text:
Home Addiction Personality Disorders – Types, Risk Factors and Help
Personality Disorders – Types, Risk Factors and Help
By American Addiction Centers Editorial Staff
Types Of Disorders
During informal discussions, the word "personality" is often used to describe behavior. A person who is kind to animals, for example, might be called a "gentle personality." In other words, it's common to think of the way the person behaves as an adequate description of that individual's personality. In 1987, researchers published an article in the British Journal of Psychiatry, hoping to clearly define what the word "personality" meant in a health care setting.
They wrote that personality goes beyond the way the person might act or seem to others. Instead, personality describes a person's mental processes, their reactions to outside stimuli, and the way they think about themselves and the world around them. In short, "personality" could be used to describe what it's like to be that person.
Describing someone's personality means describing what it's like to think, feel and act like that person.
Understanding this word is key to understanding personality disorders. People who have personality disorders don't simply have problems with behavior. Their issues go beyond simple acts. Instead, people with personality disorders have a rigid and inflexible way of thinking and viewing the world around them, and these thoughts and views lead people with personality disorders to act in inappropriate ways. They may face significant disruptions in their social lives as a result.
Types of Personality Disorders
People with personality disorders have unhealthy ways of thinking that persist, no matter what the situation is. These disorders run so deep that the people believe that they are normal and those around them are abnormal. They may not believe they have any problems whatsoever. People with personality disorders tend to fall into one of three categories, based on their symptoms.
People with Type A personality disorders tend to show odd or eccentric behaviors some or most of the time. Specific disorders in the Type A group include:
Paranoid personality disorder. These people remain convinced that those around them are lying or cheating in some way. They interpret every action as some sort of betrayal, and they may act out in hostile and angry ways, as they believe their rights are always being violated in some way.
Schizotypal personality disorder. Acting, dressing and talking in strange ways are common, and these people may also believe that they have magical powers. They may be extremely anxious in social situations, and they may retreat to their own worlds for protection.
Schizoid personality disorder. These people are distrustful of others, so they keep their own council. They may seem cold, distant and logical with few social connections. In fact, they're fearful of other people and they avoid sharing their thoughts. They may prefer to daydream instead.
People with Type B personality disorders tend to appear overly dramatic or emotional to those around them. Specific disorders in this group include:
Antisocial personality disorder. These people may have no respect for others, and they may persistently lie, cheat, steal and commit violent acts. They may never feel guilt about these actions. They may seem irritable, violent and brash because they act on every impulse without considering the effect it might have on others.
Borderline personality disorder. Fluctuations in mood are common in people with this disorder, and they may move from extreme attachment to others to absolute abandonment of them in the flick of an eye. Even minor misunderstandings can turn into major arguments, resulting in stony silences. These people may also become suicidal in order to manipulate others into paying attention to them.
Histrionic personality disorder. Someone with this condition will seem very emotional, laughing and crying at inappropriate times and demanding a large amount of attention from others. They may be overly concerned about their appearance, and they may be considered dramatic or reactionary.
Narcissistic personality disorder. People with this disorder truly believe that they are better than others. They may expect constant attention and adoration from all whom they meet. If they don't receive this response, they may resort to manipulation in order to get it.
People with Type C personality disorders are, in general, anxious and fearful. Specific disorders include:
Avoidant personality disorder. These people are extremely shy and timid, and they may be incredibly sensitive to criticism. They may crave the attention of others, but be far too scared to ask for that attention.
Dependent personality disorder. A need to be loved and accepted characterizes this condition, and people may accept abuse rather than be alone. They may be unable to care for themselves or make decisions, and they may ask for constant reassurance from those they love.
Obsessive-compulsive personality disorder. These people rely on order and cleanliness to keep them safe, and they may be incredibly inflexible about the rules they set. Since they can't control everything in their lives, they may feel increased anxiety most, or all, of the time.
These descriptions may seem overly negative. In fact, it might be easy to wonder why anyone would choose to spend time with someone who has a personality disorder. It's important to remember that these people have a true and definable illness that makes them act the way they do. They don't choose to be hurtful or mean. They simply cannot act any other way due to the influence of the diseases they have. Only through getting help can they put these behaviors behind. Blaming them or isolating them will not help them get better. Only therapy will do that.
Prevalence and Risk Factors
According to the National Institute of Mental Health (NIMH), 9.1 percent of adults have some form of personality disorder.
Personality disorders don't seem to discriminate based on sex, as equal amounts of women and men are affected. NIMH goes on to say that less than 40 percent of people with personality disorders are currently receiving treatment for their condition. In other words, more than half of people with personality disorders are untreated and struggling with their conditions on their own. It's unclear why so many people are not getting the help that they need, but it's possible that these conditions are so isolating that those affected live without any outside influence that could provide needed assistance.
According to a study published in the American Journal of Psychiatry, these factors increase the risk of developing a personality disorder:
Being Native American or of African ancestry
Having a low income group
Being a young adult
Being divorced, widowed or never married
It's possible that chaotic childhoods contribute to personality disorders. Living through a significant amount of abuse or neglect could allow a person to develop a distorted personality, as the person learns to develop abnormal modes of thinking and behaving in order to live through the situation. Children are rarely diagnosed with a personality disorder, however, as many children experiment with personality as they grow. It can be difficult for experts to determine what is basic experimentation and what is true dysfunction. For this reason, most cases of childhood personality disorders go undiagnosed, and when the child becomes an adult, the problems truly come to light.
Hazards of Personality Disorders
People who have personality disorders have serious difficulty in their relationships. They often simply cannot understand other people, and other people cannot understand them. They may become incredibly isolated as a result, unable to form meaningful relationships and succeed in their lives.
People who develop psychotic behaviors as a result of their personality disorders may face imprisonment. Some people are arrested over and over for their behaviors, and they may be unable or unwilling to stop the actions that cause the arrest. They may be true losers in the judicial system, as they may seem unable to change and unwilling to show remorse for their actions.
According to a study published in the Archives of General Psychiatry, people who have personality disorders are at increased risk for alcohol and marijuana addiction. In addition, of those studied, more than half were addicted to nicotine. Alcohol, marijuana and cigarettes can all be incredibly detrimental to health, and some people can even die from their addictions.
Living with someone who has a personality disorder can also be very distressing. Often, these people can be cruel and manipulative, likely to distort situations and be abusive. Their moods can change quickly. They can say and do things that are confusing at best and dangerous at worst. It's not the sort of living situation that is beneficial for anyone.
Help Is Available
It can be easy to judge people with personality disorders as damaged and beyond hope. In fact, the opposite is true. Personality disorders can often be treated through a combination of medications and therapies designed to correct the rigid thinking and help the person understand the needs of others. Therapies may take years to complete, but they can be helpful. Reading up on personality disorders is a good first step. Scheduling an appointment with a qualified mental health counselor is an excellent next step to take. Make the call today.
Naperville, Illinois 60540
Recovery Centers of America at Devon
235 W Lancaster Ave
Devon, Pennsylvania 19333
American Addiction Centers Editorial Staff
The editorial staff of luxury.rehabs.com is comprised of addiction content experts from American Addiction Centers. Our editors and medical reviewers have over a decade of cumulative experience in medical content editing and have reviewed thousands of pages for accuracy and…
Borderline Personality Disorder Signs and Treatment
Choosing the Best Exclusive Schizoid Personality Disorder Treatment Center
Choosing the Best Private Dependent Personality Disorder Treatment Center
Choosing the Best Private Schizotypal Personality Disorder Treatment Center
Finding the Best Private Antisocial Personality Disorder Treatment Facility
Getting the Best Narcissistic Personality Disorder Treatment Center
Histrionic Personality Disorders
All Addiction Articles
Exclusive Treatment Center Options for Crystal Meth Addiction
Drug Abuse Symptoms, Facts, and Statistics
Finding the Right Addiction Treatment Facility
Finding a Eating Disorder Treatment Center
Heroin Addiction Signs, Intervention and Treatment
How do I pay for treatment Out of Pocket Insurance, other?


text:
White Light (Luz Blanca) es el sexto álbum de estudio de la banda irlandesa The Corrs. Supuso el regreso del grupo diez años después del álbum de estudio Home, tras haber llevado a cabo sendos proyectos en solitario Andrea y Sharon.

Álbum
En el mes de septiembre The Corrs reapareció en público por primavera vez desde 2005, en los conciertos Live in Hyde Park de Londres. El nuevo álbum fue editado el 27 de noviembre. El adelanto del trabajo fue "Bring On The Night", aunque su videoclip no se publicaría hasta el 1 de diciembre. A éste le siguió como sencillo "I Do What I Like". Además del citado videoclip, ambas canciones contaron además con video oficial rodado en Church Studios.

El título del álbum se extrae de una de sus canciones, "White Light", inspirada por el Club de los 27 y más concretamente por Amy Winehouse. El tema "Gerry's Reel" es una canción instrumental que hace referencia a Gerry Corr, padre de los hermanos Corr, fallecido en 2015. Por otro lado, Ellis Island hace referencia a la Isla de Ellis, cerca de la costa neoyorquina, en la que pasaron la cuarentena miles de inmigrantes irlandeses antes de entrar en América.  Kiss Of Life fue coescrita con Natasha Bedingfield y Unconditional con John Shanks.

Gira
En enero de 2016 dio comienzo el "White Light Tour" que les llevó a varios países y la participación en festivales como el Isle Of Wight y el Intercéltico de Lorient.

Canciones

 I do what I like (Hago lo que me gusta) - 3:40
 Bring on the night (Desata (haz salir) la noche) - 4:17
 White Light (Luz blanca) - 3:16
 Kiss of life (Beso de vida) - 4:00
 Unconditional (Incondicional) - 3:55
 Strange Romance (Romance extraño) - 3:42
 Ellis Island (Isla de Ellis) - 5:05
 Gerry's Reel (Reel de Gerry) - 3:21
 Stay (Quédate) - 3:10
 Catch me when I fall (Cógeme cuando caiga) - 5:30
 Harmony (Armonía) - 4:36
 With me stay (Conmigo quédate) - 3:43

Lista de ventas

Referencias

Álbumes de Irlanda de 2015
Álbumes de The Corrs

