{% extends "public/base.html" %} {% block banner %} {% endblock %} {% block page_title %}Server error{% endblock %} {% block content %}
Sorry, something went wrong on our system. Don't panic, we are fixing it! Please try again later.


---
layout: post
title: Avon Glimmersticks Diamonds Eyeliner - Sparkling silver
tags:
- Avon
status: publish
type: post
published: true
meta:
_edit_last: '2'
wp_plus_one_redirect: ''
wp_plus_one_disabled: '1'
_aioseop_title: Avon Glimmersticks Diamonds Eyeliner - Sparkling silver
_aioseop_keywords: Avon Glimmersticks Diamonds Eyeliner - Sparkling silver, Avon
Glimmersticks Diamonds Eyeliner Sparkling silver review
_yoast_wpseo_linkdex: '0'
_thumbnail_id: '3558'
_yoast_wpseo_focuskw: ''
_yoast_wpseo_title: ''
_yoast_wpseo_metadesc: ''
_yoast_wpseo_metakeywords: ''
_yoast_wpseo_meta-robots-noindex: '0'
_yoast_wpseo_meta-robots-nofollow: '0'
_yoast_wpseo_meta-robots-adv: none
_yoast_wpseo_sitemap-include: ! '-'
_yoast_wpseo_sitemap-prio: ! '-'
_yoast_wpseo_canonical: ''
_yoast_wpseo_redirect: ''
---
I just love the Avon glimmerstick range, they are the best budget picks I have ever had. Recently I got my hands on the Sparkling silver shade and I am in love.
Price: Rs.299
Enjoy the swatches, you can check the other shades Smokey Diamond & Black ice with review here
Which is you favorite Avon glimmerstick shade ?
You can check this months offers here, 50% off on major products... don't miss it :)
*Product was sent by PR but that has not affected my opinion at all.