redpajama_set_name: RedPajamaWikipedia


text:
Perpetual Contract
BingX Updates
BingX Research
New Launch Analysis
Tech Giants Announce the Establishment and Launch of the Metaverse Standard Forum
eBay Acquires NFT Marketplace, KnownOrigin
What is Optimism – Optimistic rollups, tokenomics and problems with the airdrop
Published by BingX Official at 2022-06-23
BingX Insights
1 What is Optimism?
2 What are Optimistic rollups?
3 How to use Optimism
4 Tokenomics of Optimism
5 Problems with the first airdrop
Join the Trading Community: Learn & Earn with BingX.
Ethereum has been the second largest cryptocurrency for quite some time. Without any doubt it is also the most recognised and used cryptocurrency that has a huge amount of community supporting it, right after Bitcoin. Moreover, it also has huge amounts of tokens, networks or projects that are built on it. And while this might seem like a positive, it also comes with a cost and that is transaction fees.
Transaction fees on Ethereum are one of the highest there are in the crypto world. This is especially due to the huge amounts of transactions and lack of scalability solutions. Yet, one of those solutions has seen a pretty decent rise in popularity in the recent months and that is Optimism.
What is Optimism?
Optimism is one of the new layer-2 scaling solutions that is supposed to help Ethereum to lower its transaction fees and thus the overall pressure on the network. It uses a technology called Optimistic rollups, which bundles large amounts of transaction data into smaller batches that are easier to "digest." This should deliver not only much lower cost of transactions, but also much higher speed of them.
Total Value Locked in Optimism (USD), Source: defillama.com
Optimism is one of many layer-2 solutions that is currently trying to help Ethereum with its gas fees, scalability and congestion. In fact, after Arbitrum, which is the biggest layer-2 solution built on Ethereum and currently has a total locked value of around 1.3 billion dollars, Optimism is currently the second biggest layer-2 solution with a locked value of about 355 million dollars.
Optimism was created in June 2019, with the first testnet being released in October 2019. Yet, the alpha mainnet was launched in January 2021. By October 2021 the version that was compatible with Ethereum Virtual Machine was released, with the open mainnet launching only 2 months after that in December 2021.
Interesting metrics of Optimism connected to its usecase, Source: optimism.io
What are Optimistic rollups?
The technology used (Optimistic rollups) was cleverly named due to the way it works. It rolls up or bundles the data of vast numbers of transactions all together and posts it as one transaction on layer-1, the Ethereum mainnet. These bundled transactions can be anything from payments, to token swaps or even NFT mints.
The logic of this bundling is pretty simple: to lower the transaction costs. The fees are split to all the users whose transactions were rolled up together. Thus, instead of all the users having to pay high transaction fees for hundreds of transactions, they essentially pay one fee that is distributed across those who were involved. That is a pretty neat and convenient way of not only lowering the costs, but also the pressure on the network.
But why is it called an Optimistic rollup? They are called optimistic because all the transactions are assumed to be valid until they are proven false, something very similar to innocent until proven guilty. While all the transactions are initially taken as valid, there is a time window during which the potentially invalid transactions can be challenged.
This would be done through something called "fraud proof." Optimism reimburses the gas that is needed to run the computations connected to the fraud proofs, hence, incentivising the users to protect the network from invalid or malicious transactions.
How to use Optimism
First of all, it needs to be mentioned that Ethereum and Optimism are technologically fairly similar, which means that any ERC-20 token that is compliant with the Ethereum token standards can be used on Optimism.
Using Optimism is similar to other layer-2 solutions or platform projects built on Ethereum. While it can be complex for some, for others, more experienced cryptocurrency users, Optimism can hardly be seen as somewhat difficult to use. For starters, the user will have to deposit their ETH or any other ERC-20 token (as Optimism can process both), to the Optimism token bridge, to allow for transactions of ETH on Optimism.
Depositing ETH or ERC-20 token to Optimism, Source: beincrypto.com
The deposit of tokens would need to come through Optimism Gateway, which should be connected to a Web3 wallet such as MetaMask and should not take longer than half hour. Yet, there is still the need to check for the Optimistic rollup, which is a week-long time window, during which the funds can be challenged.
But once they are deposited to Optimism, they can be easily used within all the supported decentralised applications. These can be all the dapps that support Ethereum. For instance, Uniswap will allow users to trade via Optimism to cut the price of the fees, once the users select Optimism as a preferred network to use.
Tokenomics of Optimism
While the mainnet of Optimism was released in December 2021, the Optimism token, OP, was not released until very recently. The OP token was only released on the 31st of May as an airdrop. About 231,000 addresses were eligible to claim more than 214 million OP tokens for free solely based on a history snapshot. During this first airdrop, only 5% of the total supply was released. The total supply is about 4.25 billion tokens, which means that more than 95% of the tokens have yet to hit the market.
This airdrop was only introduced in April 2022 in this blog post. Yet, Optimism has revealed that it is only the first of many. But the team decided not to disclose any other terms and days of when the following airdrops should happen. This is commonly known practice in the cryptoworld, since it incentivises the users to start using the network as soon as possible.
Distribution of the total supply of Optimism token, Source: optimism.mirror.xyz
It is expected that Optimism will release the next airdrop date with eligibility criteria for those who want to participate. Yet, it can be expected that this will be based on snapshots from the past, meaning that at the time of the announcement of the airdrop the users will not be able to participate.
For instance, imagine that at the end of June, Optimism releases a statement that new airdrops will happen at the beginning of July. Yet, they will specify that the participants in this airdrop will be only those, who had their wallets, addresses or made transactions before 15th of June.
Thus, the snapshot will be back dated to 15th of June, giving no chance for anyone new to participate and take advantage of the recent announcement. This clearly incentivizes the users to join the network as soon as possible, so that they are eligible for the next airdrop, should they be interested.
Problems with the first airdrop
While it may look very interesting and encouraging to receive "free money" in the form of the airdrop just for using some network, it needs to be clearly stated that these tokens are of a high risk. And this was very visible during the first airdrop of Optimism, which did not go according to plans at all.
During the initial airdrop, some of the users were able to claim tokens earlier than others. This gave them a chance to dump those tokens into the market with lower supply, thus selling at the best possible prices. Those who were then late and received the tokens after the price was falling due to the selling pressure from the side of "early-receivers" decided to cut their losses and sell. This created even more selling pressure and congested the network, bringing another weakness of Optimism to the light.
The Optimism team admitted that they made mistakes and in retrospect showed where they happened and what they will do in the future to minimise those mistakes. They for instance showed that they were not ready to face such a volume, a mistake that would push the price of the token to its all time lows on May 31st.
Nevertheless, the team behind the token is dedicated to erase this mistake by improving their airdropping protocol with the next iterations of airdrops.
Adjusting for all the possible information connected to Optimism that are publicly available, one must clearly see that this token is very similar to others in that it tries to solve scalability problems connected to Ethereum. So far, it seems that Optimism is doing a pretty decent job with solving those problems, but it comes with its costs. Thus, as always, investors in this industry need to be very careful about where they put their money and how they adjust for the risks connected to their investments.
Disclaimer: BingX does not endorse and is not responsible for or liable for any content, accuracy, quality, advertising, products, or other materials on this page. Readers should do their own research before taking any actions related to the company. BingX is not responsible, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with the use of or reliance on any content, goods, or services mentioned in the article.
Top 5 Cryptocurrencies to Watch Out For in 2023
Core Scientific Plans to Sell Bitmain Coupons for $6.6 Million
SushiSwap to Launch Decentralized Perpetual Futures Exchange on Sei Network
What are Wrapped Tokens – WBTC and WETH
Tesla's Q4 report: Position on Bitcoin Remains Unchanged
All You Need to Know About Lens Protocol (LENS)
EU Lawmakers Propose Taxing Crypto Assets
Announcement BingX Charity BingX Daily BingX Insights BingX Research BingX Updates Blockchain Campaign Events Hot news Important Announcements Insights Monthly Review New Launch Analysis Project Report The Beginner's Guide
2022 ©BingX Social Trading Platform: Trading Made Easy

redpajama_set_name: RedPajamaCommonCrawl


Paytm Movies is the official 'Ticketing Partner' of Tubelight and Salman Khan Films.
Paytm Movies is gearing up for one of the year's most awaited movies – Tubelight. The company expects the movie to be one of the highest grossers of 2017 and has launched advance bookings across India.
Paytm Movies is the official 'Ticketing Partner' of Tubelight and Salman Khan Films. Consumers can buy movie vouchers that can be redeemed while booking tickets; select movie-goers will get an opportunity for an exclusive meet-and-greet with Salman Khan and digital autographed posters and merchandise.
Directed by Kabir Khan, Tubelight stars Salman Khan and Sohail Khan as brothers. Set against the unfortunate Indo-Sino War of 1962, the movie also features Chinese female actor Zhu Zhu, child actor Martin Ray Tangu and late Bollywood prodigy Om Puri.
Those interested can choose to book tickets at any of 3500 screens across 550 cities. The company's QR code-based scan-and-book offline ticketing systems will aim to help ease queues outside booking counters once the movie is launched on June 23.


This article original appeared on BXTimes.com.
The Bronx River Alliance hosted the exhilarating Bronx River Greenway 5K Canoe Challenge, New River House Tour and Starlight Park Event on Saturday, July 15. Teams paddled down the river as they competed for the title of 2017 Bronx River Canoe Champion while raising funds to continue making canoe adventures on the Bronx River possible for local families.
The Bronx River Alliance is partially funded by Hurricane Sandy coastal resiliency relief and federal funds.


text:
Q: CountDownTimer on version 4.4.2 - 4.4.4 can not be cancelled I have a CountDownTimer which works perfectly on every android version except 4.4.2 - 4.4.4. Does anyone know why this is happening? The way i am stopping the timer it is when it goes <= 0 .
    mTimerRemaining = new CountDownTimer(10000, 1000) {

        public void onTick(final long millisUntilFinished) {

            mTimeRemainingNum -= 1000;

            if(mTimeRemainingNum <= 0) {
                mTimerRemaining.cancel();
            }
        }

        public void onFinish() {

         // On Finish doesn't work
        }
    };

    mTimerRemaining.start();

A: That is odd. Have you considered using a Handler instead?
Example of use:
private final int interval = 10000; // 10 secs
private Handler handler = new Handler();
private Runnable runnable = new Runnable(){
    public void run() {
        // your code here
    }
};
handler.postDelayed(runnable, interval);

Please, let me know if it works for you :)

A: Create a CountDownTimer class in your project
package your.package;

public abstract class CountDownTimer {

    private final android.os.CountDownTimer countDownTimer;

    private boolean isCancel = false;

    public CountDownTimer(long millisInFuture, long countDownInterval) {
        countDownTimer = new android.os.CountDownTimer(millisInFuture, countDownInterval) {
            @Override
            public void onTick(long millisUntilFinished) {
                if (isCancel) {
                    return;
                }
                CountDownTimer.this.onTick(millisUntilFinished);
            }

            @Override
            public void onFinish() {
                if (isCancel) {
                    return;
                }
                CountDownTimer.this.onFinish();
            }
        };
    }

    public final CountDownTimer start() {
        isCancel = false;
        countDownTimer.start();
        return this;
    }

    public final void cancel() {
        isCancel = true;
        countDownTimer.cancel();
    }

    public abstract void onTick(long millisUntilFinished);

    public abstract void onFinish();
}

You just change the import from android.os.CountDownTimer to your.package.CountDownTimer
CountDownTimer class is Disposable.

redpajama_set_name: RedPajamaStackExchange