Linger is a Tcl/Tk application that performs a variety of language experiments, particularly self-paced reading. Because it is Tcl/Tk-based, it is easily modified and runs on all major platforms: Unix, Windows, and Mac.
Linger can be used with just about any left-to-right horizontal language for which a font is available. It handles true/false, multiple choice questions, and difficulty ratings, as well as audio playing and recording.
It currently includes the following experiment types:
These different experiment types are explained in their own sections below. Many variations on these experiments are possible by overriding default parameters in an experiment preferences file. Additional experiment types can be created by adding new code to the preferences file. For example, Linger can also be used to generate HTML questionnaires.
Tcl/Tk comes pre-installed on most Linux machines. Just check that you have an executable named wish. If not, Tcl/Tk can be obtained from your favorite RPM site, or from the Tcl/Tk website.
To run Linger, simply execute the linger.tcl program, which should be marked executable.
To run Linger on Windows, you will need to install Tcl/Tk. To do that, go to the Tcl/Tk website and follow the links for downloading the latest ActiveTcl distribution. Once Tcl/Tk and Linger are installed you should be able to run Linger by simply double clicking on the linger.tcl file, which should have an icon that looks like a feather.
On Windows you may find that the Tcl/Tk window doesn't completely fill the screen and that the mouse remains visible. I can't find any way around these problems. I recommend moving the mouse to the edge of the screen once you start an experiment.
To figure out which fonts are available on your machine, run Wish (this comes with Tcl/Tk) and type "font families".
Or you can go to the Linger directory and double click the Linger.sit file. This will create an AppleScript file called Linger. Double click that file to run Linger. Note that the Linger window may not pop to the front when it starts.
On the Mac, you will find that the toolbar menu at the top and the mouse remain visible. I don't know any way around this. I recommend moving the mouse to the edge of the screen once you start an experiment.
To figure out which fonts are available on your machine, run wish (this comes with Tcl/Tk) and type "font families".
Linger is able to play and record sounds and work with a variety of image types. However, you may need to use some Tcl/Tk extension packages to get the full functionality. In order to display JPEG images, you will need the Img package. To include it, place this at the top of your preferences file:
package require ImgThe Snack package is recommended for playing sounds and is required for recording them. It will be included automatically if it is available. To check its availability, run wish and type:
package require snackThe Img and Snack packages are included in recent distributions for Windows and Macintosh OS X. If you are running under Unix, you may need to download and install the packages from these web sites:
It is easiest to run Linger from within the main Linger directory, which contains linger.tcl. If you want to run it from elsewhere under Linux, you must set the LINGER_HOME environment variable to point to the main Linger directory. If the Linger directory is located in your home directory, you can do this as follows:
export LINGER_HOME=${HOME}/LingerYou may want to put this command in your .bash_profile file.
To run Linger on a Unix machine, simply run the linger.tcl script, which should be executable. On a Windows machine, you can double-click the linger.tcl file. On Mac OS 9, you can double-click the executable program you created with "Drag & Drop Tclets". Under Max OS X, you can run linger.tcl from the command line, or you can double click on the Linger script, which is produced when you unpack the Linger.sit file.
When you start Linger, it will look in the Experiments subdirectory of the main Linger directory to find all available experiments. Choose the one you want using the pull-down menu.
The subject number will be set to one more than the highest number for which data has been saved in the chosen experiment. You can type a different subject number if you like. The subject number must be an integer, because it determines which set of items will be selected.
If the subject number is blank or you select Test, the experiment will be run but no data will be collected. If you choose a subject number for which data already exists, Linger will ask before overwriting the old data file.
While in the experiment, you can hit End to jump to the next screen or Esc to kill the program. If you are in the middle of an experiment, you will have to confirm the exit. If Linger is killed, any data collected so far will still be saved. See the section on Aborting and Continuing Experiments.
Doug DougTheMan John johnny87 {Duane Wayne} ddog1023
When you start Linger, if you choose one of these names from the pulldown menu, notifications will be sent to that address.
The Experiments directory should contain one subdirectory for each experiment. Each experiment directory contains a subdirectory called "Results". This will contain the data files for each subject. You don't need to create the Results directory. It will be created when the first subject is run.
The experiment directory should also have the following files:
| items | contains the experimental and filler sentences and questions |
| preferences | contains commands that override the default preferences |
| introduction | contains commands that run the intro and practice trials |
| break | contains commands that run if a rest break occurs |
| conclusion | contains commands that run at the end of the experiment |
# e2 16 c There_were_two guitarists practicing at a_night_club. One made a living as a musician. The other only played for fun. A pianist played with the guitarist who@W played@verb for fun in a concert, and they got a record deal. ? Did the guitarist who played for fun get a record deal? Y
Each item begins with a header. The format of the header is:
# experiment_name item_name condition_name
A filler item must be given the experiment_name "filler". The condition_name will be ignored, but must be specified. It is best to set it to "-". Practice items can also be included in the items file. They must be given the experiment_name "practice". Practice items will not be shown during the experiment, but you can choose to present them during the introduction using the presentItem command.
Using the default font on a 1024x768 display, you should be able to fit 100 characters on a line. If your items are longer than one line, be sure to consider where the line breaks might fall and how this could bias your results. It is probably best if the line breaks occur between sentences or during a non-critical region. If lines are too long to fit on the screen, Linger will wrap them for you. You may want to avoid this. You can check if any lines are too long by running Linger with the -c command-line option.
The blank spaces (other than those at the beginning or end of a line) will be retained in the actual experiment. So you should be sure that double spaces only appear where they should (after periods).
If you want several consecutive words to be revealed (in masked reading) as a block, they should be connected with underscores. In the first line of the example, "There were two" appears as a block and "a night club" appears as a block. On the other hand, if you want to split a word into two separate regions with no space between them, use a pipe symbol ("|") to split the words in the items file. This is often necessary in languages like Chinese which does not use spaces between the words.
Each word (or word block, really) has a tag, which will appear in the data file. The default tag is -. If you append @foo to a word, the word's tag will be set to "foo". Tags can be used to identify the words of interest in your experiment. You might tag the main verb with @mv and the noun following it with @obj. Then you can easily extract reading times of interest from the data file by selecting lines whose tag column matches a certain tag.
You could also use tags to label the words in regions of interest. If you have regions A, B, and C, you might label the words: A1 A2 A3 B1 B2 C1 C2, etc. Then you can easily compute region-by-region averages by extracting the lines in the results file with matching tags.
Important note: If your regions of interest do not always start and end on the same word number (or word block number, really) for every item in a given condition, you must use tags to label the regions. Otherwise, once the experiment is done it will be extremely difficult to analyze the data because the regions won't line up.
If a word is given an empty tag, meaning that nothing follows the @, it will be a static word. Static words are not masked during self-paced reading and are visible throughout the sentence. No data will be recorded for them in the results file. Static words might be used to identify the speakers in a dialogue.
Each type of question must be on a single line, starting with a special symbol. If you want to have a line that is part of an item's sentence, but which should begin with one of the marks that identify a question or item header (#?!*), you can precede the mark with a backslash (\), which will be stripped off but which will prevent the line from being treated as a question or header.
? Did the guitarist who played for fun get a record deal? Y
Optionally, the first ? can be immediately followed by a tag, as in ?q1b. In this case, the question is given the tag "q1b". The tag is included in the results file. This can be useful in cases where several different types of questions are used and you would like to perform separate analyses on them.
Here's an example with a single correct answer using underscores versus double quotes:
!foo The ________ ate the flowers. {cat dog pink_pig fat_baby} pink_pig !foo The ________ ate the flowers. {cat dog "pink pig" "fat baby"} {"pink pig"}
In this case, the question has been given the tag "foo". Here is how it would look with two possible answers:
!foo The ________ ate the flowers. {cat dog pink_pig fat_baby} {pink_pig dog} !foo The ________ ate the flowers. {cat dog "pink pig" "fat baby"} {"pink pig" dog}You can place double quotes around single-word answers if you want. It doesn't matter.
The following variables can be set in the preferences file to alter the way questions are asked:
# If true, multiple questions are randomly ordered: set QuestRand 0 # This is the number of questions asked per item. If it is the null string, # all are asked: set QuestNum {} # The probability of asking each question if one or more is available: set QuestProb 1.0If an item has four questions, all of them will be asked by default, in the order given. If you set QuestRand to 1, they will be randomly ordered. If you set QuestNum to 2, only the first two questions will be asked. If you set QuestRand to 1 and QuestNum to 2, then two of the four items will be asked, in random order. If you set QuestProb to 0.5, then each of the questions will be asked with 50% probability, which could mean that none are asked, or all of them. If you set QuestNum to 3 and QuestProb to 0.5, then three of the four items will be chosen initially, and then they will each be asked with 50% chance, so you will get from 0 to 3 questions.
If you need more customized question asking behavior, you can override the chooseQuestions procedure, which does the job of choosing the questions to ask for each item. For example, you may have two types of question (about the first clause versus the second clause), with three questions of each type, and you want to ask exactly one question of each type. In that case, you would ise the question tag to label its type and write your own chooseQuestions procedure to make use of this label.
The width of the entry box for typing the answer is controlled by the FillInBlankWidth variable. It defaults to 50. The entry box will scroll, so subjects may type more than this if they want.
It can be more efficient, however, to run items from multiple experiments in the same session. The items from different experiments will serve as fillers for each other. Of course, you would want those experiments to use different sentence types. One experiment using sentential complements would not make a good set of fillers for another experiment using sentential complements.
Normally, you will want the number of subjects who run an experiment to be a multiple of the number of conditions in the experiment to balance the number of subjects in each condition for each item. If you are combining several experiments with different numbers of conditions, the naive thing to do would be to run as many subjects as the least common multiple of the two condition numbers, or some multiple thereof. However, if you had three experiments with 4, 5, and 7 conditions, you would need 140 subjects to balance the conditions in this way.
A smarter thing to do is to run at least enough subjects for each experiment individually, and then discard the data for the last few subjects for an experiment if the number of subjects is not a multiple of the number of conditions for that experiment. So, in this example, you might run 49 subjects. All of them will be used for the experiment with 7 conditions. The last 4 will be discarded for the experiment with 5 conditions, and the last 1 will be discarded for the experiment with 4 conditions.
The introduction, break, and conclusion files define the start, rest periods, and end of the experiment, respectively. Each file is just a Tcl script, so you could actually do arbitrarily complex things with them. But there are some default commands that are normally used. They are as follows:
instruct {This is the first line of the text. This is the second line. This is the third.}
The instruct command prints some text in the small font and then waits for a key press to continue. The text will automatically be wrapped if the lines are two long, but you can put your own line breaks in as well. Lines will be left justified. This is useful for giving instructions in the introduction file.
command {This is a big font command.}
The command command is similar to instruct but it uses a big font and centers the text. It should be used for short messages, like "Here we go...".
createItem {# practice 1 - This is a practice sentence. ? Did you read the sentence? Y}
The createItem command is used to create a temporary item. This is most often used to create practice items for immediate presentation. createItem takes one argument, which should be enclosed in curly braces and which should consist of an item description, just as it would appear in the "items" file. You should give practice items the experiment_name "practice" and the condition name "-". Practice items can also be defined in the items file. As long as they have the experiment_name "practice", they won't be presented during the actual experiment.
presentItem practice:1:-
The presentItem command runs a single item using the item-presentation function that is associated with the current experiment. If the experiment is selfPacedReading, then the command that is actually run will be selfPacedReadingItem. Normally this is used to immediately present a practice item that has just been created. The argument consists of the experiment_name, item_name, and condition_name of the item, separated by colons.
The break file is run periodically to give the subjects a break. Normally it will just contain something like:
command {Time for a break.}
The BreakInterval variable determines the number of sentences between breaks. If it is 0, no breaks will be offered.
The preference file is also just a Tcl script file. It will be run just after the experiment has been chosen. The preference file should contain overrides to the preferences set at the top of the linger.tcl file. You can override a parameter simply by setting it to a different value. For example, if you want to put masks over spaces between words, you should set the MaskSpaces parameter to 1 as follows:
set MaskSpaces 1
You can customize many different aspects of Linger in the preference file, including the experiment type, the display fonts, the response keys, the various timing delays, the names of the other files, the frequency of rest breaks, the frequency of questions, the feedback messages for right or wrong answers, and even the special symbols used in the items file.
To see all the variables that can be customized, with short descriptions, just read the top of the linger.tcl file.
If you want to do more profound customizations, such as creating a new experiment type, you should place the code in the preferences file. The preferences file will be read after most of the linger.tcl file, so you can also override any of the functions that are defined in linger.tcl by re-defining them.
set CollectRatings 1The rating will be presented after the sentence, but before any other questions. Subjects can respond my clicking with the mouse or using the number keys. These options affect the ratings:
# The maximum value of the rating scale: set RatingChoices 7 # The message presented along with ratings: set RatingMessage "How difficult was it to understand that sentence?" # The label at the low end of the rating scale: set RatingEasy "Very Easy" # The label at the high end of the rating scale: set RatingHard "Very Hard"The rating and response time are stored in the Results file.
The items that the subject would have seen are stored in a file in the Results directory whose name is the subject number, with the extension .itm. If you run Linger again and choose the same experiment and subject number and this file is found, you will be asked if you want to continue where you left off.
If you do choose to continue, the items will be loaded from the .itm file. Linger will then read the .dat file to figure out where the previous run left off. The new results will be appended to the .dat file.
When you continue an experiment, you may not want to make the subject go through the entire introduction again. In your introduction file, you can check the "Continuing" variable to determine if this is a continuation. Here is how you might do that:
if {$Continuing} { put code here that is run when continuing } else { put code here that is run for a new subject }
Unless it is in "test" mode, Linger will write a data file to the Results subdirectory of the experiment directory. The file name will be the subject number followed by ".dat". The data file contains both the reading times and the question answering correctness and response time.
Each line in the data file contains a single observation and has 8 columns. The columns are separated by whitespace. The columns for a reading time response will be:
subject_num experiment_name item_name condition_name word_num word word_tag time
The word is the actual word or region, from which you can get the word length.
The word_tag is its tag.
The time is in milliseconds.
The columns for a T/F question will be:
subject_num experiment_name item_name condition_name ?tag answer correct time
The answer is the actual response given (1 for yes, 0 for no).
The correct field is 1 if the response was correct, 0 if wrong.
The tag is the tag that followed the ? in the items file.
The columns for a multiple-choice question will be:
subject_num experiment_name item_name condition_name !tag answer correct time
The answer is the actual response given by the subject.
The columns for a difficulty rating will be:
subject_num experiment_name item_name condition_name %tag answer {} time
The answer is the response given by the subject. There is no correct answer, so the 7th column is the null string.
| -e experiment | This sets the experiment name, causing it to skip the experiment-choosing window. |
| -s subject | Sets the subject number. If -e is used and this is not, the next available subject number will be used. |
| -t | Runs in testing mode, so no data will be recorded. |
| -b | Runs in batch mode, which is non-interactive. This can be used to have Linger perform special functions, like spewing out information for an HTML form. |
| -c | This causes Linger to check the length of the lines in every item and report those that will wrap. |
| -v # | Sets the verbosity level. 1 prints out the lines in the items file as they are parsed, which is useful for finding the source of errors. 2 prints out lots of info as the experiment runs. |
To check the length of all of the items in experiment Exp1, you could do this:
linger.tcl -e Exp1 -c
Masked self-paced reading requires the subject to press a key (the spacebar by default) to reveal each word or block of words. A block of words is simply a group of words that appear together. They are joined by underscores in the items file. Hidden words are masked by dashes. By default these don't cover spaces and have small gaps between characters.
This is the default experiment type, so the preferences file could be empty if you just want the standard behavior. Here are some options that you may want to override:
# The font used for the sentences: set TextFont "-family {courier new} -size -14 -weight bold" # Should spaces within blocks be masked: set MaskJoins 0 # Should spaces between blocks be masked: set MaskSpaces 0 # The gap between mask dashes (in pixels): set MaskGap 1 # The number of blocks to show at once with a moving window: set WindowSize 1 # The key to see the next word: set GoKey space # The key to respond no: set NoKey f # The key to respond yes: set YesKey j # The delay (in msec) before presenting each sentence: set PreDelay 1000 # The reward message, leave blank for no feedback: set RightAnswer "" # The error message, leave blank for no feedback: set WrongAnswer "Oops. Wrong answer." # The time the feedback message stays on the screen: set FeedbackDelay 1500
If the RightAnswer or WrongAnswer message is left blank, no feedback will be given in that case.
If a word is given an empty tag (by appending an @ symbol to the word), it is a "fixed" word, which means it remains on the screen permanently and no timing data is recorded for it. If such a word appeared in the middle of a sentence, the moving window would jump over it.
The moving window can be made larger than a single block by changing the WindowSize parameter. In this case, it will really appear to be more like a window moving over the sentence. Fixed words do not participate in the moving window. The reading time is recorded as if it applies to the first word in the window.
set PlayWords 1If you don't want to display the words at the same time, use this option as well:
set ShowWords 0A variety of sound formats can be used, although WAV files are standard. By default, Linger will expect the first word of experiment E1, item 4, condition b in the following location:
Audio/E1-4-b/E1-4-b-1.wavand the second word in file:
Audio/E1-4-b/E1-4-b-2.wavThe Audio directory, in this case, is a subdirectory of your experiment directory. You can change the name of the audio directory as well as the mark used to separate the elements of the item name and the extension of the sound file by changing these options in the preference file:
# The subdirectory in which audio is stored. For self-paced listening, this # needs a subdirectory for each item: set AudioDir "Audio" # This separates an item's exper., item, condit., and word in audio filenames: set AudioJoinMark "-" # The extension on audio files: set AudioExtension "wav"Note that each item and condition gets its own subdirectory within the main audio directory. If a sound file is missing, a beep will be placed in place of the word and an error message will be printed to standard error.
In centered self-paced reading, the words or phrases appear roughly in the center of the screen, with no masking. In the preferences file, you will need to set the experiment type:
set Experiment centerSelfPacedReading
By default, the words are not actually centered, but left justified a certain distance to the left of the center. This is generally better because it allows the reader to always saccade back to the same point to read the next word. You can adjust whether the words are actually centered, and the distance from the center on which they are aligned:
# When doing center*PacedReading, if the words are left justified relative to # one another: set CenterLeftAligned 1 # When doing center*PacedReading, the amount the words are shifted to the left # from the middle of the screen: set CenterLeftShift 50Before the first word appears, there will be a crosshair on which subjects can fixate, to indicate the impending start of a sentence. If the words are left-aligned, it is best if the crosshair appears one or two characters to the right of the alignment point. The location and size of the crosshair can be adjusted with these parameters:
# The size of a fixation crosshair: set CrossSize 10 # The amount the crosshair is shifted up from center: set CrossUpShift 0 # The amount the crosshair is shifted left from center: set CrossLeftShift 0The delay during which the crosshair is visible is set by this:
# The delay (in msec) before presenting each item: set PreDelay 1000And the duration of blank screen between the crosshair and the first word is:
# The delay before the first word in auto-paced reading (and centerSelfPaced): set AutoPacedInitDelay 1000
Auto-paced reading is like self-paced reading, except that it isn't self paced. The word blocks are revealed at a fixed rate. To use auto-paced reading, add the following to the preferences file:
set Experiment autoPacedReadingMost of the options useful for self-paced reading are also useful here. Two addition parameters are:
# The delay between words in auto-paced reading: set AutoPacedDelay 400 # The delay before the first word in auto-paced reading: set AutoPacedInitDelay 1000
set Experiment centerAutoPacedReadingMost of the options useful for centered self-paced reading are also useful here. The one additional parameters is:
# The delay between words in auto-paced reading: set AutoPacedDelay 400
The following variables are useful:
TextFont TextColor PreDelay
When starting Linger, the two subjects must be given the same subject number, so the item ordering can be synchronized. In order to ensure that the subjects see the same item ordering, the random number generator will be re-seeded using the subject number before randomizing the item order.
Instead of setting the Experiment variable to speakAndListen, you must run this command in the preferences file:
speakAndListenInitThis will present a dialog box that allows you to indicate whether the subject is the speaker or listener. This will set the SALRole global variable to either "Speaker" or "Listener". Then, in the introduction file, you can check this variable in order to present different instructions to the speaker and listener as follows:
if {$SALRole == "Speaker"} { put the speaker's introduction code here } else { put the listener's introduction code here }This variable sets the message shown to the speaker at the start of each item:
set SpeakerWaitMessage "Wait until the listener is ready."If the subject number is 5, the speaker's data will be stored in the file Results/5S.dat and the listener's in Results/5L.dat. For the speaker it records the reading time prior to speaking and the speaking time. For the listener it records the listening time and the question responses.
The audio recordings are stored in a subdirectory of the Results directory whose name is the subject number. The file name will be composed of the experiment name, item number, and condition, joined by the AudioJoinMark, which defaults to "-".
You can change the rate and format of the sound recordings by setting the RecordOptions variable:
# Flags for the SNACK recorder: set RecordOptions {-rate 44100} # -encoding Lin16 | Lin8offset | Lin8 | Lin24 | Lin32 | Float | Alaw | Mulaw # -rate 8000 | 11025 | 16000 | 22050 | 32000 | 44100 | 48000 # see the Snack manual for other options
The following line should appear in the preferences file:
set Experiment listenAndAnswerThis option sets the message displayed while the subject listens to the sentence:
# The message used in listenAndAnswer trials: set ListenMessage "Listen to the sentence"In this type of experiment, you probably don't want to randomize the order of the items. Therefore, you should add:
set RandomOrder 0
This will only work on a system that is capable of playing a sound file from the command-line. The command for playing a file is stored in the PlayAudio variable. The default is appropriate for most Linux systems:
set PlayAudio /usr/bin/playOther relevant variables are:
# The size of a fixation crosshair: set CrossSize 10The test word is presented using the BigFont:
set BigFont "-family {helvetica} -size 24 -weight bold"In writing the items file, the name of the sound file should be used in place of the sentence and the question should just contain the lexical decision word:
# APLD 1 a /home/foo/Primes/1a.wav ? cantaloupe Y
When you save the file, choose plain text (not rich text format) and then select the appropriate Unicode encoding for your language. Try to save the files with no .txt extension. If you can't save without an extension, try removing it once the file is saved. You can also leave the .txt extension on the files, but you'll need to make a change to preferences, as explained below.
The preferences file itself must be in plain English. In the preferences file, you need to tell Linger what encoding was used for the other files. You do this by setting the LangEncoding variable. For Chinese, the preferences file might include the following:
set LangEncoding big5 set TextFont "-family {song ti} -size -24 -weight bold"
This says that the encoding used on the experiment files is big5. "Song ti" is a Chinese font available on most Linux machines. Other fonts may be downloadable and others are probably available under Mac and Windows.
In order to see which encodings are available in Linger, run the program wish and, at the command line, run "encoding names". The names won't be the same as those available in Word, but you will probably see the correspondence. Make sure you choose the same encoding when you save the files as you do in the preferences file.
I recommend big5 or euc-cn for Chinese, enc-jp or jis0208 for Japanese, macCyrillic for Russian (on a Mac).
In order to see which fonts are available, run wish and type "font families". Look for a name that is similar to a non-English font that you are used to using in Word or some other program.
If you were forced to save the introduction, items, and other files with a .txt extension, you will need to tell Linger about this by putting the following lines (whichever apply) in the preferences file:
set ItemFile "items.txt" set IntroFile "introduction.txt" set BreakFile "break.txt" set ConclFile "conclusion.txt"
If you need to include encoded text in the preferences file (for example, if you are changing the WrongAnswer message), this may present a small problem. The desired encoding is not normally known until you set the LangEncoding inside the preferences file, and by that time it's too late to encode the file properly. Most changes that would require non-English text can be done at the top of the introduction file instead of in the preferences file. Otherwise, you should put the encoded portions of the preferences in another file, like preferences2. Then you can put this line in the original preferences file, after you set the LangEncoding:
encSource preferences2
Linger automatically decides which items to give to each subject in a round-robin sort of fashion based on the subject's number. Subject 1 will get the first condition of item 1, the second condition of item 2, the third of item 3, and so on. Subject 2 will get the second condition of item 1, the third of item 2, and so on. Each subject will thus have 1 condition for each item and an as-even-as-possible number of sentences from each condition.
The number of different choices (different subject lists) will be the least common multiple of the number of conditions in each item. If some items have 4 conditions and some have 3, there will be 12 distinct lists, effectively.
If you drop a subject from the experiment and want to replace his data, it is a good idea to reuse their subject number with the next subject to fill in the hole. Otherwise, the number of subjects per condition may not be balanced. Of course, you will probably want to copy the original .dat file to a backup location before overwriting it.
Once the experimental sentences have been chosen for a particular subject, they are ordered. If you want to present the items in the order specified in the items file, set the RandomOrder variable to 0 in the preferences file.
When ordering the items, items within each experiment are randomized and filler items and items from different experiments are interlaced. If possible, Linger will start with a filler item and no two items from the same experiment will be adjacent. If the items are all from the same experiment, you should have at least as many fillers as items. If you are running items from multiple experiments in one session, items from one experiment can act as fillers for the others, and fewer actual filler items may be necessary.
More advanced users may wish to create their own experiment types. The best way to learn to customize Linger is to begin by becoming proficient with the Tcl/Tk language. A simple tutorial is available here. The Tcl/Tk manual is also very helpful for reference.
The next thing to do is to read the code in linger.tcl. The most useful parts are the global variables at the top and the helper functions which follow them. The helper functions are simple procedures that can be used to facilitate commonly performed operations. They handle tasks such as opening files, printing warning and error messages, randomly sorting lists, measuring elapsed time, creating time delays, displaying various types of messages, and working with sounds.
The procedures for a new experiment can be written from scratch or based on copies of the procedures of an existing experiment. Most experiments will have two primary procedures, although defining some additional helper procedures may be useful. For example, the following procedures define the Auditory Prime Lexical Decision experiment type:
proc auditoryPrimeLexicalDecisionItem item { global QuestProb Question Sentence PreDelay loadSound $Sentence($item) snd crossHairOn after $PreDelay playSound snd crossHairOff askQuestions $item BigFont center deleteSound snd } proc auditoryPrimeLexicalDecision list { standardExperiment auditoryPrimeLexicalDecisionItem $list }The auditoryPrimeLexicalDecision procedure is the main one that runs the entire experiment, other than the introduction and conclusion. The name of this main procedure is the name of the experiment and it is what you must set the Experiment variable to.
The other necessary procedure is the item-presentation procedure. Its name should be the same as the experiment, with "Item" appended to the end. It takes as an argument the code for a single item and controls the presentation of the item and any questions that follow it.
The main experiment procedure takes a list of item codes as its argument. Most of these procedures simply call the standardExperiment procedure. This takes two arguments, the name of the experiment's item-presentation procedure and the list of items. The standardExperiment runs through the list of items, calling the item presentation procedure on each one. It also pauses for rest breaks and sends notifications at the appropriate time.
The auditoryPrimeLexicalDecisionItem procedure begins by declaring some global variables. Any variables that exist outside of the procedure must be declared global before they are used. It then calls the loadSound procedure to load the sound file. The name of the sound file in this experiment type is given in the items file in place of the sentence. So the global variable Sentence($item), which normally contains a list of the sentence lines, actually contains a filename in this case.
The crossHairOn procedure displays a crosshair in the center of the screen. The next line waits for a fixed delay. Then the sound is played in blocking mode, which won't return until it is done. Next, the crosshair is removed and the questions are asked. The question, in this case, should consist of a word on which a lexical decision will be performed. Finally, the sound is deleted to free up the memory it uses.


M
y
S
l
a
m
More
Profile
Settings
Log Out
Create your Slam Post
Question asked by
To
Select Questions


pathogens health virus priority public [], infectious research diseases pathogen criteria prioritization {border-style Health group px;} #ffffff;} surveillance experts importance process priorities spp. German national weight []. different high number groups highest scores total (e.g., (nâ€Š=â€Š) Germany[], according causes criterion illness Infectious epidemiological external scoring weighting Delphi Germany Hepatitis actions approach based care collab: incidence internal low need needs proportion px; weighted {font-family Department Diseases Helicobacter RKI broad established font-size important large methodology participants prevention setting strategic treatment Disease Medical Mycobacterium Neisseria University assigned control data disease double; events experts. fatality general median medium ranked respective score (including Federal Public Respiratory available border-color border-width causing clinical common communicable considered dedicated defined effective moderate new pathogens' political possibilities professional pylori range solid; utilization virus, {font-style {font-weight â€œâ€�) (median Chlamydia Clostridium Communicable Freiburg, Human Influenza Institute Ministry Prevention RSV Results Staphylococcus Table Varicella World absenteeism agenda allocation antimicrobial areas bold clinicians contains courier; criteria, criterion. current definitions diseases. em; example, fever final good group, group: groups. includes: initiated international level list maintain particular planning prevalence pt;} ranking rates reference relevant require resources respiratory sequelae small specialists syncytial systems used using work â€œCase


Actions, resources, and condition keys for Amazon EC2 Image Builder
Amazon EC2 Image Builder (service prefix:
imagebuilder
) provides the following service-specific resources, actions, and condition context keys for use in IAM permission policies.
References:
-
Learn how to configure this service .
-
View a list of the API operations available for this service .
-
Learn how to secure this service and its resources by using IAM permission policies.
Topics
Actions defined by Amazon EC2 Image Builder
You can specify the following actions in the
Action
element of an IAM policy statement. Use policies to grant permissions to perform an operation in AWS. When you use an action in a policy, you usually allow or deny access to the API operation or CLI command with the same name. However, in some cases, a single action controls access to more than one operation. Alternatively, some operations require several different actions.
The
Resource types
column of the Actions table indicates whether each action supports resource-level permissions. If there is no value for this column, you must specify all resources ("*") to which the policy applies in the
Resource
element of your policy statement. If the column includes a resource type, then you can specify an ARN of that type in a statement with that action. If the action has one or more required resources, the caller must have permission to use the action with those resources. Required resources are indicated in the table with an asterisk (*). If you limit resource access with the
Resource
element in an IAM policy, you must include an ARN or pattern for each required resource type. Some actions support multiple resource types. If the resource type is optional (not indicated as required), then you can choose to use one of the optional resource types.
The
Condition keys
column of the Actions table includes keys that you can specify in a policy statement's
Condition
element. For more information on the condition keys that are associated with resources for the service, see the
Condition keys
column of the Resource types table.
For details about the columns in the following table, see Actions table .
| Actions | Description | Access level | Resource types (*required) | Condition keys | Dependent actions |
|---|---|---|---|---|---|
| CancelImageCreation | Grants permission to cancel an image creation | Write | |||
| CreateComponent | Grants permission to create a new component | Write |
iam:CreateServiceLinkedRole imagebuilder:TagResource kms:Encrypt kms:GenerateDataKey kms:GenerateDataKeyWithoutPlaintext |
||
| CreateContainerRecipe | Grants permission to create a new Container Recipe | Write |
ecr:DescribeImages ecr:DescribeRepositories iam:CreateServiceLinkedRole imagebuilder:GetComponent imagebuilder:GetImage imagebuilder:TagResource kms:Encrypt kms:GenerateDataKey kms:GenerateDataKeyWithoutPlaintext |
||
| CreateDistributionConfiguration | Grants permission to create a new distribution configuration | Write |
iam:CreateServiceLinkedRole imagebuilder:TagResource |
||
| CreateImage | Grants permission to create a new image | Write |
iam:CreateServiceLinkedRole imagebuilder:GetContainerRecipe imagebuilder:GetDistributionConfiguration imagebuilder:GetImageRecipe imagebuilder:GetInfrastructureConfiguration imagebuilder:TagResource |
||
| CreateImagePipeline | Grants permission to create a new image pipeline | Write |
iam:CreateServiceLinkedRole imagebuilder:GetContainerRecipe imagebuilder:GetImageRecipe imagebuilder:TagResource |
||
| CreateImageRecipe | Grants permission to create a new Image Recipe | Write |
ec2:DescribeImages iam:CreateServiceLinkedRole imagebuilder:GetComponent imagebuilder:GetImage imagebuilder:TagResource |
||
| CreateInfrastructureConfiguration | Grants permission to create a new infrastructure configuration | Write |
iam:CreateServiceLinkedRole iam:PassRole imagebuilder:TagResource sns:Publish |
||
|
imagebuilder:CreatedResourceTagKeys imagebuilder:CreatedResourceTag/<key> |
|||||
| DeleteComponent | Grants permission to delete a component | Write | |||
| DeleteContainerRecipe | Grants permission to delete a container recipe | Write | |||
| DeleteDistributionConfiguration | Grants permission to delete a distribution configuration | Write | |||
| DeleteImage | Grants permission to delete an image | Write | |||
| DeleteImagePipeline | Grants permission to delete an image pipeline | Write | |||
| DeleteImageRecipe | Grants permission to delete an image recipe | Write | |||
| DeleteInfrastructureConfiguration | Grants permission to delete an infrastructure configuration | Write | |||
| GetComponent | Grants permission to view details about a component | Read |
kms:Decrypt |
||
| GetComponentPolicy | Grants permission to view the resource policy associated with a component | Read | |||
| GetContainerRecipe | Grants permission to view details about a container recipe | Read | |||
| GetContainerRecipePolicy | Grants permission to view the resource policy associated with a container recipe | Read | |||
| GetDistributionConfiguration | Grants permission to view details about a distribution configuration | Read | |||
| GetImage | Grants permission to view details about an image | Read | |||
| GetImagePipeline | Grants permission to view details about an image pipeline | Read | |||
| GetImagePolicy | Grants permission to view the resource policy associated with an image | Read | |||
| GetImageRecipe | Grants permission to view details about an image recipe | Read | |||
| GetImageRecipePolicy | Grants permission to view the resource policy associated with an image recipe | Read | |||
| GetInfrastructureConfiguration | Grants permission to view details about an infrastructure configuration | Read | |||
| GetWorkflowExecution | Grants permission to view details about a workflow execution | Read | |||
| GetWorkflowStepExecution | Grants permission to view details about a workflow step execution | Read | |||
| ImportComponent | Grants permission to import a new component | Write |
iam:CreateServiceLinkedRole imagebuilder:TagResource kms:Encrypt kms:GenerateDataKey kms:GenerateDataKeyWithoutPlaintext |
||
| ImportVmImage | Grants permission to import an image | Write |
ec2:DescribeImportImageTasks iam:CreateServiceLinkedRole |
||
| ListComponentBuildVersions | Grants permission to list the component build versions in your account | List | |||
| ListComponents | Grants permission to list the component versions owned by or shared with your account | List | |||
| ListContainerRecipes | Grants permission to list the container recipes owned by or shared with your account | List | |||
| ListDistributionConfigurations | Grants permission to list the distribution configurations in your account | List | |||
| ListImageBuildVersions | Grants permission to list the image build versions in your account | List | |||
| ListImagePackages | Grants permission to return a list of packages installed on the specified image | List | |||
| ListImagePipelineImages | Grants permission to return a list of images created by the specified pipeline | List | |||
| ListImagePipelines | Grants permission to list the image pipelines in your account | List | |||
| ListImageRecipes | Grants permission to list the image recipes owned by or shared with your account | List | |||
| ListImageScanFindingAggregations | Grants permission to list aggregations on the image scan findings in your account | List | |||
| ListImageScanFindings | Grants permission to list the image scan findings for the images in your account | List |
inspector2:ListFindings |
||
| ListImages | Grants permission to list the image versions owned by or shared with your account | List | |||
| ListInfrastructureConfigurations | Grants permission to list the infrastructure configurations in your account | List | |||
| ListTagsForResource | Grants permission to list tags for an Image Builder resource | Read | |||
| ListWorkflowExecutions | Grants permission to list workflow executions for the specified image | List | |||
| ListWorkflowStepExecutions | Grants permission to list workflow step executions for the specified workflow | List | |||
| PutComponentPolicy | Grants permission to set the resource policy associated with a component | Permissions management | |||
| PutContainerRecipePolicy | Grants permission to set the resource policy associated with a container recipe | Permissions management | |||
| PutImagePolicy | Grants permission to set the resource policy associated with an image | Permissions management | |||
| PutImageRecipePolicy | Grants permission to set the resource policy associated with an image recipe | Permissions management | |||
| StartImagePipelineExecution | Grants permission to create a new image from a pipeline | Write |
iam:CreateServiceLinkedRole imagebuilder:GetImagePipeline |
||
| TagResource | Grants permission to tag an Image Builder resource | Tagging | |||
| UntagResource | Grants permission to untag an Image Builder resource | Tagging | |||
| UpdateDistributionConfiguration | Grants permission to update an existing distribution configuration | Write | |||
| UpdateImagePipeline | Grants permission to update an existing image pipeline | Write | |||
| UpdateInfrastructureConfiguration | Grants permission to update an existing infrastructure configuration | Write |
iam:PassRole sns:Publish |
||
|
imagebuilder:CreatedResourceTagKeys imagebuilder:CreatedResourceTag/<key> |
Resource types defined by Amazon EC2 Image Builder
The following resource types are defined by this service and can be used in the
Resource
element of IAM permission policy statements. Each action in the
Actions table
identifies the resource types that can be specified with that action. A resource type can also define which condition keys you can include in a policy. These keys are displayed in the last column of the Resource types table. For details about the columns in the following table, see
Resource types table
.
| Resource types | ARN | Condition keys |
|---|---|---|
| component |
arn:$
{
Partition}:imagebuilder:$
{
Region}:$
{
Account}:component/$
{
ComponentName}/$
{
ComponentVersion}/$
{
ComponentBuildVersion}
|
|
| componentVersion |
arn:$
{
Partition}:imagebuilder:$
{
Region}:$
{
Account}:component/$
{
ComponentName}/$
{
ComponentVersion}
|
|
| distributionConfiguration |
arn:$
{
Partition}:imagebuilder:$
{
Region}:$
{
Account}:distribution-configuration/$
{
DistributionConfigurationName}
|
|
| image |
arn:$
{
Partition}:imagebuilder:$
{
Region}:$
{
Account}:image/$
{
ImageName}/$
{
ImageVersion}/$
{
ImageBuildVersion}
|
|
| imageVersion |
arn:$
{
Partition}:imagebuilder:$
{
Region}:$
{
Account}:image/$
{
ImageName}/$
{
ImageVersion}
|
|
| imageRecipe |
arn:$
{
Partition}:imagebuilder:$
{
Region}:$
{
Account}:image-recipe/$
{
ImageRecipeName}/$
{
ImageRecipeVersion}
|
|
| containerRecipe |
arn:$
{
Partition}:imagebuilder:$
{
Region}:$
{
Account}:container-recipe/$
{
ContainerRecipeName}/$
{
ContainerRecipeVersion}
|
|
| imagePipeline |
arn:$
{
Partition}:imagebuilder:$
{
Region}:$
{
Account}:image-pipeline/$
{
ImagePipelineName}
|
|
| infrastructureConfiguration |
arn:$
{
Partition}:imagebuilder:$
{
Region}:$
{
Account}:infrastructure-configuration/$
{
ResourceId}
|
|
| kmsKey |
arn:$
{
Partition}:kms:$
{
Region}:$
{
Account}:key/$
{
KeyId}
|
|
| workflowExecution |
arn:$
{
Partition}:imagebuilder:$
{
Region}:$
{
Account}:workflow-execution/$
{
WorkflowExecutionId}
|
|
| workflowStepExecution |
arn:$
{
Partition}:imagebuilder:$
{
Region}:$
{
Account}:workflow-step-execution/$
{
WorkflowStepExecutionId}
|
Condition keys for Amazon EC2 Image Builder
Amazon EC2 Image Builder defines the following condition keys that can be used in the
Condition
element of an IAM policy. You can use these keys to further refine the conditions under which the policy statement applies. For details about the columns in the following table, see
Condition keys table
.
To view the global condition keys that are available to all services, see Available global condition keys .
| Condition keys | Description | Type |
|---|---|---|
| aws:RequestTag/${TagKey} | Filters access by the presence of tag key-value pairs in the request | String |
| aws:ResourceTag/${TagKey} | Filters access by tag key-value pairs attached to the resource | String |
| aws:TagKeys | Filters access by the presence of tag keys in the request | ArrayOfString |
| imagebuilder:CreatedResourceTag/<key> | Filters access by the tag key-value pairs attached to the resource created by Image Builder | String |
| imagebuilder:CreatedResourceTagKeys | Filters access by the presence of tag keys in the request | ArrayOfString |
| imagebuilder:Ec2MetadataHttpTokens | Filters access by the EC2 Instance Metadata HTTP Token Requirement specified in the request | String |
| imagebuilder:StatusTopicArn | Filters access by the SNS Topic Arn in the request to which terminal state notifications will be published | String |


THE NEW REPLACEMENT TO HEADLEY COURT:
THE VISION OF THE DUKE OF WESTMINSTER IS NOW A REALITY
The new rehabilitation centre for servicemen and women planned as a replacement for Headley Court is now a reality. The centre has been designed by leading classical firm John Simpson Architects of London and is backed by the Duke of Westminster, himself a former soldier. Parliament announced the official go-ahead in July 2014 and the contract for this prestigious £250 million construction project is about to be let.
John Simpson Architects were commissioned to design a masterplan for a substantial series of new buildings within the registered historic landscape of the Stanford Hall estate near Loughborough. The buildings have been arranged to form a series of courtyards and external garden spaces providing a conducive environment for the rehabilitation of wounded service personnel. In addition, the practice will be restoring much of the sensitive historic fabric of Grade II* listed Stanford Hall which is at the historic heart of the estate and at the core of the proposals.
The centre will provide facilities for a range of treatments including for trauma rehabilitation, neurological care and a “back to life” capability which will, ensure that for people leaving the centre are fully prepared for life outside.
Listed building consent and planning permission has already been given for the project which will provide 400,000 sq ft of new floor space within a number of buildings, creating a new Defence and National Rehabilitation Centre which will sit comfortably in the surrounding landscape.
Construction is due to start in summer this year and the facilities transferred from Headley Court will be fully operational by 2018.


Home
Menu
Music
Jobs
Product Price Update
Sales Report
Coffee at JavaJam
Total dollar sales by products
Sales quantities by product category


{% extends 'base.html' %} {% load widget_tweaks %} {% block content %}
Welcome to your dashboard. From here you can get a summary view of what data others have requested from you (Responses), your own data requests you have sent out (Requests) and also the files that you have uploaded.
Use the tabs below to navigate across these areas.
You either have no requests or have completed all outstanding requests.
Note that the email you have registered with is: {{user.email}}. Requests will need to be sent to this email to appear here.
You have not created any requests. These will appear here once you start to build your first request. Get started using the button above.
Filename:
{{ obj.document.url }}
Uploaded at:
{{ obj.uploaded_at }}
No documents.
{% endif %}


Computer Science Ph.D. student at The University
of Texas at El Paso.
My research interest lies in knowledge representation / semantic workflows / data portability.
I'm a current member of Cyber-ShARE's iLink
group.
Code optimization for a native Java application
Development of an Android application for non-tech-savy end-users
Publish web sites on development server
Conduct research on Smart Cities solutions: Understand and improve the urban mobility of older adults in
El Paso, Texas. Software development using Android Studio followed by a Flutter development.
Oversee peers
Research and development of a semantical-based technology for the sharing and reusing of scientific environmental models. Development using GWT, Java, and ontologies.
Spring 2019 Introduction to Computer Science (CS1) – Prepare lectures, teach labs scaffolding, coaching and mentoring students, grading, assist instructor, coordinate with other assistants
Implement a Smart City solution on Android for blind individuals using IBM's visual recognition and text-to-speech services. Joint work between The University of Texas at El Paso and Guadalajara University (Mexico)
Implement a data mining solution whose aim is to predict food disease outbreaks using Yelp · Implemented a Naïve-Bayes solution
Develop a framework to analyze current water treaty between the United States and Mexico in an interdisciplinary team
Developer of web (Java and Grails) applications using state-of-the-art frameworks · Developer of mobile applications (Android) using Eclipse and Android Studio
Administration, configuration, and maintenance of development and production servers using Ubuntu Linux (LTS)
Advisor: Natalia Villanueva-Rosales Ph.D.
Spending time with my wife and two kids keep me busy while not working on my studies.
You can find us at the local museum La Rodadora, or
feeding Modesto at the "Parque Central
Hermanos
Escobar", or at the El Paso Zoo.
I love swimming, I have been practicing it for the last 5 years which has helped me improve my butterfly
swimming style (150 meters as of March 2018), I usually go to the Rec Center.
Photography has recently caught my attention and I help my brother with his photography studio.
I volunteer my free time (which unfortunately is not much) to the neighbourhood committee where I live.


Installing Ptplot
Ptplot is distributed in several formats.
Ptplot is shipped with the java files precompiled, so you need not
recompile. However, if you are using the standalone scripts such as
ptplot
, then you may want to go through the installation
procedure so that the standalone scripts are properly localized.
If you are using Windows and you want to rebuild Ptplot or
localize the standalone scripts, then you will need to install the
Cygwin toolkit from
http://sourceware.cygnus.com/cygwin/
so that you can run /bin/sh
and make
.
If you are running Windows and do not want to install the Cygwin toolkit,
then see
Using Ptplot under Windows without Cygwin
Below are the installation instructions for Unix and Windows
with Cygwin.
- Be sure that JDK1.2 is installed, and that
javac
is in your path.
- Untar or unzip the Ptplot distribution.
- Set the
PTII
environment variable to point
to the top of the Ptplot tree. Under C-shell, one would do:
setenv PTII ~/src/ptplot3.1p1
- cd into the
PTII
directory:
cd $PTII
- Run
configure
./configure
- Run make
make
- View the applets by going starting your browser and going to:
ptolemy/plot/doc/index.htm
Ptplot is also available in several self-extracting formats
that were created with the Installshield JShield tool.
Our use of this tool is still experimental. If you have problems,
please try the tar or zip files.
Note that when you run the installer under Windows, Ptplot is
added to your Start menu under Ptolemy -> Ptplot.
Installshield limitations
Notes about building and installing
How does configure work?
configure
is a /bin/sh
script
that determines some information about your environment and
then modifies a few files.
When the configure
script is run, it reads in
mk/ptII.mk.in
and
ptolemy/plot/ptplot.in
generates
mk/ptII.mk
and
ptolemy/plot/ptplot
To get help with configure
, try
./configure --help
configure
reads in the .in
files
and substitutes strings inside the @
For example, configure
reads in
ptolemy/plot/ptplot.in
and
PTII_DEFAULT=@PTII_DEFAULT@
PTJAVA_DIR=@PTJAVA_DIR@
becomes
PTII_DEFAULT=/users/cxh/ptII
PTJAVA_DIR=/usr/java1.1
Below are the instructions for using Ptplot
if you are under Windows and you do not have the Cygwin and have
downloaded the tar or zip files.
- Set the
PTII
variable to the top-level
directory of the Ptplot tree.
C:\ptplot3.1p1> PTII=c:\ptplot3.1p1
PTII
is used by the standalone ptplot.bat
script and other scripts
- Be sure that
java
is in your path by running
java -version
- Added
%PTII\bin
to your PATH.
- Run
ptplot.in
Usually, it is not necessary to recompile the Ptplot classes, but
below are the instructions for recompiling by hand under Windows without
Cygwin.
- To compile the Ptplot Java classes, they must be in the directory
ptolemy\plot.
C:\ptplot3.1p1> cd ptolemy\plot
- set your CLASSPATH to ..\..
C:\ptplot3.1p1\ptolemy\plot>set CLASSPATH=..\..
C:\ptplot3.1p1\ptolemy\plot>echo %CLASSPATH%
..\..
- Remove the old Java files and compile them
C:\ptplot3.1p1\ptolemy\plot>del *.java *\*.java
C:\ptplot3.1p1\ptolemy\plot>javac *.java
- Run
ptplot.bat
, which reads %PTII%
C:\ptplot3.1p1\ptolemy\plot>ptplot.bat
Installing Ptplot as an applet
Ptplot includes several jar files, which are collections of
Java .class
files
-
plotapplet.jar
- .class files necessary for simple JDK1.1
browser applets - no pxgraph, no plotml.
-
pxgraphapplet.jar
- .class files necessary for simple JDK1.1
browser applets with pxgraph classes, no plotml.
Applets that use the
pxgraphargs
applet parameter
should use this jar file.
-
plotmlapplet.jar
- .class files necessary for PlotML applets -
includes com/microstar/xml and the plotml code, but does not include pxgraph,
or PlotFrame.
-
plot.jar
- The standard Ptolemy II jar file that includes the
ptolemy/plot/*.class files and the class files in plotml and compat.
Does not include com/microstar/xml or ptolemy/gui.
plot.jar
is used by the Ptolemy II build system.
-
plotapplication.jar
- .class files necessary for standalone applications - includes
com/microstar/xml, ptolemy/gui and the plotml code, but does not
include pxgraph. If
plotapplication.jar
is
present, then it is used by the standalone scripts (ptplot
etc.)
The best way to use Ptplot as an applet is to copy the appropriate
*applet.jar
file into the same directory as your applet,
and then to use the archive
applet directive.
For examples of applet html code, see the demonstrations.
Installing Ptplot as an application
Under Unix and Windows with the Cygwin toolkit,
ptplot can be run as three standalone applications:
When configure is run, it substitutes variables inside ptplot.in
and produced ptplot
. The ptplot
script
is shared between the standalone applications, ptplot
determines what name it was called with, and selects the appropriate
class accordingly.
If the ptplot
script is run,
then ptolemy.plot.PlotApplication
is run
If the ptplot
script is copied to histogram
,
then ptolemy.plot.plotml.HistogramMLApplication
is run
If the ptplot
script is copied to pxgraph
,
then ptolemy.plot.compat.PxgraphApplication
is run
Under Unix, you can use a hard link to create the histogram and
pxgraph script:
ln ptplot histogram
ln ptplot pxgraph
Under Windows, three .bat scripts are provided:
ptplot.bat
, histogram.bat
and
pxgraph.bat
Last Updated: $Date: 1999/09/01 16:50:54 $


Default XSL-FO Processor for PDF
Conversa generates XSL-FO files that can be converted to PDF format using the following
XSL
transformation engines:
- Built-in Apache FOP 2.3
- External Apache FOP
- Antenna House XSL Formatter
- RenderX XEP
Use the External Tools tab of the Preferences
dialog to configure the default XSLT engine.
External Tools
If you want to generate PDF using XSLT engines other than the built-in Apache FOP,
you must
indicate the paths to the XSLT engine executables in the corresponding text boxes.
Use the
apropriate Browse... button to locate the executables in the file
system.
XMLmind XSL-FO converter is required to generate RTF, DOCX or ODT files from a DITA
map. Enter
the location of fo2rtf.bat
(Windows) or fo2rtf
(Mac OS
X or Linux) in the XMLmind XSL-FO Converter text box or use the
corresponding Browse... button to locate the program in the file system.
Microsoft Help Compiler is required to generate Html Help (Windows help) using conversa.
Enter
the location of hhc.exe
in the Microsoft Help
Compiler text box or use the Browse... button next to it to
select the location from the file system.


Package net.sf.jasperreports.engine
Interface JRTemplate
-
- All Known Implementing Classes:
JRSimpleTemplate
public interface JRTemplate
A template that can be used by report. Templates contain report styles that can be used by reports once the template is included in the report. This allows styles to be externalized and reused across several reports. A template can in its turn include other templates, seegetIncludedTemplates()
.Style Templates
Report styles can also be defined in external style template files that are referenced by report templates. This allows report designers to define in a single place a common look for a set of reports. A style template is an XML file that contains one or more style definitions. A template can include references to other style template files, hence one can organize a style library as a hierarchical set of style template files. Style template files use by convention the *.jrtx extension, but this is not mandatory. The<jasperTemplate>
element is the root of a style template file. The<template>
element is used to include references to other template files; the contents of this element is interpreted as the location of the referred template file. The<style>
element is identical to the element with the same name from report design templates (JRXML files), with the exception that a style in a style template cannot contain conditional styles. This limitation is caused by the fact that conditional styles involve report expressions, and expressions can only be interpreted in the context of a single report definition. Each style must specify a name, and the style names have to be unique inside a style template. A report can use style templates by explicitly referring them in its definition. References to a style templates are included in JRXML reports as<template>
elements. Such an element contains an expression that is resolved at fill time to a style template instance. The template expression can only use constants/literals and report parameters. Variables and fields cannot be used because the template expressions are evaluated before the report calculation engine is initialized. If the template expression evaluates to null, the engine ignores the template reference. Style template locations are interpreted in the same manner as image or subreport locations, that is, the engine attempts to load the location as an URL, a disk file or a classpath resource. Styles from included template files can be used in the report just as local styles, that is, they can be referred by report elements or used as base styles for other (derived) styles. The style templates are loaded at report fill time, and style name references are resolved once all the templates have been loaded. If a style name reference cannot be resolved, that is, no style can be found in the loaded templates for a style name used in the report, the fill process will fail with an exception that specifies which style could not be resolved. When loading style templates and resolving style names to styles, a tree/graph of style templates is created, the top of the tree being the set of styles defined in the report. On this tree, style name references are resolved to the last style that matches the name in a depth-first traversal. For instance, if a report contains a style named Normal and the report also includes a style template that contains a style named Normal, an element referring the Normal style would use the style defined in the report. The same principle applies to the way the default style is determined: the last style which is marked as default is used as report default style. The following example illustrates how style templates can be referenced in a JRXML report definition:<jasperReport ...> <template>"report_styles.jrtx"</template> <!-- parameters can be used in style template expressions --> <template>$P{BaseTemplateLocation} + "report_styles.jrtx"</template> <template class="java.net.URL">$P{StyleTemplateURL}</template> <parameter name="BaseTemplateLocation"/> <parameter name="StyleTemplateURL" class="java.net.URL"/> ...
At the API level, style templates are represented byJRTemplate
instances. A reference to a style template in a report is represented by aJRReportTemplate
instance. Such references can be added to aJasperDesign
object via theaddTemplate(JRReportTemplate)
method, and the list of template references can be obtained by calling thegetTemplates()
method. In more complex cases, style templates can be injected into a report by using the built-inREPORT_TEMPLATES
report parameter. This parameter expects as value a collection (as injava.util.Collection
) ofJRTemplate
instances. The user report fill code can either load style templates on its own from template XML files usingJRXmlTemplateLoader
, or instantiate style template objects by any other means, and pass the dynamically loaded style template list to the report fill process using theREPORT_TEMPLATES
parameter. Style templates passed to a report via theREPORT_TEMPLATES
parameter are placed after the templates referenced in the report definition, hence styles from the parameter templates override styles with identical names from the statically referenced templates.- Author:
- Lucian Chirita<EMAIL_ADDRESS>- See Also:
JRReport.getTemplates()
,JRParameter.REPORT_TEMPLATES
,JRStyleContainer.getStyleNameReference()
-
-
Method Summary
All Methods Instance Methods Abstract Methods Modifier and Type Method Description JRTemplateReference[]
getIncludedTemplates()
Returns the templates included/referenced by this template.JRStyle[]
getStyles()
Returns the styles defined in this template.
-
-
-
Method Detail
-
getIncludedTemplates
JRTemplateReference[] getIncludedTemplates()
Returns the templates included/referenced by this template.- Returns:
- the included templates
-
getStyles
JRStyle[] getStyles()
Returns the styles defined in this template.- Returns:
- the template styles
-
-


options for destination currency were selected based on no travel restrictions (due to COVID-19) as of 16 April, 2021. Reference: Kayak.com's travel restrictions by country


anem-vignette.Rmd
This package was created to evaluate the hydraulic relationships among wells, in order to estimate the effect of a group of wells on drawdown at these wells or other wells. It it based on method of images from the analytical element modeling approach, in which the 2-dimensional characteristics of aquifers are reproduced by strategically placing wells within the domain.
This package models simple aquifer and well configurations. The boundaries of the aquifer can be specified as no flow or constant head boundaries, and the corners of the aquifer must be right angles. For fully bounded aquifers, this means that the aquifer must be a rectangle. The constant head boundaries take the head of the undisturbed aquifer, h0.
Units are designed for length dimensions given in meters (or m2), and time in seconds.
As you will see in this vignette, the package has a number of functions that are used to set up the aquifer boundaries and wells. For practical purposes, the package was designed for simple but real aquifers, and wells and boundaries of the aquifers can be imported as shapefiles and then prepared. The basic functionality of the package, described in more detail in sections below, can be seen in the following figure.
The package relies on the principle of superposition and the method of images to generate groundwater hydrodynamics, illustrated by the two figures below (see ?get_segments_behavior
and ?get_stream_function
, respectively, which give examples for generating similar plots). The principle of superposition states that, because the groundwater equations are linear, the solution to the equations can be calculated as the sum of solutions. In the example below, the drawdown of the water table is calculated as the sum of drawdown due to three individual wells.
In the method of images, wells are mirrored across aquifer boundaries to reproduce characterics of the boundary, such as no flow or constant head. The following examples demonstrate (a) how a no-flow boundary is created by mirroring a well across the boundary, and (b) how a constant head boundary is recreated by mirroring the well and inverting the pumping.
Load packages for the vignette
Aquifers in this package are characterized by:
Use the define_aquifer()
function to create a new aquifer, which has the class aquifer
. This class is essentially a list with names parameters and a separate print method.
# define aquifer bounds_df <- data.frame(bound_type=c("CH","NF","NF","NF"),m=c(Inf,0,Inf,0),b=c(0,1000,1000,0)) aquifer_unconfined <- define_aquifer("unconfined",1e-3,bounds=bounds_df,h0=100,n=0.35) print(aquifer_unconfined) #> # aquifer_type: unconfined #> # Ksat: 0.001 #> # h0: 100 #> # n: 0.35 #> # bounds: #> # A tibble: 4 x 8 #> bID bound_type m b x1 y1 x2 y2 #> <int> <chr> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> #> 1 1 CH Inf 0 0 1000 0 0 #> 2 2 NF 0 1000 0 1000 1000 1000 #> 3 3 NF Inf 1000 1000 1000 1000 0 #> 4 4 NF 0 0 0 0 1000 0 #> # recharge (undisturbed water table): #> No recharge zones
Wells are characterized by:
well_image
column)The code below Defines 8 pumping wells using random locations and arbitrarily divides wells into countries “A” and “B” using a threshold at y = 500 m. The define_wells()
function ensures that the wells have all appropriate columns, and the class of the returned object is a tibble
(which functions like a data.frame
, but has a couple bells and whistles). Also note that the radius of influence (R) is defined arbitrarily, but there is also a function to calculate this manually – see ?get_ROI
for more details.
The generate_image_wells()
function generates well images to recreate the bounderies defined by the aquifer, aquifer_unconfined
.
# define wells and well images set.seed(15) wells_actual <- define_wells(x = runif(8,0,1000), y = c(runif(4,0,500),runif(4,500,1000)), Q = -1/4, diam = 1, R = 1000, weights = 1, country = rep(c("A","B"),each=4)) wells <- wells_actual %>% generate_image_wells(aquifer_unconfined) print(wells) #> # A tibble: 68 x 11 #> wID Q R diam x y well_type well_image weights #> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <fct> <chr> <dbl> #> 1 1 -0.25 1000 1 602. 344. Pumping Actual 1 #> 2 2 -0.25 1000 1 195. 416. Pumping Actual 1 #> 3 3 -0.25 1000 1 966. 52.3 Pumping Actual 1 #> 4 4 -0.25 1000 1 651. 323. Pumping Actual 1 #> 5 5 -0.25 1000 1 367. 755. Pumping Actual 1 #> 6 6 -0.25 1000 1 989. 853. Pumping Actual 1 #> 7 7 -0.25 1000 1 815. 931. Pumping Actual 1 #> 8 8 -0.25 1000 1 254. 921. Pumping Actual 1 #> 9 9 -0.25 1000 1 602. 1656. Pumping Image (+Q) 1 #> 10 10 -0.25 1000 1 602. -344. Pumping Image (+Q) 1 #> # … with 58 more rows, and 2 more variables: country <chr>, orig_wID <int>
Plot the aquifer and wells.
ggplot() + geom_segment(data=aquifer_unconfined$bounds,aes(x1,y1,xend=x2,yend=y2,linetype=bound_type)) + geom_abline(slope=0,intercept=500,linetype="dashed") + geom_point(data=wells_actual,aes(x,y,fill=country),shape=21) + coord_equal()
Get drawdown relationships using get_drawdown_relationships()
. This function calculates the average drawdown at wells in each group defined by the column group_column
. The average is taken as the weighted mean, determined by the weights_column
. The weights were previously set equal for all wells so that the result here is a simple mean. The results show PHIii and PHIij.
drawdown_relationships <- get_drawdown_relationships(wells, aquifer_unconfined, group_column=country, weights_column=weights) drawdown_relationships
| var | pot | units | description |
|---|---|---|---|
| PHI_A_A | 1199.6188 | [m^2/cumec] | Weighted effect of pumping [cumec] in group A on discharge potential [m^2] in group A |
| PHI_A_B | 189.2822 | [m^2/cumec] | Weighted effect of pumping [cumec] in group B on discharge potential [m^2] in group A |
| PHI_B_A | 189.2822 | [m^2/cumec] | Weighted effect of pumping [cumec] in group A on discharge potential [m^2] in group B |
| PHI_B_B | 1342.9247 | [m^2/cumec] | Weighted effect of pumping [cumec] in group B on discharge potential [m^2] in group B |
The hydrodynamics of the aquifer can be mapped by obtaining gridded heand flow using the get_gridded_hydrodynamics()
function. The function takes as input the wells, aquifer, and grid dimensions for head and flow. It returns a list
object with data.frames for head and flow, which can then be plotted.
gridded_1 <- get_gridded_hydrodynamics(wells,aquifer_unconfined,c(20,20),c(8,8)) ggplot() + geom_raster(data=gridded_1$head,aes(x,y,fill=head_m)) + geom_contour(data=gridded_1$head,aes(x,y,z=head_m),color="white",alpha=0.3) + geom_segment(data=gridded_1$flow,aes(x,y,xend=x2,yend=y2), arrow = arrow(ends="last",type="closed",length=unit(1,"mm")),color="black") + geom_segment(data=aquifer_unconfined$bounds,aes(x1,y1,xend=x2,yend=y2,linetype=bound_type)) + geom_point(data=wells %>% filter(wID==orig_wID),aes(x,y),shape=21) + coord_equal() #> Warning: Removed 2 rows containing missing values (geom_segment).
The function get_bounds_behavior()
is a helper function to generate hydraulic properties at the boundaries. It obtains hydraulic head and the flow normal to the boundaries by setting boundaries to segments and using get_segments_behavior()
. Normal flow is defined such that positive flow has some component in the x-direction (the y-direction depends on the normal vector for the boundary). The function plot_bounds_behavior()
is a wrapper around get_bounds_behavior()
, and it can be used to quickly compare the hydraulic head along the boundaries and flow across the boundaries under two scenarios:
bounds_behavior <- plot_bounds_behavior(wells,aquifer_unconfined) gridExtra::grid.arrange(bounds_behavior$p_h,bounds_behavior$p_f,nrow=1)
Finally, the function plot_bounds_behavior
also includes the raw data of head and flow used to create the above plots (bounds_behavior$bounds_behavior
), as well as a summary of these values which includes mean head on each of the boundaries and mean flow as the mean of the absolute value of flow normal to each boundary (bounds_behavior$table
). To numerically check that the boundaries are working as expected, we can print bounds_behavior$table
:
| bound | Mean flow, images | Mean flow, no images | Mean head, images | Mean head, no images |
|---|---|---|---|---|
| 1 CH | 1.07e-05 | 3.9e-06 | 100.00000 | 98.64171 |
| 2 NF | 0.00e+00 | 5.4e-06 | 95.01699 | 97.82476 |
| 3 NF | 0.00e+00 | 5.7e-06 | 93.32580 | 97.81516 |
| 4 NF | 0.00e+00 | 4.2e-06 | 96.37611 | 98.55836 |
Background flow is parameterized by defining “recharge” in the aquifer. Recharge can be defined as a constant flow (F) or a recharge divide (D). In both cases, flow is defined as m3 / m-s, in the direction of the recharge vector. Recharge is therefore defined by specifying:
See ?define_recharge
for more details.
# Define recharge for type "D" recharge_params <- list(recharge_type="D",recharge_vector=c(500,500,501,501), flow_main=1e-3,flow_opp=2e-3,x0=0,y0=0) # Define bounds as "PB" -- pervious bounds, which have no effect (other than to define output grid) bounds_recharge <- define_bounds(data.frame(bound_type=rep("PB",4),m=c(Inf,0,Inf,0),b=c(0,0,1000,1000))) aquifer_recharge <- define_aquifer("confined",1,h0=0,z0=1,n=0.35,recharge=recharge_params,bounds=bounds_recharge) gridded_2 <- get_gridded_hydrodynamics(wells_actual,aquifer_recharge,c(20,20),c(8,8))
The results can then be plotted, just as above:
The package implements particle tracking in two ways: (1) tracking individual particles using track_particles
and (2) estimating capture zones of wells using get_capture_zone
, which initializes particles in the vicinity of wells and tracks them in reverse. Here we use get_capture_zone
on the previous aquifer to generate particle tracking away from wells.
# wells <- wells # wells[4,"Q"] <- 0.25 well_particles <- get_capture_zone(wells,aquifer_unconfined,t_max=365,n_particles=4)
gridded_3 <- get_gridded_hydrodynamics(wells,aquifer_unconfined) ggplot() + geom_raster(data=gridded_1$head,aes(x,y,fill=head_m)) + geom_contour(data=gridded_1$head,aes(x,y,z=head_m),color="white",alpha=0.3) + geom_segment(data=aquifer_unconfined$bounds,aes(x1,y1,xend=x2,yend=y2,linetype=bound_type)) + geom_path(data=well_particles,aes(x,y,group=i,color=as.factor(wID)),show.legend = FALSE) + geom_point(data=wells_actual,aes(x,y,color=as.factor(wID)),shape=21,show.legend = FALSE) + coord_equal()
The basic functionality of this package is implemented in a Shiny application, which can be run by calling anem_app()
or accessed online at shinyapps.io. The Shiny application provides an GUI for setting aquifer properties, drawing boundaries, defining recharge, adding wells, and tracking particles. It also displays results directly in the app. You can also download scenarios created on anem-app and import them into R. To do so, check out ?import_app_rds
from this package to learn more.


2 writes to _cancelOperationDisposed
Microsoft.Management.Infrastructure.CimCmdlets (2)
CimSessionProxy.cs (2)
1543
if (Interlocked.CompareExchange(ref this.
_cancelOperationDisposed
, 1, 0) == 0)
1568
Interlocked.Exchange(ref this.
_cancelOperationDisposed
, 0);
1 reference to _cancelOperationDisposed
Microsoft.Management.Infrastructure.CimCmdlets (1)
CimSessionProxy.cs (1)
1542
DebugHelper.WriteLogEx("CancelOperation Disposed = {0}", 0, this.
_cancelOperationDisposed
);