Connecting Google Search Console Data to Your Keylime Toolbox Account.
Keylime Toolbox gathers queries and related SEO data from Google's API. To surface the most query data possible, Keylime Toolbox processes not only top-level domain data, but also data for all levels of subfolders and then aggregates and deduplicates the data for the most complete view possible.
Add your site to Google Search Console (if it isn't added already) and add the Keylime Toolbox API as a user (queries@keylimetoolbox.com). Add all major subfolders and subdomains to Google Search Console.
The bad news: it's a little tedious to add all the subfolders.
The great news: once you've done that, Keylime Toolbox can surface substantially more query data (typically significantly more than is available in analytics).
You can always start with just your root domain and see how much "not provided" query data Keylime Toolbox is able to recover, and then add subfolders later.
www.example.com/folder2/If parts of your site are secure and other parts are not secure, make sure that you've added both the http and https versions of the site. If your site includes subdomains, make sure those are added as well (and any subfolders of those subdomains).
Log into Google Search Console with an account that has ownership access to your domain/subdomains. Select 'Add or remove users' from the 'Manage site' menu located to the right of each domain and subdomain.
Click 'Add a New User' in the upper left corner and add queries@keylimetoolbox.com with either restricted or full permission.
Email support@keylimetoolbox.com with a list of the subfolders you have added.
Google keeps 90 days of data stored for all domains so Keylime Toolbox can begin providing analytics for the domain as soon as we have access. However, Google only begins storing data for subfolders when they are added, so data collection and storage in Keylime Toolbox begins on the date the subfolders are added. You'll begin to see comprehensive query data from the aggregation of this subfolder data about a week after the subfolders are added.


text:
Gold extraction at the Gwynfynydd Mine, North Wales, United Kingdom: a case study of environmentally sustainable mineral processing within a national park
Dominy, S.C., and Phelps, R.F.G. (2002) Gold extraction at the Gwynfynydd Mine, North Wales, United Kingdom: a case study of environmentally sustainable mineral processing within a national park. In: Green Processing 2002 (4/2002) pp. 225-232. From: International Conference on the Sustainable Processing of Minerals 2002, 29-31 May 2002, Cairns, QLD, Australia.
View at Publisher Website: https://www.ausimm.com.au/publications/p...
The former Gwynfynydd gold mine is located within the heart of the Snowdonia National Park, North Wales, United Kingdom. The black shale-hosted quartz reefs have intermittently produced more than 50 000 ounces of gold since 1863. Its most recent period of operation by Wclsh Gold PLC was between 1992 and 1999 when it extracted 10 000 tonnes annually from a total resource base of 180 000 tonnes. A historical mining grade of 15 grammes/tonne was recovered from the Chidlaw Reef on which all production was based. Erratically distributed gold pockets hosted in the footwall zone of a 3 - 6 111 wide quartz reef characterise the mineralisation. The gold exhibits a high-nugget effect and as a consequence the accurate determination of tonnage and grade was difficult. Production was undertaken by overhand shrinkage sloping. Due to its location within a National Park certain environmental constraints were placed on the operators. The principal requirement or planning permission was that processing should take place above ground and not involve chemicals. As a result, an underground mill based on physical separation methods was constructed in response to these environmental constraints. Much of the mine discharge is related to the flow of rainwater through the workings from surface openings on the reefs. Discharge from the underground milling facility was enhanced in various metals, particularly zinc, though was reduced to legally acceptable levels using liming tanks prior to discharge into the River Muwddach, The company was required to monitor and treat all water discharged from the mine before it reached the river. The mine closed in l 999, since which time a tip re-processing has continued as part of an environmental remediation and gold supply program.
04 EARTH SCIENCES > 0403 Geology > 040307 Ore Deposit Petrology @ 100%
84 MINERAL RESOURCES (excl. Energy Resources) > 8402 Primary Mining and Extraction Processes of Mineral Resources > 840205 Mining and Extraction of Precious (Noble) Metal Ores @ 100%


LAOAG CITY, Jan. 12 –- The provincial government has provided free shuttle service for passengers arriving at the Laoag International Airport without an arranged vehicle to take them to the city proper.
The shuttle bus is deployed at the airport to fetch passengers arriving at anytime of the day through the three domestic carriers Philippine Airlines, Cebu Pacific and Air Philippines.
The bus would be stationed at the airport from the time the airlines arrive during their morning flights and in the evening.
Mindful of the inconvenience that passengers go through each time they travel to this city, Ilocos Norte Gov. Imee Marcos thought of dedicating one Sirib Bus to the airport to service those who do not have an arranged vehicle to fetch them.
The shuttle service is available to passengers whether local or foreigner.
At present, public transportation provided by jeepneys plying the Laoag-Gabu route is the only means to reach and leave the airport. Some passengers who are on short stay in the city and those who could not arrange a private vehicle would hire a tricycle ride to and from the airport.
The province started providing free shuttle ride to the airport during the Holidays when droves of balikbayans and tourists came to Ilocos Norte to spend Christmas.
Milagros Gonzales, provincial chief of the Department of Tourism, said officials are expecting tourist arrivals in the province to double this year due to a favorable tourism climate.
"The presence of more tourist attractions and facilities in Ilocos Norte is also a good indicator of robust tourism activity," she said.


text:
Robert Martin has stood for more than 60 years as a visionary development company whose diverse portfolio includes office, retail and commercial space. Today, the company's holdings include 200 real estate properties and 5 million square feet of development space across the tri-state region.
Office Parks . Industrial . Residential
Robert Martin Company, LLC is a leading real estate investment and development firm based in Westchester County, NY
Robert Martin Company, LLC
100 Clearbrook Road
Elmsford, NY 10523
© 2019 by Robert Martin Company
ROBERT MARTIN COMPANY
Investment . Development. Management
DRIVING GROWTH, DELIVERING VALUE
Robert Martin Company is a fully-integrated real estate company with a proven track record of successfully acquiring, developing, and managing investment properties throughout its influential history. For over 60 years, Robert Martin Company has been paving the way for innovation, improvement and expansion in the communities it serves.
60 Years of Distinguished History
Founded in 1957, by Robert F. Weinberg and Martin S. Berger, Robert Martin Company, LLC has a long, distinguished history in real estate. The Company and its partners have developed and acquired over 20 million square feet of property
SHAPED BY SERVICE, DRIVEN BY EXCELLENCE
Robert Martin Company has received over 50 prestigious awards and recognitions for its work and service.
Notable awards include an induction into the Westchester Business Council's Hall of Fame, receiving the March of Dimes Real Estate Award for outstanding community service and its founders recognized as two of the top 10 most influential people in Westchester by The Journal News.


Keep your devices charged when you're on the go with this Platinum car charger. It conveniently fits in a cigarette lighter and charges with a USB port to work with a variety of devices. This Platinum car charger uses Qualcomm Quick Charge 2.0 technology to reduce charging time for efficiency.
Provides reliable and convenient charging for your existing devices.
Up to four times faster compared to conventional USB charging.
Offers up to 3A output energy for quick and safe charging (5V/3A, 9V/2A, 12V/1.5A).
Can charge any USB device.


text:
National Wetland Centre
Wetland Trails
Value Wetlands
Types of Wetlands
Ramsar Wetlands
Plan a Wetlands Event
Restore Wetlands
Visit Wetlands
Sponsor a Region
More ways of connecting with us
Getting Kiwis
into wetlands
National Wetland Trust of New Zealand
The National Wetland Trust (NWT) – is a nonprofit organisation established in 1999 to increase the appreciation of wetlands and their values by all New Zealanders. We are planning a Wetland Discovery Centre at Rotopiko/Lake Serpentine where visitors can learn about wetlands and experience their special qualities.
Our other aims are to:
Increase public knowledge and appreciation of wetland values
Increase understanding of wetland functions and processes
Ensure landowners and government agencies commit to wetland protection, enhancement and restoration
Find out what's on for World Wetlands Day.
See some stunning New Zealand wetlands in our gallery.
Why Wetlands
Wetlands are vital in maintaining healthy ecosystems.
You want clean water? Flood or tsunami protection? How about locking up carbon to protect us from climate change?
It's the wetlands that do these for us..
Visiting Wetlands
Wetlands are wonderful places to visit. As well as their great natural beauty they provide opportunities for walking, boating, canoeing, bird watching and fishing. To help people visit wetlands the NWT has produced a series of wetland trails and is building an online directory of those you can safely visit.
In 1971, the value of wetland sites around the world was formally recognised at the signing of a Wetland Convention in the Iranian town of Ramsar. To date, this is the only international convention on an ecosystem type. The anniversary of the Convention's signing is celebrated on World Wetlands Day, February 2nd every year.
Despite their great natural wealth, wetlands are still largely a forgotten and under-valued habitat. Over 90 percent of New Zealand's wetlands have been drained or filled. The National Wetland Trust (NWT) is working to reverse this trend, and to increase knowledge, appreciation and understanding of the value of wetlands.
Wetlands are vital in maintaining healthy ecosystems. They improve water quality and reduce flood risks, provide biodiversity and play an important role in managing climate change.
The NWT is planning a Wetland Discovery Centre at Rotopiko / Lake Serpentine. It will be a native wildlife haven with research and educational facilities, wetland gardens and heritage trails.
Type of Wetlands
Wetlands are permanently or intermittently wet areas, shallow water, and land water margins that support a natural ecosystem of plants and animals adapted to wet conditions
Here you will find a range of excellent resources for learning about, restoring or teaching about New Zealand wetlands.
We run national conferences every two years. We want to see as many wetland events being run across the country as possible, getting people into these uniquely beautiful environments. If you have an idea for a wetland event, please let us know.
Our trustees and members are at the forefront of cutting edge wetland science. We also encourage students to research wetlands through our Golden Plover awards.
Stay informed about our wetlands with the latest news including information on wetland restoration projects.
Our goals are urgent - over 90% of New Zealand's wetlands have been lost. There's much to do to protect and restore wetlands, and we need your support now more than ever.
We are always looking for new ways to partner with organisations that build long-term relationships focused on our mutual goals. Let's talk about what we could achieve together.
National Wetland Trust, c/o Box 177
Pukekohe 2340, New Zealand
© National Wetland Trust of New Zealand
Website Design by Digital Stream


Purpose Task Stool - Seating - HON | Arthur P. O'Hara, Inc.
Adaptable like no other chair, Purpose's sleek design works everywhere, and with a versatile selection of fabric and finish options, it also fits anywhere. With two neutral base choices and a dynamic collection of upholstery selections, it's easy to create the right look for any space. Whether using the arm or armless task chair or stool, making yourself comfortable in Purpose is as easy as taking your seat.


The Journal of Baltic Studies editorial staff is proud to unveil a new Facebook page dedicated to the journal!
The topic of this Special Issue is the role of diaspora from Latvia and Latvians in national and international politics since the mid-19th century. We invite submissions that discuss various instances of either self-identified Latvians or groups from Latvia that resided outside of Latvia's territory engaging in political processes in their host countries and on international scale.
The Estonian Academy of Sciences recently announced that diaspora scholar Sander Jürisson's Masters thesis, a comprehensive history of Estonians in Brazil – migration and adaptation is one of the best student research papers of 2012.
Master in International Migration and Social Cohesion. Application for the MISOCO Erasmus Mundus Master Course 2013-2015 is now open.


text:
"""Class DistributionStrategy, TowerContext, and supporting APIs."""

from __future__ import absolute_import
from __future__ import division
from __future__ import print_function

import threading

from tensorflow.python.data.ops import dataset_ops
from tensorflow.python.eager import context as eager_context
from tensorflow.python.framework import ops
from tensorflow.python.ops import array_ops
from tensorflow.python.ops import control_flow_ops
from tensorflow.python.ops import resource_variable_ops
from tensorflow.python.ops import variable_scope
from tensorflow.python.ops.losses import losses_impl
from tensorflow.python.platform import tf_logging
from tensorflow.python.training import device_util
from tensorflow.python.training import distribution_strategy_context
from tensorflow.python.util import deprecation
from tensorflow.python.util import nest

# ------------------------------------------------------------------------------
# Context tracking whether in a distribution.update() or .update_non_slot()
# call.

_update_device = threading.local()

def get_update_device():
  """Get the current device if in a `DistributionStrategy.update()` call."""
  try:
    return _update_device.current
  except AttributeError:
    return None

class UpdateContext(object):
  """Context manager when you are in `update()` or `update_non_slot()`."""

  def __init__(self, device):
    self._device = device
    self._old_device = None

  def __enter__(self):
    self._old_device = get_update_device()
    _update_device.current = self._device

  def __exit__(self, exception_type, exception_value, traceback):
    del exception_type, exception_value, traceback
    _update_device.current = self._old_device

# ------------------------------------------------------------------------------
# Public utility functions.

def get_loss_reduction():
  """Reduce `aggregation` corresponding to the last loss reduction."""
  loss_reduction = ops.get_default_graph()._last_loss_reduction  # pylint: disable=protected-access
  if loss_reduction == losses_impl.Reduction.SUM:
    return variable_scope.VariableAggregation.SUM
  return variable_scope.VariableAggregation.MEAN

# ------------------------------------------------------------------------------
# Internal API for validating the current thread mode

def _require_cross_tower_context(distribution_strategy):
  """Verify in cross-tower context for `distribution_strategy`."""
  context = _get_per_thread_mode()
  if context.cross_tower_context is distribution_strategy: return
  # We have an error to report, figure out the right message.
  if context.distribution_strategy is not distribution_strategy:
    if (context.distribution_strategy is
        distribution_strategy_context._get_default_distribution_strategy()):  # pylint: disable=protected-access
      raise RuntimeError(
          'Need to be inside "with distribution_strategy.scope()" for %s' %
          (distribution_strategy,))
    else:
      raise RuntimeError(
          "Mixing different DistributionStrategy objects: %s is not %s" %
          (context.distribution_strategy, distribution_strategy))
  assert context.cross_tower_context is None
  raise RuntimeError("Method requires being in cross-tower context, use "
                     "get_tower_context().merge_call()")

def require_tower_context(tower_ctx):
  """Verify in `tower_ctx` tower context."""
  context = _get_per_thread_mode()
  if context.tower_context is tower_ctx: return
  # We have an error to report, figure out the right message.
  if context.tower_context is None:
    raise RuntimeError("Need to be inside `call_for_each_tower()`")
  if context.distribution_strategy is tower_ctx.distribution_strategy:
    # Two different TowerContexts with the same DistributionStrategy.
    raise RuntimeError("Mismatching tower context.")
  raise RuntimeError(
      "Mismatching DistributionStrategy objects: %s is not %s." %
      (context.distribution_strategy, tower_ctx.distribution_strategy))

def _require_distribution_strategy_scope(distribution_strategy):
  """Verify in a `distribution_strategy.scope()` in this thread."""
  context = _get_per_thread_mode()
  if context.distribution_strategy is distribution_strategy: return
  # We have an error to report, figure out the right message.
  if (context.distribution_strategy is
      distribution_strategy_context._get_default_distribution_strategy()):  # pylint: disable=protected-access
    raise RuntimeError(
        'Need to be inside "with distribution_strategy.scope()" for %s' %
        (distribution_strategy,))
  else:
    raise RuntimeError(
        "Mixing different DistributionStrategy objects: %s is not %s" %
        (context.distribution_strategy, distribution_strategy))

# ------------------------------------------------------------------------------
# Internal context managers used to implement the DistributionStrategy
# base class

class _CurrentDistributionContext(object):
  """Context manager for setting the `DistributionStrategy` and var creator."""

  def __init__(self,
               distribution_strategy,
               var_creator_scope,
               var_scope=None,
               default_device=None):
    self._context = distribution_strategy_context._CrossTowerThreadMode(  # pylint: disable=protected-access
        distribution_strategy)
    self._var_creator_scope = var_creator_scope
    self._var_scope = var_scope
    if default_device:
      self._device_scope = ops.device(default_device)
    else:
      self._device_scope = None

  def __enter__(self):
    _push_per_thread_mode(self._context)
    if self._var_scope:
      self._var_scope.__enter__()
    self._var_creator_scope.__enter__()
    if self._device_scope:
      self._device_scope.__enter__()
    return self._context.distribution_strategy

  def __exit__(self, exception_type, exception_value, traceback):
    if self._device_scope:
      self._device_scope.__exit__(exception_type, exception_value, traceback)
    self._var_creator_scope.__exit__(exception_type, exception_value, traceback)
    if self._var_scope:
      self._var_scope.__exit__(exception_type, exception_value, traceback)
    _pop_per_thread_mode()

class _SameScopeAgainContext(object):
  """Trivial context manager when you are already in `scope()`."""

  def __init__(self, distribution_strategy):
    self._distribution_strategy = distribution_strategy

  def __enter__(self):
    return self._distribution_strategy

  def __exit__(self, exception_type, exception_value, traceback):
    del exception_type, exception_value, traceback

# ------------------------------------------------------------------------------
# Base classes for all distribution strategies.

class DistributionStrategy(object):
  """A list of devices with a state & compute distribution policy.

  See [tensorflow/contrib/distribute/README.md](
  https://www.tensorflow.org/code/tensorflow/contrib/distribute/README.md)
  for overview and examples.

  The intent is that you can write an algorithm in a stylized way and
  it will be usable with a variety of different `DistributionStrategy`
  implementations. Each descendant will implement a different strategy
  for distributing the algorithm across multiple devices/machines.
  Furthermore, these changes can be hidden inside the specific layers
  and other library classes that need special treatment to run in a
  distributed setting, so that most users' model definition code can
  run unchanged. The `DistributionStrategy` API works the same way
  with eager and graph execution.

  First let's introduce a few high-level concepts:

  * _Data parallelism_ is where we run multiple copies of the model
    on different slices of the input data. This is in contrast to
    _model parallelism_ where we divide up a single copy of a model
    across multiple devices.
    Note: we only support data parallelism for now, but
    hope to add support for model parallelism in the future.
  * A _tower_ is one copy of the model, running on one slice of the
    input data.
  * _Synchronous_, or more commonly _sync_, training is where the
    updates from each tower are aggregated together before updating
    the model variables. This is in contrast to _asynchronous_, or
    _async_ training, where each tower updates the model variables
    independently.
  * Furthermore you might run your computation on multiple devices
    on one machine (or "host"), or on multiple machines/hosts.
    If you are running on multiple machines, you might have a
    single master host that drives computation across all of them,
    or you might have multiple clients driving the computation
    asynchronously.

  To distribute an algorithm, we might use some of these ingredients:

  * Parameter servers: These are hosts that hold a single copy of
    parameters/variables. All towers that want to operate on a variable
    retrieve it at the beginning of a step and send an update to be
    applied at the end of the step. Can support either sync or async
    training.
  * Mirrored variables: These are variables that are copied to multiple
    devices, where we keep the copies in sync by applying the same
    updates to every copy. Normally would only be used with sync training.
  * Reductions and Allreduce: A _reduction_ is some method of
    aggregating multiple values into one value, like "sum" or
    "mean". If doing sync training, we will perform a reduction on the
    gradients to a parameter from all towers before applying the
    update. Allreduce is an algorithm for performing a reduction on
    values from multiple devices and making the result available on
    all of those devices.
  * In the future we will have support for TensorFlow's partitioned
    variables, where a single variable is split across multiple
    devices.

  We have then a few approaches we want to support:

  * Code written (as if) with no knowledge of class `DistributionStrategy`.
    This code should work as before, even if some of the layers, etc.
    used by that code are written to be distribution-aware. This is done
    by having a default `DistributionStrategy` that gives ordinary behavior,
    and by default being in a single tower context.
  * Ordinary model code that you want to run using a specific
    `DistributionStrategy`. This can be as simple as:

    ```
    with my_distribution.scope():
      iterator = my_distribution.distribute_dataset(
          dataset).make_one_shot_iterator()
      tower_train_ops = my_distribution.call_for_each_tower(
          tower_fn, iterator.get_next())
      train_op = tf.group(my_distribution.unwrap(tower_train_ops))
    ```

    This takes an ordinary `dataset` and `tower_fn` and runs it
    distributed using a particular `DistributionStrategy` in
    `my_distribution`. Any variables created in `tower_fn` are created
    using `my_distribution`'s policy, and library functions called by
    `tower_fn` can use the `get_tower_context()` API to get enhanced
    behavior in this case.

    You can also create an initializable iterator instead of a one-shot
    iterator. In that case, you will need to ensure that you initialize the
    iterator before calling get_next.
    ```
    iterator = my_distribution.distribute_dataset(
        dataset).make_initializable_iterator())
    session.run(iterator.initializer)
    ```

  * If you want to write a distributed algorithm, you may use any of
    the `DistributionStrategy` APIs inside a
    `with my_distribution.scope():` block of code.

  Lower-level concepts:

  * Wrapped values: In order to represent values parallel across devices
    (either towers or the devices associated with a particular value), we
    wrap them in a "PerDevice" or "Mirrored" object that contains a map
    from device to values. "PerDevice" is used when the value may be
    different across devices, and "Mirrored" when the value are the same.
  * Unwrapping and merging: Consider calling a function `fn` on
    multiple devices, like `call_for_each_tower(fn, w)` with an
    argument `w` that is a wrapped value. This means `w` will have a
    map taking tower device `d0` to `w0`, tower device `d1` to `w1`,
    etc. `call_for_each_tower()` unwraps `w` before calling `fn`, so
    it calls `fn(w0)` on `d0`, `fn(w1)` on `d1`, etc.  It then merges
    the return values from `fn()`, which can possibly result in
    wrapped values. For example, let's say `fn()` returns a tuple with
    three components: `(x, a, v0)` from tower 0, `(x, b, v1)` on tower 1,
    etc. If the first component is the same object `x` from every
    tower, then the first component of the merged result will also be
    `x`. If the second component is different (`a`, `b`, ...)  from
    each tower, then the merged value will have a wrapped map from
    tower device to the different values. If the third component is
    the members of a mirrored variable (`v` maps `d0` to `v0`, `d1` to
    `v1`, etc.), then the merged result will be that mirrored variable
    (`v`).
  * Tower context vs. Cross-tower context: _tower context_ is when we
    are in some function that is being called once for each tower.
    Otherwise we are in cross-tower context, which is useful for
    calling `DistributionStrategy` methods which operate across the
    towers (like `reduce()`). By default you start in a tower context
    (the default "single tower context") and then some methods can
    switch you back and forth, as described below.
  * Worker devices vs. parameter devices: Most tower computations will
    happen on worker devices. Since we don't yet support model
    parallelism, there will be one worker device per tower. When using
    parameter servers (see above), the set of devices holding
    variables may be different, otherwise the parameter devices might
    match the worker devices.
  * Non-slot devices are some subset of the parameter devices where we
    put all the non-slot variables. We need to ensure that all
    non-slot variables are allocated on the same device, or mirrored
    across the same set of devices. If you have some variable you want
    to colocate all the non-slot variables with, you can use
    `colocate_vars_with()` to get the remaining non-slot variables on
    the same device.  Otherwise you can use `non_slot_devices()` to
    pick a consistent set of devices to pass to both
    `colocate_vars_with()` and `update_non_slot()`.

  When using a `DistributionStrategy`, we have a new type dimension
  called _locality_ that says what values are compatible with which
  APIs:

  * T: different value for each tower (e.g. a PerDevice-wrapped value).
  * M: value is "mirrored" across towers, i.e. there are copies with the
    same value on each tower (e.g. a Mirrored-wrapped value).
  * V(`v`): value is "mirrored" across all the devices which have a
    copy of variable `v` (also a Mirrored-wrapped value, but over
    parameter devices instead of worker devices).
  * N: value is "mirrored" across all the "non-slot" devices

  Rules for methods with respect to locality and single-tower vs.
  cross-tower context:

  * `with d.scope()`: default single-tower context -> cross-tower context for
    `d`
  * `with d.colocate_vars_with(v)`: in tower/cross-tower context, variables
    will be created with locality V(`v`). That is, if we write
    `with d.colocate_vars_with(v1): v2 = tf.get_variable(...)`, then
    `v2` will have locality V(`v1`), i.e. locality V(`v2`) will equal
    V(`v1`).
  * `with d.colocate_vars_with(d.non_slot_devices(...))`: in
    tower/cross-tower context, variables will be created with locality N
  * `v = tf.get_variable(...)`: in tower/cross-tower context, creates
    a variable (which by definition will have locality V(`v`), though
    will match another locality if inside a `colocate_vars_with`
    scope).
  * `d.distribute_dataset(dataset).make_one_shot_iterator()`: in cross-tower
    context, produces an iterator with locality T
  * `d.broadcast(t)`: in cross-tower context, produces a value with locality M
  * `d.broadcast(t, v)`: in cross-tower context, produces a value with
    locality V(`v`)
  * `d.call_for_each_tower(fn, ...)`: in cross-tower context, runs
    `fn()` in a tower context (and so may call `get_tower_context()` and
    use its API, including `merge_call()` to get back to cross-tower
    context), once for each tower. May use values with locality T or
    M, and any variable.
  * `d.reduce(m, t, t)`: in cross-tower context, accepts t with locality T
    and produces a value with locality M.
  * `d.reduce(m, t, v)`: in cross-tower context, accepts t with
    locality T and produces a value with locality V(`v`).
  * `d.batch_reduce(m, [(t, v)]): see `d.reduce()`
  * `d.update(v, fn, ...)`: in cross-tower context, runs `fn()` once
    for each device `v` is copied to, all inputs should have locality
    V(`v`), output will have locality V(`v`) as well.
  * `d.update_non_slot(d.non_slot_devices(), fn)`: in cross-tower
    context, like `d.update()` except with locality N.
  * `d.read_var(v)`: Gets the (read-only) value of the variable `v` (on
    the device determined by the current device scope), aggregating
    across towers for tower-local variables. Frequently, this will be
    done automatically when using `v` in an expression or fetching it in
    a cross-tower context, but this function can be used to force that
    conversion happens at a particular point in time (for example, to
    add the result of the conversion to a graph collection).

  The standard pattern for updating variables is to:

  1. Wrap your input dataset in `d.distribute_dataset()` and create an iterator.
  2. Define each tower `d.call_for_each_tower()` up to the point of
     getting a list of gradient, variable pairs.
  3. Call `d.reduce(VariableAggregation.SUM, t, v)` or `d.batch_reduce()` to sum
     the gradients (with locality T) into values with locality V(`v`).
  4. Call `d.update(v)` for each variable to update its value.

  Steps 3 and 4 are done automatically by class `Optimizer` if you call
  its `apply_gradients` method in a tower context. Otherwise you can
  manually call its `_distributed_apply` method in a cross-tower context.

  Another thing you might want to do in the middle of your tower function
  is an all-reduce of some intermediate value, using `d.reduce()` or
  `d.batch_reduce()`. You simply provide the same tensor as the input and
  destination.

  Layers should expect to be called in a tower context, and can use
  the `get_tower_context()` function to get a `TowerContext` object. The
  `TowerContext` object has a `merge_call()` method for entering
  cross-tower context where you can use `reduce()` (or
  `batch_reduce()`) and then optionally `update()` to update state.

  You may use this API whether or not a `DistributionStrategy` is
  being used, since there is a default implementation of
  `TowerContext` and `DistributionStrategy`. Or you can use the
  `get_tower_context().is_single_tower` property to run different code
  in the distributed vs. single tower cases.
  """

  # TODO(josh11b): Raise an exception if variable partitioning requested before
  #   we add support.
  # TODO(josh11b): Also `parameter_device_index` property?
  # TODO(josh11b): `map()`
  # TODO(josh11b): ClusterSpec/ClusterResolver
  # TODO(josh11b): Partitioned computations, state; sharding
  # TODO(josh11b): Model parallelism: "towers" with multiple devices; shuffling
  # TODO(josh11b): List of towers with their worker and parameter devices
  #   (where the parameter devices may overlap in the ps case).

  def __init__(self):
    self._default_device = None
    # This property is used to determine if we should set drop_remainder=True
    # when creating Datasets from numpy array inputs.
    self._require_static_shapes = False

  def scope(self):
    """Returns a context manager selecting this DistributionStrategy as current.

    Inside a `with distribution_strategy.scope():` code block, this thread
    will use a variable creator set by `distribution_strategy`, and will
    enter its "cross-tower context".

    Returns:
      A context manager.
    """
    if distribution_strategy_context.has_distribution_strategy():
      _require_cross_tower_context(self)
      return _SameScopeAgainContext(self)

    def creator_with_resource_vars(*args, **kwargs):
      _require_distribution_strategy_scope(self)
      kwargs["use_resource"] = True
      return self._create_variable(*args, **kwargs)

    def disable_partitioned_variables(getter, *args, **kwargs):
      if kwargs.pop("partitioner", None) is not None:
        tf_logging.log_first_n(
            tf_logging.WARN, "Partitioned variables are disabled when using "
            "DistributionStrategy.", 1)
      return getter(*args, **kwargs)

    return _CurrentDistributionContext(
        self, variable_scope.variable_creator_scope(creator_with_resource_vars),
        variable_scope.variable_scope(
            variable_scope.get_variable_scope(),
            custom_getter=disable_partitioned_variables),
        self._default_device)

  def _create_variable(self, next_creator, *args, **kwargs):
    # Note: should support "colocate_with" argument.
    raise NotImplementedError("must be implemented in descendants")

  def read_var(self, v):
    """Reads the value of a variable.

    Returns the aggregate value of a tower-local variable, or the
    (read-only) value of any other variable.

    Args:
      v: A variable allocated within the scope of this `DistributionStrategy`.

    Returns:
      A tensor representing the value of `v`, aggregated across towers if
      necessary.
    """
    raise NotImplementedError("must be implemented in descendants")

  def colocate_vars_with(self, colocate_with_variable):
    """Scope that controls which devices variables will be created on.

    No operations should be added to the graph inside this scope, it
    should only be used when creating variables (some implementations
    work by changing variable creation, others work by using a
    tf.colocate_with() scope).

    This may only be used inside `self.scope()`.

    Example usage:

    ```
    with distribution_strategy.scope():
      var1 = tf.get_variable(...)
      with distribution_strategy.colocate_vars_with(v1):
        # var2 and var3 will be created on the same device(s) as var1
        var2 = tf.get_variable(...)
        var3 = tf.get_variable(...)

      def fn(v1, v2, v3):
        # operates on v1 from var1, v2 from var2, and v3 from var3

      # `fn` runs on every device `v1` is on, `v2` and `v3` will be there too.
      distribution_strategy.update(v1, fn, v2, v3)
    ```

    Args:
      colocate_with_variable: A created in `self.scope()`. Variables created
        while in the returned context manager will be on the same set of
        devices as `colocate_with_variable`.

    Returns:
      A context manager.
    """
    def create_colocated_variable(next_creator, *args, **kwargs):
      _require_distribution_strategy_scope(self)
      kwargs["use_resource"] = True
      kwargs["colocate_with"] = colocate_with_variable
      return next_creator(*args, **kwargs)

    _require_distribution_strategy_scope(self)
    return variable_scope.variable_creator_scope(create_colocated_variable)

  def _call_dataset_fn(self, dataset_fn):
    result = dataset_fn()
    if not isinstance(result, dataset_ops.Dataset):
      raise ValueError(
          "dataset_fn() must return a tf.data.Dataset when using a "
          "DistributionStrategy.")
    return result

  # TODO(josh11b): `PerDeviceDataset` currently only implements a few methods of
  # Dataset API such as make_one_shot_iterator and make_initializable_iterator.
  # Extend to implement more functionality of datasets.
  def distribute_dataset(self, dataset_fn):
    """Return a `dataset` split across all towers.

    Suitable for providing input to for `call_for_each_tower()` by creating an
    iterator:

    ```
    def dataset_fn():
      return tf.data.Dataset.from_tensors([[1.]]).repeat()
    with distribution_strategy.scope():
      distributed_dataset = distribution_strategy.distribute_dataset(dataset_fn)
      iterator = distributed_dataset.make_one_shot_iterator()
      tower_results = distribution_strategy.call_for_each_tower(
          tower_fn, iterator.get_next())
    ```

    Args:
      dataset_fn: A function that returns a `tf.data.Dataset`.

    Returns:
      A `PerDeviceDataset` that will produce data for each tower.
    """
    raise NotImplementedError("must be implemented in descendants")

  def broadcast(self, tensor, destinations=None):
    """Mirror a tensor on one device to all worker devices.

    Args:
      tensor: A Tensor value to broadcast.
      destinations: An optional mirrored variable, device string, or
        list of device strings, specifying the destination devices
        to copy `tensor` to. Defaults to `self.worker_devices`.

    Returns:
      A value mirrored to `destinations` devices.
    """
    # TODO(josh11b): More docstring
    _require_cross_tower_context(self)
    return self._broadcast(tensor, destinations)

  def _broadcast(self, tensor, destinations):
    raise NotImplementedError("must be implemented in descendants")

  def initialize(self):
    """Any initialization to be done before running any computations.

    In eager mode, it executes any initialization as a side effect.
    In graph mode, it creates the initialization ops and returns them.

    For example, TPU initialize_system ops.

    Returns:
      In eager mode, returns `None`.
      In graph mode, a list of ops to execute. Empty list if nothing to be done.
    """
    if eager_context.executing_eagerly():
      return
    else:
      return []

  def finalize(self):
    """Any final actions to be done at the end of all computations.

    In eager mode, it executes any finalize actions as a side effect.
    In graph mode, it creates the finalize ops and returns them.

    For example, TPU shutdown ops.

    Returns:
      In eager mode, returns `None`.
      In graph mode, a list of ops to execute. Empty list if nothing to be done.
    """
    if eager_context.executing_eagerly():
      return
    else:
      return []

  def run_steps_on_dataset(self, fn, iterator, iterations=1,
                           initial_loop_values=None):
    """Run `fn` with input from `iterator` for `iterations` times.

    This method can be used to run a step function for training a number of
    times using input from a dataset.

    Args:
      fn: function to run using this distribution strategy. The function must
        have the following signature: `def fn(context, *inputs)`.
        `context` is an instance of `MultiStepContext` that will be passed when
        `fn` is run. `context` can be used to specify the outputs to be returned
        from `fn` by calling `context.set_last_step_output`. It can also be used
        to capture non tensor outputs by `context.set_non_tensor_output`.
        See `MultiStepContext` documentation for more information.
        `inputs` will have same type/structure as `iterator.get_next()`. If the
        `iterator.get_next()` returns a tuple say `return x, y` then whose will
        be unpacked and passed to the `step_fn`; and step_fn signature would
        look like `def step_fn(context, x, y)`. If the iterator returns a single
        value say `return x` then the value is passed as is; the step_fn
        signature would look like `def step_fn(context, x)`.
        Typically, `fn` will use `call_for_each_tower` method of the strategy
        to distribute the computation over multiple towers.
      iterator: Iterator of a dataset that represents the input for `fn`. The
        caller is responsible for initializing the iterator as needed.
      iterations: (Optional) Number of iterations that `fn` should be run.
        Defaults to 1.
      initial_loop_values: (Optional) Initial values to be passed into the
        loop that runs `fn`. Defaults to `None`. # TODO(priyag): Remove
        initial_loop_values argument when we have a mechanism to infer the
        outputs of `fn`.

    Returns:
      Returns the `MultiStepContext` object which has the following properties,
      among other things:
        - run_op: An op that runs `fn` `iterations` times.
        - last_step_outputs: A dictionary containing tensors set using
        `context.set_last_step_output`. Evaluating this returns the value of
        the tensors after the last iteration.
        - non_tensor_outputs: A dictionatry containing anything that was set by
          `fn` by calling `context.set_non_tensor_output`.
    """
    _require_cross_tower_context(self)
    return self._run_steps_on_dataset(fn, iterator, iterations,
                                      initial_loop_values)

  def _run_steps_on_dataset(self, fn, iterator, iterations,
                            initial_loop_values):
    raise NotImplementedError("must be implemented in descendants")

  def call_for_each_tower(self, fn, *args, **kwargs):
    """Run `fn` once per tower.

    `fn` may call `tf.get_tower_context()` to access methods such as
    `tower_id()` and `merge_call()`.

    `merge_call()` is used to communicate between the towers and
    re-enter the cross-tower context. All towers pause their execution
    having encountered a `merge_call()` call. After that the
    `merge_fn`-function is executed. Its results are then unwrapped and
    given back to each tower call. After that execution resumes until
    `fn` is complete or encounters another `merge_call()`.  Example:

    ```python
    # Called once in "cross-tower" context.
    def merge_fn(distribution, three_plus_tower_id):
      # sum the values across towers
      return sum(distribution.unwrap(three_plus_tower_id))

    # Called once per tower in `distribution`, in a "tower" context.
    def fn(three):
      tower_ctx = tf.get_tower_context()
      v = three + tower_ctx.tower_id
      # Computes the sum of the `v` values across all towers.
      s = tower_ctx.merge_call(merge_fn, v)
      return s + v

    with distribution.scope():
      # in "cross-tower" context
      ...
      merged_results = distribution.call_for_each_tower(fn, 3)
      # merged_results has the values from every tower execution of `fn`.
      print(distribution.unwrap(merged_results))  # Prints a list
    ```

    Args:
      fn: function to run (will be run once per tower).
      *args: positional arguments for `fn`
      **kwargs: keyword arguments for `fn`.
          `"run_concurrently"`: Boolean indicating whether executions of `fn`
             can be run concurrently (under eager execution only), defaults to
             `True`.

    Returns:
      Merged return value of `fn` across all towers.
    """
    _require_cross_tower_context(self)
    return self._call_for_each_tower(fn, *args, **kwargs)

  def _call_for_each_tower(self, fn, *args, **kwargs):
    raise NotImplementedError("must be implemented in descendants")

  def reduce(self, aggregation, value, destinations):
    """Combine (via e.g. sum or mean) values across towers.

    Args:
      aggregation: Indicates how a variable will be aggregated. Accepted values
        are `tf.VariableAggregation.SUM`, `tf.VariableAggregation.MEAN`,
        `tf.VariableAggregation.ONLY_FIRST_TOWER`.
      value: A per-device value with one value per tower.
      destinations: A mirrored variable, a per-device tensor, a device string,
        or list of device strings. The return value will be copied to all
        destination devices (or all the devices where the `destinations` value
        resides). To perform an all-reduction, pass `value` to `destinations`.

    Returns:
      A value mirrored to `destinations`.
    """
    # TODO(josh11b): More docstring
    # TODO(josh11b): Return an unwrapped value if colocate_with is a
    # single device.
    _require_cross_tower_context(self)
    assert aggregation in [
        variable_scope.VariableAggregation.SUM,
        variable_scope.VariableAggregation.MEAN,
        variable_scope.VariableAggregation.ONLY_FIRST_TOWER
    ]
    return self._reduce(aggregation, value, destinations)

  def _reduce(self, aggregation, value, destinations):
    raise NotImplementedError("must be implemented in descendants")

  def batch_reduce(self, aggregation, value_destination_pairs):
    """Combine multiple `reduce` calls into one for faster execution.

    Args:
      aggregation: Indicates how a variable will be aggregated. Accepted values
        are `tf.VariableAggregation.SUM`, `tf.VariableAggregation.MEAN`,
        `tf.VariableAggregation.ONLY_FIRST_TOWER`.
      value_destination_pairs: A sequence of (value, destinations)
        pairs. See `reduce()` for a description.

    Returns:
      A list of mirrored values, one per pair in `value_destination_pairs`.
    """
    # TODO(josh11b): More docstring
    _require_cross_tower_context(self)
    assert aggregation in [
        variable_scope.VariableAggregation.SUM,
        variable_scope.VariableAggregation.MEAN,
        variable_scope.VariableAggregation.ONLY_FIRST_TOWER
    ]
    return self._batch_reduce(aggregation, value_destination_pairs)

  def _batch_reduce(self, aggregation, value_destination_pairs):
    return [
        self.reduce(aggregation, t, destinations=v)
        for t, v in value_destination_pairs
    ]

  def update(self, var, fn, *args, **kwargs):
    """Run `fn` to update `var` using inputs mirrored to the same devices.

    If `var` is mirrored across multiple devices, then this implements
    logic like:

    ```
    results = {}
    for device, v in var:
      with tf.device(device):
        # *args and **kwargs will be unwrapped if they are mirrored.
        results[device] = fn(v, *args, **kwargs)
    return merged(results)
    ```

    Otherwise this returns `fn(var, *args, **kwargs)` colocated with `var`.

    Neither `*args` nor `**kwargs` may contain per-device values.
    If they contain mirrored values, they will be unwrapped before
    calling `fn`.

    Args:
      var: Variable, possibly mirrored to multiple devices, to operate on.
      fn: Function to call. Should take the variable as the first argument.
      *args: Additional positional arguments to pass to `fn()`.
      **kwargs: Keyword arguments to pass to `fn()`. If "grouped=False" is
        specified, the return value will be unwrapped.

    Returns:
      By default, the merged return value of `fn` across all towers.  The merged
      result has dependencies to make sure that if it is evaluated at all, the
      side effects (updates) will happen on every tower. If instead
      "grouped=False" is specified, this function will return a nest of lists
      where each list has an element per tower, and the caller is responsible
      for ensuring all elements are executed.
    """
    _require_cross_tower_context(self)
    options = {"grouped": kwargs.pop("grouped", True)}
    return self._update(var, options, fn, *args, **kwargs)

  def _update(self, var, options, fn, *args, **kwargs):
    raise NotImplementedError("must be implemented in descendants")

  def update_non_slot(self, colocate_with, fn, *args, **kwargs):
    """Runs `fn(*args, **kwargs)` on `colocate_with` devices.

    Args:
      colocate_with: The return value of `non_slot_devices()`.
      fn: Function to execute.
      *args: Positional arguments to pass to `fn()`.
      **kwargs: Keyword arguments to pass to `fn()`. If "grouped=False" is
        specified, the return value will be unwrapped and the caller is
        responsible for ensuring all elements are executed.

    Returns:
      Return value of `fn`, possibly merged across devices.
    """
    _require_cross_tower_context(self)
    options = {"grouped": kwargs.pop("grouped", True)}
    return self._update_non_slot(colocate_with, options, fn, *args, **kwargs)

  def _update_non_slot(self, colocate_with, options, fn, *args, **kwargs):
    raise NotImplementedError("must be implemented in descendants")

  def unwrap(self, value):
    """Returns the list of all per-device values contained in `value`.

    Args:
      value: A value returned by `call_for_each_tower()` or a variable
        created in `scope()`.

    Returns:
      A list of values contained in `value`. If `value` represents a single
      value, this returns `[value].`
    """
    return self._unwrap(value)

  def value_container(self, value):
    """Returns the container that this per-device `value` belongs to.

    Args:
      value: A value returned by `call_for_each_tower()` or a variable
        created in `scope()`.

    Returns:
      A container that `value` belongs to.
      If value does not belong to any container (including the case of
      container having been destroyed), returns the value itself.
      `value in unwrap(value_container(value))` will always be true.
    """
    raise NotImplementedError("must be implemented in descendants")

  def _unwrap(self, distributed_value):
    raise NotImplementedError("must be implemented in descendants")

  def group(self, value, name=None):
    """Shortcut for `tf.group(distribution.unwrap(value))`."""
    value = nest.flatten(self.unwrap(value))

    if len(value) != 1 or name is not None:
      return control_flow_ops.group(value, name=name)
    # Special handling for the common case of one op.
    v, = value
    if hasattr(v, "op"):
      v = v.op
    return v

  @property
  def is_single_tower(self):
    """Returns whether there is a single tower or multiple.

    Returns:
      A boolean. If `True`, `call_for_each_tower(fn)` will only call `fn` once.
      If `False`, `call_for_each_tower(fn)` may call `fn` multiple times.
    """
    raise NotImplementedError("must be implemented in descendants")

  @property
  def require_static_shapes(self):
    return self._require_static_shapes

  @property
  def num_towers(self):
    """Returns number of towers, for purposes of averaging across towers."""
    raise NotImplementedError("must be implemented in descendants")

  @property
  def worker_devices(self):
    """Returns the list of devices used to run `call_for_each_tower()` calls."""
    # TODO(josh11b): More docstring
    raise NotImplementedError("must be implemented in descendants")

  @property
  def parameter_devices(self):
    """Returns the list of devices used for variable and `update` placement."""
    # TODO(josh11b): More docstring
    raise NotImplementedError("must be implemented in descendants")

  def non_slot_devices(self, var_list):
    """Device(s) for non-slot variables.

    Create variables on these devices in a
    `with colocate_vars_with(non_slot_devices(...)):` block.
    Update those using `update_non_slot()`.

    Args:
      var_list: The list of variables being optimized, needed with the
        default `DistributionStrategy`.
    """
    raise NotImplementedError("must be implemented in descendants")

  @property
  def worker_device_index(self):
    """An object mapping worker device to an id.

    This might be passed as an argument to `call_for_each_tower()`, as in:

    ```
    with distribution_strategy.scope():

      def fn(device_id):
        # device_id is an integer. `fn` is being executed on device:
        #    distribution_strategy.worker_devices[device_id].

      distribution_strategy.call_for_each_tower(
          fn, distribution_strategy.worker_device_index)
    ```

    Returns:
      An index object, or the integer 0 if there is only a single tower.
    """
    _require_cross_tower_context(self)
    return self._worker_device_index()

  def _worker_device_index(self):
    raise NotImplementedError("must be implemented in descendants")

  @property
  def between_graph(self):
    """Whether the strategy uses between-graph replication or not.

      This is expected to return a constant value that will not be changed
      throughout its life cycle.
    """
    raise NotImplementedError("must be implemented in descendants")

  def configure(self,
                session_config=None,
                cluster_spec=None,
                task_type=None,
                task_id=None):
    """Configures the strategy class."""
    del session_config, cluster_spec, task_type, task_id

  @property
  def should_init(self):
    """Whether initialization is needed."""
    raise NotImplementedError("must be implemented in descendants")

  @property
  def should_checkpoint(self):
    """Whether checkpointing is needed."""
    raise NotImplementedError("must be implemented in descendants")

  @property
  def should_save_summary(self):
    """Whether saving summaries is needed."""
    raise NotImplementedError("must be implemented in descendants")

# A note about the difference between the context managers
# `TowerContext` (defined here) and `_CurrentDistributionContext`
# (defined above) used by `DistributionStrategy.scope()`:
#
# * a TowerContext is only present during a `call_for_each_tower()`
#   call (except during a `merge_run` call) and in such a scope it
#   will be returned by calls to `get_tower_context()`.  Implementers of new
#   DistributionStrategy descendants will frequently also need to
#   define a descendant of TowerContext, and are responsible for
#   entering and exiting this context.
#
# * DistributionStrategy.scope() sets up a variable_creator scope that
#   changes variable creation calls (e.g. to make mirrored
#   variables). This is intended as an outer scope that users enter once
#   around their model creation and graph definition. There is no
#   anticipated need to define descendants of _CurrentDistributionContext.
#   It sets the current DistributionStrategy for purposes of
#   `get_distribution_strategy()` and `has_distribution_strategy()`
#   and switches the thread mode to a "cross-tower context".
class TowerContext(object):
  """DistributionStrategy API inside a `call_for_each_tower()` call."""

  def __init__(self, distribution_strategy, tower_id):
    self._distribution_strategy = distribution_strategy
    self._thread_context = distribution_strategy_context._InTowerThreadMode(  # pylint: disable=protected-access
        self)
    self._tower_id = tower_id

  def __enter__(self):
    _push_per_thread_mode(self._thread_context)

  def __exit__(self, exception_type, exception_value, traceback):
    _pop_per_thread_mode()

  def merge_call(self, merge_fn, *args, **kwargs):
    """Merge args across towers and run `merge_fn` in a cross-tower context.

    This allows communication and coordination when there are multiple calls
    to a model function triggered by a call to
    `distribution.call_for_each_tower(model_fn, ...)`.

    See `MirroredDistribution.call_for_each_tower()` for an explanation.

    Otherwise, this is equivalent to:

    ```
    distribution = get_distribution_strategy()
    with cross-tower-context(distribution):
      return merge_fn(distribution, *args, **kwargs)
    ```

    Args:
      merge_fn: function that joins arguments from threads that are given as
        PerDevice. It accepts `DistributionStrategy` object as the first
        argument.
      *args: positional per-thread arguments for `merge_fn`
      **kwargs: keyword per-thread arguments for `merge_fn`.

    Returns:
      The return value of `merge_fn`, except for `PerDevice` values which are
      unpacked.
    """
    require_tower_context(self)
    return self._merge_call(merge_fn, *args, **kwargs)

  def _merge_call(self, merge_fn, *args, **kwargs):
    """Default implementation for single tower."""
    _push_per_thread_mode(  # thread-local, so not needed with multiple threads
        distribution_strategy_context._CrossTowerThreadMode(  # pylint: disable=protected-access
            self._distribution_strategy))
    try:
      return merge_fn(self._distribution_strategy, *args, **kwargs)
    finally:
      _pop_per_thread_mode()

  @property
  def is_single_tower(self):
    """Returns whether there is a single tower or multiple."""
    require_tower_context(self)
    return self._distribution_strategy.is_single_tower

  @property
  def num_towers(self):
    """Returns number of towers, for purposes of averaging across towers."""
    return self._distribution_strategy.num_towers

  @property
  def tower_id(self):
    """Which tower is being defined, a number from 0 to `num_towers - 1`."""
    require_tower_context(self)
    return self._tower_id

  @property
  def distribution_strategy(self):
    """The current `DistributionStrategy` object."""
    return self._distribution_strategy

  @property
  def device(self):
    """The device this tower is to be executed on, as a string."""
    require_tower_context(self)
    return device_util.current()

  # TODO(josh11b): Implement `start_all_reduce(method, t)` for efficient
  # all-reduce. It would return a function returning the result of reducing `t`
  # across all towers. The caller would wait to call this function until they
  # needed the reduce result, allowing an efficient implementation:
  # * With eager execution, the reduction could be performed asynchronously
  #   in the background, not blocking until the result was needed.
  # * When constructing a graph, it could batch up all reduction requests up
  #   to that point that the first result is needed. Most likely this can be
  #   implemented in terms of `merge_call()` and `batch_reduce()`.

# ------------------------------------------------------------------------------

class _DefaultDistributionStrategy(DistributionStrategy):
  """Default `DistributionStrategy` if none is explicitly selected."""

  def scope(self):
    """Context manager setting a variable creator and `self` as current."""
    if distribution_strategy_context.has_distribution_strategy():
      raise RuntimeError("Must not nest DistributionStrategy scopes.")

    def creator(next_creator, *args, **kwargs):
      _require_distribution_strategy_scope(self)
      return next_creator(*args, **kwargs)

    return _CurrentDistributionContext(
        self, variable_scope.variable_creator_scope(creator))

  def colocate_vars_with(self, colocate_with_variable):
    """Does not require `self.scope`."""
    _require_distribution_strategy_scope(self)
    return ops.colocate_with(colocate_with_variable)

  def distribute_dataset(self, dataset_fn):
    return self._call_dataset_fn(dataset_fn)

  def _broadcast(self, tensor, destinations):
    if destinations is None:
      return tensor
    else:
      raise NotImplementedError("TODO")

  def _call_for_each_tower(self, fn, *args, **kwargs):
    # We don't run `fn` in multiple threads in _DefaultDistributionStrategy.
    kwargs.pop("run_concurrently", None)
    with TowerContext(self, tower_id=0):
      return fn(*args, **kwargs)

  def _reduce(self, aggregation, value, destinations):
    # TODO(josh11b): Use destinations?
    del aggregation, destinations
    return value

  def _update(self, var, options, fn, *args, **kwargs):
    # The implementations of _update() and _update_non_slot() are identical
    # except _update() passes `var` as the first argument to `fn()`.
    return self._update_non_slot(var, options, fn, var, *args, **kwargs)

  def _update_non_slot(self, colocate_with, options, fn, *args, **kwargs):
    should_group = options.pop("grouped")
    assert not options  # Validate that we are processing all of the options.
    # TODO(josh11b): Figure out what we should be passing to UpdateContext()
    # once that value is used for something.
    with ops.colocate_with(colocate_with), UpdateContext(colocate_with):
      result = fn(*args, **kwargs)
      if should_group:
        return result
      else:
        return nest.map_structure(self._unwrap, result)

  def read_var(self, tower_local_var):
    return array_ops.identity(tower_local_var)

  def _unwrap(self, distributed_value):
    return [distributed_value]

  def value_container(self, value):
    return value

  @property
  def is_single_tower(self):
    return True

  @property
  def num_towers(self):
    return 1

  @property
  def worker_devices(self):
    raise RuntimeError(
        "worker_devices() method unsupported by _DefaultDistributionStrategy.")

  @property
  def parameter_devices(self):
    raise RuntimeError("parameter_devices() method unsupported by "
                       "_DefaultDistributionStrategy.")

  def non_slot_devices(self, var_list):
    return min(var_list, key=lambda x: x.name)

  def _worker_device_index(self):
    raise RuntimeError("worker_device_index() method unsupported by "
                       "_DefaultDistributionStrategy.")

# ------------------------------------------------------------------------------
# Deprecated, use v.assign_add(amount) instead.  Internal API, so expect
# it to be deleted soon.

@deprecation.deprecated(None,
                        "Use v.assign_add(amount) instead. You may need to set "
                        "aggregation=tf.VariableAggregation.ONLY_FIRST_TOWER "
                        "when creating the variable.")
def increment_var(v, amount=1):
  """`v += amount`, distributed-aware version."""
  def update(vu):
    return vu.assign_add(amount, read_value=False)

  def merge_fn(dist, vm):
    return dist.update(vm, update)

  tower_context = distribution_strategy_context.get_tower_context()
  return tower_context.merge_call(merge_fn, v)

# ------------------------------------------------------------------------------
# We haven't yet implemented deserialization for DistributedVariables.
# So here we catch any attempts to deserialize variables
# when using distribution strategies.
# pylint: disable=protected-access
_original_from_proto = resource_variable_ops._from_proto_fn

def _from_proto_fn(v, import_scope=None):
  if distribution_strategy_context.has_distribution_strategy():
    raise NotImplementedError(
        "Deserialization of variables is not yet supported when using"
        "distributed strategies.")
  else:
    return _original_from_proto(v, import_scope=import_scope)

resource_variable_ops._from_proto_fn = _from_proto_fn
# pylint: enable=protected-access

#-------------------------------------------------------------------------------
# Shorthand for some methods from distribution_strategy_context.
_push_per_thread_mode = distribution_strategy_context._push_per_thread_mode  # pylint: disable=protected-access
_get_per_thread_mode = distribution_strategy_context._get_per_thread_mode  # pylint: disable=protected-access
_pop_per_thread_mode = distribution_strategy_context._pop_per_thread_mode  # pylint: disable=protected-access

redpajama_set_name: RedPajamaGithub


The LWF works with and for member churches, supporting them to proclaim the gospel, serve people in need and advocate for peace, justice and reconciliation. Our three institutional programs - building the communion, improving capacity for Diakonia (serving people in need), and promoting church growth and sustainability - are designed to help the church reach its potential as an agent of change rooted in the communities it serves. The LWF's flagship program in Africa is a wide-ranging series of initiatives that address the most pressing social and economic concerns. The work of the Africa communion is guided by its undertaking to help churches work together on God's mission in Africa, shaping its approach according to the context of the country. The LWF's Department for Mission and Development accompanies LWF member churches in Africa as they carry out holistic mission.
The LWF's institutional programs - improving capacity for Diakonia (serving people in need), improving capacity for advocacy, promoting transformative leadership, promoting an inclusive communion, offering theological education, and forming strong relationships and identity - are designed to help the church reach its potential as an agent of change rooted in the communities it serves.
Our 37 projects at country level tackle endemic poverty, economic injustice and harmful social practices. They inspire change and promote efforts to build peace, addressing some of the greatest problems of society.


The Burfjord project is comprised of six exploration licenses totaling 5,500 hectares near Kåfjord, Norway. Mineralization at Burfjord belongs to Iron Oxide Copper Gold (IOCG) deposit clan; this portion of northern Fennoscandia, a key IOCG province globally. Copper mineralization was mined in the Burfjord area during the 19th century, with over 30 historic mines and prospects developed along the flanks of a prominent 4 x 6 kilometer anticlinal structure comprised of interbedded metasedimentary and metavolcanic rocks.
Many of the rocks in the anticline have been subjected to intense hydrothermal alteration. This potential has only recently been recognized in Norway Mineralization occurs as both high grade Cu-Au lodes that were historically mined at high cut-off grades (>3% Cu and lower grade, bulk tonnage potential Cu-Au mineralization developed in stockwork vein arrays. Vein mineralization in the area is dominated by carbonate and iron-oxide minerals (magnetite and hematite), but also contain chalcopyrite, bornite and chalcocite in addition to cobalt-rich pyrite.
Only limited exploration has taken place in the modern era. Limited historic drilling (confined to vicinity of Cedarsgruve Mine) produced intercepts including 7m @ 3.6% Cu.
The Burjord project is situated 40 km southwest of Alta (regional airport), road accessible and is located 7.5 kilometers from tide water. Burfjord is 32 km west of Kåfjord copper mines, the first major industrial enterprise north of the Arctic Circle.


The writer of a recent letter wondered how a committed Christian could also be a Democrat ("Democrats draw wrong lines," Oct. 18). I'd like to give the writer my take on Christian values.
Jesus Christ was and is inclusive, which means he loves and cares for all of us unconditionally. That includes gays, those who choose to have an abortion, and those who don't use God's name in all their conversations.
Being a Christian means we are our brother's keepers. We pass legislation that supports people over "principalities and powers." We utilize our rights to free speech to bring clarity as well as harmony between opposing opinions. We respect others as part of God's creation just as we see ourselves to be a part of that greater whole.
In my view, the America recalled in the recent letter is a less Christian country than it is today. I don't want to bring back the era when women couldn't vote, when blacks were denied civil rights and when gays were denied the same rights we all enjoy. OK, so we're still working on that last one, but I'm confident we'll eventually make the loving choice.
What does believing America is the land of the free mean? To me, it means all of her people are free to be who they choose to be, with those choices being between the individual and his or her God, free of other peoples' judgments.
I don't see that God has been taken out of our nation - or anything else - because I see God in everything humans do. God is much bigger than our small egos.
I'm a Democrat and I'm a Christian. For me, being a Democrat is an expression of my Christian values.