Further details were revealed about the general shape of Dungeons & Dragons to come emerged during the panel's Q & A section, and the most interesting information asked of Perkins was about settings other than the Forgotten Realms. When asked about the other settings that D&D has had in the past, Perkins said that all "key" settings would be supported "in some way." In regards to the Eberron setting in particular, Perkins was cagey with details but said that Eberron fans will "love" what is being done for the setting, further implying that Eberron creator Keith Baker would be somehow involved. It's hard to say what else can be considered a "key" setting, but if Wizards' past choices can be counted on, then Dark Sun will likely be included in that list. Perkins also provided more details about Ravenloft saying that players would see more Ravenloft content "very soon."
"Dragonlance is not dead," said Perkins when asked about the classic setting. However, when asked about it after the panel, Perkins said that the R&D team as it is now would require a "specialist" to do work on Dragonlance. Which when I released it into the wild via Twitter prompted this rather hilarious twitter exchange between one of Dragonlance's authors, Margaret Weis, and Cam Banks, who did work for Dragonlance during the Dungeons and Dragons Third Edition era. Beyond that Dragonlance nugget, the only further detail revealed was that Wizards of the Coast wanted to "Do right by their settings."
Further details include that Dungeons & Dragons' Fifth Edition is about 97.9% complete. In regards to class design, and specifically addressing complaints that in the Fourth Edition of the game every character felt the same, Perkins said that there was no symmetrical design between classes, and that the game was designed so that at each level of play no character felt "like crap." However, he said, "classes gain features asymmetrically, and every class has its thing ... and feels very different from others."
Perkins ended the session by saying that there would be a new line of tie-in fiction featuring iconic characters to fit alongside both the Tyranny of Dragons event and the launch of Fifth Edition D&D.
Above all of these things, though, is the confirmation that Modrons are back in the game - Wizards of the Coast showed concept art and everything. No take-backsies on this one or we riot.
Wondering what else was going on at PAX East in Tabletop games? Check out everything there is to know about the convention's tabletop game news right here.


Under Secretary Kappos also participated in the Federal Circuit Bar Association's China IP Adjudication Conference at Renmin University in Beijing as part of USPTO's ongoing effort to coordinate IP policy efforts – from patent examining administrative processes to the judicial terrain – and to support trade agreements that will open up markets to U.S. companies, while working to aggressively investigate unfair trade practices taking place anywhere in the world.
The USPTO has made progress in patent sharing with China's State Intellectual Property Office (SIPO). Moreover, bilateral relationships through PPH offer China and the U.S. an important forum to iron out best practices between our country's patent systems, on an administrative level. We must continue to engage with our trading partners in developing constructive, cooperative solutions, while ensuring IP systems adhere to rule of law, transparency, and the free flow of information.
Undoubtedly, this is an era during which innovation--and the protections our patent authorities provide for that innovation--will write the next chapter of global growth.


text:
Cambridge Bancorp (CATC.OQ)
CATC.OQ on NASDAQ Stock Exchange Capital Market
Denis Sheahan
Albert Rietheimer
51 2014 Chief Financial Officer, Executive Vice President
Michael Duca
Executive Vice President - Head of Wealth Management
2014 Executive Vice President - Consumer Banking Director
Martin Millane
2014 Chief Lending Officer, Executive Vice President
Chief Investment Officer, Senior Vice President
Robert Siegrist
Senior Vice President - Marketing Director
Noreen Briand
Senior Vice President - Human Resources Director
Susan Martore-Baker
President of Cambridge Trust Company of New Hampshire and Senior Vice President
Robert Bettacchi
63 Director
Jeanette Clough
Sarah Green
Hambleton Lord
Leon Palandjian
Robert Peterkin
R. Gregg Stone
Linda Whitlock
Kathryn Willmore
Byron Woodman
Mr. Denis K. Sheahan is Chairman of the Board, President, Chief Executive Officer of the Company. Sheahan served as chief financial officer for Rockland Trust from May 2000 until assuming the COO role in September 2013. He also served as senior vice president and controller. Prior to joining Rockland Trust Company, Sheahan served as vice president of Finance for BayBanks, Inc. Sheahan has been a member of the Board of Directors of the Old Colony YMCA since 2003, serving as its Chairman of the Board from 2011-2013. He is also a member of the Old Colony YMCA Executive Committee, and is actively involved in youth sports programs. He is a graduate of the Cork Institute of Technology, Cork, Ireland and received a Master's of Business Administration from Boston University.
Mr. Albert R. Rietheimer is Chief Financial Officer, Executive Vice President of the Company. He has over twenty-five years of experience in corporate finance. Prior to joining Cambridge Trust Company, he was chief financial officer and treasurer of Bancorp Rhode Island, a position he held since 1996. Mr. Rietheimer began his finance career in 1978 at Peat, Marwick, Mitchell & Co. in Boston.
Mr. Michael A. Duca is Executive Vice President - Head of Wealth Management of the Company. He joined Cambridge TrustCompany in 2006. Mr. Duca is the former Managing Director and Office Directorof Deutsche Bank Private Wealth Management in Boston. While at Deutsche Bank,he oversaw new business development and client management in the Boston areaand was the senior contact person for high-net-worth and ultra-high-net-worthclients, their ... attorneys, and other advisors. With more than 25 years offinancial services experience, Mr. Duca joined Private Wealth Management inAugust 2004 from Credit Suisse First Boston, where he was a Managing Directorin the private client services group. He was also a Managing Director and SalesManager at Donaldson, Lufkin and Jenrette (now part of Credit Suisse) and hasheld positions in fixed income sales at Goldman Sachs and Co. Mr. Duca servesas a research fellow to the Massachusetts Institute of Technology's Age Lab. He earned a B.A. in Economics from Holy Cross College in Massachusetts in 1974 andan M.B.A. in Finance from The Darden School of Graduate Business Administration at the University of Virginia in 1976.
Mr. James F. Spencer is Chief Investment Officer, Senior Vice President of the Company. He oversees the Wealth Management investment group, whichincludes portfolio managers in Massachusetts and New Hampshire, as well asanalysts, a fixed income specialist, compliance officer and trader in our Harvard Square office. As Chief Investment Officer, he is responsible for Cambridge Trust's investment management process, investment policy and research.
Mr. Robert J. Bettacchi is Director of the Company. He is Principal/Owner of RJB Consulting, he is Retired SVP of W. R. Grace & Co. and President of Grace Performance Chemicals.
Ms. Jeanette G. Clough is Director of the Company. She serves as President & Chief Executive Officer, Mount Auburn Hospital.
Ms. Sarah G. Green is Director of the Company. She is Retired First Vice President & Chief Operating Officer, Federal Reserve Bank of Richmond.
Mr. Hambleton Lord is Director of the Company. He serves as Managing Director, Launchpad Venture Group.
Mr. Leon A. Palandjian is Director of the Company. He serves as Lead Director, Cambridge Bancorp and Cambridge Trust Company; Managing Member, Intercontinental Capital Management, LLC; Portfolio Manager, Techari Global Healthcare Fund.
Dr. Robert S. Peterkin is Director of the Company. He is a Professor of Practice Emeritus, Harvard Graduate School of Education; Principal, Peterkin Consulting Group.
Mr. R. Gregg Stone, is Director of the Company. He is sole manager of Kestrel Ventures, LLC., the general partner of two venture funds - Kestrel Venture Partners, L.P., and Mass Ventures Equity Fund, L.P. Investments have included healthcare, software, retail and manufacturing companies. He serves as a director of six private companies and as a board observer to three others. Past directorships have included IntraServer, merged into LSI Logic, and Progressive Technologies, merged into Brooks Automation. Before founding Kestrel in 1996, he worked at Pell, Rudman & Co. Inc, a Boston-based investment adviser, and served as the general partner of its venture fund. He joined Pell, Rudman after practicing law at the firm of Hemenway & Barnes in Boston. He holds J.D. and A.B. degrees from Harvard. He is also on the boards of the Beth Israel Deaconess Medical Center, Boys & Girls Clubs of Boston and Camp Pasquaney.
Ms. Linda Whitlock is Director of the Company. Ms. Whitlock was the Nicholas President and Chief Executive Officer of Boys & Girls Clubs of Boston, a non-profit organization that provides affordable, high-impact programs to at-risk youth, from 1999 to 2008. Before that, Ms. Whitlock has held administrative positions at, and been a member of the faculties of, Buckingham Browne & Nichols School and Concord Academy in Massachusetts. She has also taught at MIT, Tufts and the University of Michigan. Ms. Whitlock currently serves on the boards of Cambridge Trust Company, Brigham and Women's Hospital, Brandeis University, Boston World Partnerships, the Boston Museum, and Boston Afterschool and Beyond. Ms. Whitlock received an A.B. in psychology from Mount Holyoke College and an A.M. in Psychology from the University of Michigan.
Ms. Kathryn A. Willmore is Director of the Company. She is Retired Vice President & Secretary of the Corporation, Massachusetts Institute of Technology.
Mr. Byron E. Woodman Jr., is Director of the Company. He is President, Monument Group Wealth Advisors, LLC; Monument Group Tax Advisors, LLC; and Woodman & Eaton, P.C.
Sullivan (John Joseph)
290 $84.99
Schmidt (Cathleen Agnes)
Palandjian (Leon Aghababai)
Green (Sarah Gisel)
Meehan (Thalia M)
Stone (Robert Gregg III)
Clough (Jeanette Gail)
Lord (Hambleton Douglas)
Jankowski (Edward F)
Rose (Jody A)
Whitlock (Linda)
Millane (Martin B. Jr.)
1,248 $0.00
Sheahan (Denis K)
Carotenuto (Michael F)
Thompson (Mark D)
Pline (Jennifer A)
Pueyo (Pilar)
Mooney (Kerri)
Willis (Jennifer M)
Nevatia (Puneet)

redpajama_set_name: RedPajamaCommonCrawl


text:
The 2010 World Mixed Doubles Curling Championship was held in Chelyabinsk, Russia from April 18–24, 2010. The event was held in conjunction with the 2010 World Senior Curling Championships. Many of the teams faced delays or withdrew from the championship due to the air travel disruption after the 2010 Eyjafjallajökull eruption.

Teams

Not Competing
The following teams were initially listed as participating in this event but are not included on the most recently updated schedule.

Competition Status following the Icelandic volcano incident

The following teams officially withdrew from the Championship due to the Icelandic volcano incident.

The following teams were delayed by the Icelandic volcano incident but still were able to make it to the Championship. Because these teams were delayed, the draws they were scheduled to play in were postponed until they arrived in Chelyabinsk.

Round robin

Results

All draw times are listed in Yekaterinburg Time (UTC+05).

Blue group

April 18
Draw 2
13:00

April 19
Draw 4
09:00

Draw 6
17:00

April 20
Draw 8
13:00

April 21
Draw 11
13:00

Draw 12
17:00

April 22
Draw 14
13:00

Draw 15
17:00

Red group

April 18
Draw 2
13:00

April 19
Draw 4
09:00

Draw 5
13:00

April 20
Draw 7
09:00

Draw 9
17:00

April 21
Draw 11
13:00

April 22
Draw 13
09:00

Draw 14
13:00

Draw 15
17:00

Green group

April 18
Draw 1
09:00

Draw 3
17:00

April 19
Draw 5
13:00

Draw 6
17:00

April 20
Draw 7
09:00

Draw 8
13:00

Draw 9
17:00

April 21
Draw 10
09:00

Draw 12
17:00

April 22
Draw 13
09:00

Draw 15
17:00

Tie-breaker
Friday, April 23, 08:30

Friday, April 23, 11:30

Playoffs

Qualification Game
Friday, April 23, 15:30

Quarterfinals
Friday, April 23, 19:30

Semifinals
Saturday, April 24, 9:00

Bronze-medal game
Saturday, April 24, 14:00

Gold-medal game
Saturday, April 24, 14:00

References
General

Specific

World Mixed Doubles Curling Championship, 2010
World Mixed Doubles Curling Championship
2010 in Russian sport
International curling competitions hosted by Russia

redpajama_set_name: RedPajamaWikipedia


text:
Q: Set EXECUTE sp_executesql result into a variable in sql I have to set a dynamic sql query result to a variable. My sql query is :
DECLARE @ResultString NVARCHAR(MAX)
DECLARE @Qry NVARCHAR(MAX)

SET @Qry='SELECT Test FROM MTest22Dec WHERE ID = 1'
EXECUTE sp_executesql @Qry, N'@Result NVARCHAR(MAX) OUTPUT', @Result=@ResultString OUTPUT
PRINT @ResultString

But @ResultString is printing empty string although there is record in database table.
What is wrong in this query?
thanks

A: You need to assign the result of select to variable inside Dynamic statement.
Change you query like this.
DECLARE @Result NVARCHAR(MAX)
DECLARE @Qry NVARCHAR(MAX)

SET @Qry='SELECT @Result = Test FROM MTest22Dec WHERE ID = 1'

EXECUTE Sp_executesql @Qry, N'@Result NVARCHAR(MAX) OUTPUT', @Result OUTPUT

PRINT @Result

A: You have to set the output variable somewhere, eg.
SET @Qry='SELECT @Result = Test FROM MTest22Dec WHERE ID = 1'

A: Try this:
DECLARE @ResultString NVARCHAR(MAX)
DECLARE @Qry NVARCHAR(MAX)

SET @Qry='SELECT @ResultString = Test FROM MTest22Dec WHERE ID = 1'
EXECUTE sp_executesql @Qry, N'@ResultString NVARCHAR(MAX) OUTPUT', @ResultString OUTPUT
PRINT @ResultString

A: Try this :
Declare @Query NVARCHAR(100)
Declare @ResultString varchar(50)

set @Query =N'select @ResultString=Test from dbo.MTest22Dec where id = @id'

exec sp_executesql @Query, N'@id int,@ResultString varchar(20) output',
@id = 1,@ResultString=@ResultString output

print @ResultString

redpajama_set_name: RedPajamaStackExchange


text:
What is an exception What are the advantages of using exception handling in a program in C++?
Exception handling C++ exception Throw exception C++ Std::exception Exception class C++ Exception error
Arguments for using Exceptions
Exceptions separate error-handling code from the normal program flow and thus make the code more readable, robust, and extensible.
Throwing an exception is the only clean way to report an error from a constructor.
Exceptions are hard to ignore, unlike error codes.
Exceptions are easily propagated from deeply nested functions.
Exceptions can be, and often are, user defined types that carry much more information than an error code.
Exception objects are matched to the handlers by using the type system.
Arguments against using Exceptions
Exceptions break code structure by creating multiple invisible exit points that make code hard to read and inspect.
Exceptions easily lead to resource leaks, especially in a language that has no built-in garbage collector and finally blocks.
Learning to write Exception safe code is hard.
Exceptions are expensive and break the promise to pay only for what we use.
Exceptions are hard to introduce to legacy code.
Exceptions are easily abused for performing tasks that belong to normal program flow.
Exceptions have been a part of C++ since early 1990s and are sanctioned by the standard to be the mechanism for writing fault-tolerant code in this language. However, many developers for various reasons choose not to use exceptions, and voices that are skeptical of this language feature are still numerous and loud: Raymond Chen's article Cleaner, more elegant, and wrong, Joel Spolsky's blog Exceptions, and Google C++ Style Guide are some of the frequently quoted texts that advise against the use of exceptions.
2. Arguments for using Exceptions
2.1 Exceptions separate error-handling code from the normal program flow and thus make the code more readable, robust, and extensible.
2.2 Throwing an exception is the only clean way to report an error from a constructor.
2.3 Exceptions are hard to ignore, unlike error codes.
2.4 Exceptions are easily propagated from deeply nested functions.
2.5 Exceptions can be, and often are, user defined types that carry much more information than an error code.
2.6 Exception objects are matched to the handlers by using the type system.
3. Arguments against using Exceptions
3.1 Exceptions break code structure by creating multiple invisible exit points that make code hard to read and inspect.
3.2 Exceptions easily lead to resource leaks, especially in a language that has no built-in garbage collector and finally blocks.
3.3 Learning to write Exception safe code is hard.
3.4 Exceptions are expensive and break the promise to pay only for what we use.
3.5 Exceptions are hard to introduce to legacy code.
3.6 Exceptions are easily abused for performing tasks that belong to normal program flow.
What is a user defined exception What are the advantages of using exception handling mechanism in a program when do we use multiple catch handlers?
What are the advantages of exception handling in C Plus Plus?
What is meant by exception handling?
What is an exception in software?
Rather than taking a side in this debate, I am trying to present a balanced view of pros and cons of using exceptions. The purpose of this article is not to convince readers to use exceptions or error codes, but help them make an informed decision that is best for their particular project. I have structured the article as a list of six arguments for using exceptions and six arguments against it that can often be heard in the C++ community.
To illustrate the point, we'll compare the usage of two simple socket libraries that differ only in the error handling mechanism. Here is how we could use them to fetch HTML from a web site:
string get_html(const char* url, int port) { Socket client(AF_INET, SOCK_STREAM, IPPROTO_TCP); client.connect(url, port); stringstream request_stream; request_stream << "GET / HTTP/1.1\r\nHost: " << url << "\r\nConnection: Close\r\n\r\n"; client.send(request_stream.str()); return client.receive(); }
Now, consider a version that uses error codes:
Socket::Err_code get_html(const char* url, int port, string* result) { Socket client; Socket::Err_code err = client.init(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (err) return err; err = client.connect(url, port); if (err) return err; stringstream request_stream; request_stream << "GET / HTTP/1.1\r\nHost: " << url << "\r\nConnection: Close\r\n\r\n"; err = client.send(request_stream.str()); if (err) return err; return client.receive(result); }
In both cases, the code does the same thing, error handling is delegated to the caller, resource cleanup is performed by destructors. The only difference is that in the former case, the socket library throws exceptions in case of failure, and in the latter case, error codes are used.
It is easy to notice that the sample with exceptions has cleaner and simpler flow, without a single if branch to disrupt it. Error handling is completely hidden and only the "normal" code flow is visible. The infrastructure for propagating exceptions is generated by the compiler: in case of an exception, the stack will "unwind" correctly, meaning that local variables in all stack frames will be destroyed properly - including running the destructors.
In fact, sample 2 as shown here is probably even simpler and cleaner than it would be in most cases: we are using only one library within the function, and return that library's error code. In practice, we would probably have to take into account different error code types that we would hit within the function, and then we would need to map all these error codes to the type we are returning from the function.
What about robustness? When exceptions are used, it is the compiler that produces the code for the "error path" and the programmer does not do it manually, meaning there are less opportunities for introducing bugs. That is especially important when the code is changed - it is very easy to forget updating the error-handling part when a change is introduced to the normal code path, or introduce a bug when doing so.
The purpose of a constructor is to establish the class invariant. To do that, it often needs to acquire system resources or in general perform an operation that may fail. If a constructor fails to establish the invariant, the object is in invalid state and the caller must be notified. Clearly, error codes cannot be used for that purpose because a constructor is not allowed to return a value. However, an exception can be thrown from a constructor in case of failure, and by doing this, we prevent creation of an invalid object.
What are some alternatives to throwing an exception from a failing constructor? One of the most popular is the "two-stage construction" idiom that is used in our sample 2. The process of constructing an object is split into two steps: the constructor performs only the part of initialization that cannot fail (i.e., setting primitive type members), and the part that can fail goes into a separate function that usually has a name such as init() or create() and returns an error code. Establishing the class invariant in this case involves not only constructing the object, but also calling this other function and checking the returned error code. The downsides of this approach are pretty obvious: it takes more work to correctly initialize an object and it is easy to end up with an object in invalid state without knowing it. Furthermore, copy construction cannot be implemented this way - there is no way to tell the compiler to insert the second step and check for the error code. Having said that, this idiom is pretty effectively used in many libraries, and with some discipline, it may be successful.
Another alternative to throwing an exception from a constructor is maintaining a "bad state flag" as a member variable, setting that flag in the constructor, and exposing a function to check the flag. The standard IO streams use this approach:
ifstream fs("somefile.txt"); if (fs.bad()) return err_could_not_open;
This technique is similar to the two-stage construction idiom. It requires an additional data member - the state flag which can be a prohibitive expense in some scenarios. On the other hand, copy construction can be implemented this way, although it is far from being safe - for instance, standard containers do a lot of copying internally and there is no way of making them check for the state flag. However, just as with the two-stage construction, this approach can work as long as we know what we are doing.
Other alternatives include setting some global value such as errno in the constructor and hoping that the caller would remember to check it. This approach is clearly inferior to the previous ones and we won't discuss it here further.
To illustrate this argument, all we have to do is remove error checking from sample 2 - it will compile just fine and as long as there are no run time errors, it will work fine as well. However, imagine there was an error in the call to init(): the object client will be in invalid state and when its member functions are invoked, pretty much anything can happen depending on the internal implementation of the Socket class, Operating System, etc.; the program may crash immediately or it can even execute all the functions but do nothing and return without any sign that something went wrong - except for the result. On the other hand, if an exception was thrown from the constructor, the invalid object would have never even been constructed and the execution would continue at the exception handler. The usual phrase is: "we would get an exception right in our face".
But is it really that hard to ignore an exception? Let's go up the stack and see the caller of get_html():
try { string html = get_html(url); } catch (...) {}
This horrible piece of code is known as "swallowing exceptions" and the effect is not much different than ignoring error codes. It does take more work to swallow exceptions than to ignore error codes and these constructs are easier to detect during code reviews, but the fact is that exceptions are still pretty easy to ignore, and people do it.
However, even if they are easy to ignore, exceptions are easier to detect than error codes. On many platforms, it is possible to break when an exception is thrown if the process is run from a debugger. For instance, GNU gdb supports "catchpoints" for that purpose, and Windows debuggers support the option "break if an exception is thrown". It is much harder, if not impossible, to get a similar functionality with error codes.
We are often not able to deal with an error at the point it is originally detected. We need to propagate the information about the error to the level where we can handle it, and exceptions enable jumping directly to the handler without writing all the plumbing manually.
Back at our sample 1 with the Socket class. Assume get_html() is invoked by a function get_title() that gets called by a UI event handler. Something like:
string get_title(const string& url) { string markup = get_html(url); HtmlParser parser(markup); return parser.get_title(); }
Exceptions would probably be handled at the UI event handler level:
void AppDialog::on_button() { try { string url = url_text_control.get_text(); result_pane.set_text( get_title(url); } catch(Socket::Exception& sock_exc) { display_network_error_message(); } catch(Parser::Exception& pars_exc) { display_parser_errorMessage(); } catch(...) { display_unknown_error_message(); } }
In the sample above, get_title() does not contain any code for propagating the error information from get_html() to on_button(). If we used error codes instead of exceptions, get_title() would need to check for the return value after calling get_html(), map that value to its own error code, and pass the new error code back to on_button(). In other words, using exceptions would make get_title() look something like our sample 1, and error codes would turn it into something similar to sample 2. Something like:
enum Get_Title_Err {Get_Title_Err_OK, Get_Title_Err_NetworkError, Get_Title_Err_ParserError}; Get_Title_Err get_title(const string& url, string* title) { string markup; Socket::Err_code sock_err = get_html(url.c_str(), &markup); if (sock_err) return Get_Title_Err_NetworkError; HtmlParser parser; HtmlParser::Err_code parser_err = parser.init(markup); if (parser_err) return Get_Title_Err_ParserError; return parser.get_title(); }
Just as with sample 2, sample 7 can easily get more complicated if we try propagating more specific error codes. In that case, our if branches would need to map error codes from the libraries to appropriate Get_Title_Err values. Also, note that we show only a part of the function nesting in this sample - it is not hard to imagine the work needed to propagate an error code from deep within the parser code to our get_title function.
An error code is usually an integer type and can carry only so much information about the error. Microsoft's HRESULT type is actually a pretty impressive attempt to pack as much information in a 32-bit integer as possible, but it clearly shows the limits of that approach. Of course, it is possible to have an error code that is a full-blown object, but the cost of copying such an object multiple times until it reaches the error handler makes this technique not desirable.
On the other hand, exceptions usually are objects and can carry a lot of useful information about the error. It is a pretty common practice for an exception to carry information about the source file and line that it was thrown at (using macros such as _FILE_ and _LINE_) and they can even automatically send messages to a logging system.
Why is it expensive to use objects for return error codes and not for exceptions? There are two reasons: first, an exception object is created only if an error actually happens, and that should be an exceptional event - pun intended. The error code needs to be created even if the operation succeeds. Another reason is that an exception is usually propagated by reference to the handler and there is no need to copy the exception object.
Let's expand a little on our sample 6 and display a specific error message in case the error happened when establishing the socket connection:
void AppDialog::on_button() { try { string url = url_text_control.get_text(); result_pane.set_text( get_title(url)); } catch(Socket::SocketConnectionException& sock_conn_exc) { display_network_connection_error_message(); } catch(Socket::Exception& sock_exc) { display_general_network_error_message(); } catch(Parser::Exception& pars_exc) { display_parser_errorMessage(); } catch(...) { display_unknown_error_message(); } }
Sample 8 demonstrates the use of the type system to classify exceptions. The handlers go from most specific ones to the most general one, and this is expressed with the language mechanism that serves the purpose: inheritance. In our sample, Socket::SocketConnectionException is derived from Socket::Exception.
If we were using error codes instead of exceptions, the error handler would probably be a switch statement and each individual case would handle a value for the error code. default would most probably correspond to catch(...). It is doable, but not quite the same. In sample 8, we use a handler for Socket::Exception to handle all exceptions from the socket library except SocketConnectionException that we handle just above it; with error codes, we would need to list all these other error codes explicitly. If we forget one, or maybe add a new error code later but forget to update it... you get the picture.
That sounds exactly the opposite of what we talked about in 2.1. How is it possible that exceptions simultaneously make the code hard to read and easy to read? To understand this point of view, remember that by using exceptions we managed to display only the "normal flow". The error-handling code still gets generated by the compiler for us and it has its own flow which is orthogonal to the flow of the code we wrote. In effect, the normal code flow is cleaner and easier to read and understand with exceptions, but that is only a part of the story. Now we need to be aware that at any function call, we introduce an invisible branch that, in case of an exception, immediately exists (or jumps to the handler if it is in the same function). That sounds worse than goto and comparable to longjmp, but in fairness, C++ exceptions are much safer to use than longjmp: as we saw in section 2.1, the compiler generates the code that unwinds the stack.
Still, the problem with readability is not necessarily bogus: if we are taking a quick look at a piece of code to learn what it does, the normal flow is really all we need, but what if we need to get really knowledgeable about it? For instance, imagine you need to do a code review or extend a function - would you rather have all possible code paths right in front of you, or having to guess which function can throw an exception and under what circumstances? Granted, it is much less of a concern if you make sure that exceptions are used only for error handling, and that the code was originally written with exception-safety in mind.
To understand what we are talking about here, let's for a moment forget object oriented programming with its classes, destructors, and exceptions, and fall back to good old C. Many functions take the following form:
void func() { acquire_resource_1(); acquire_resource_2(); use_resources_1(); use_resources_2(); use_resources_3(); release_resource_2(); release_resource_1(); }
Basically, we acquire some resources at the beginning of the function, use them to do some processing, and then release them. The resources in question can come from the system (memory, file handles, sockets...), or external libraries. In any case, they are limited and need to be released, or may be exhausted at some point and that's what we call a "leak".
So where is the problem? Our function from sample 9 is an example of well-structured code with a single entry and a single exit, and we will always clean up the resources at the end of the function. Imagine now that something can go wrong at use_resources_1(). In that case, we don't want to execute the rest of the use_resources_... functions, but report an error and exit immediately. Well, not immediately - we need to clean up the resources first. How do we do it best with a language like C? Let's just say the discussions on that topic involve even more passion than our little "exceptions vs. error codes" dilemma: some people copy and paste the clean-up code and call it whenever they exit; other ones make macros for that purpose when possible; there are developers who preserve the "SESE" structure of the function and introduce if-else branches for each function that can fail. Such functions look like a closing angle bracket ">" and some call it "arrow anti-pattern". Many C developers use goto to jump to the cleanup part of the function.
One way or another, it is a mess even without exceptions. What if we switch to C++ and use_resources_1() to throw an exception in case of error? The way the function is written, the cleanup part will not be executed and we will have a leak. How would a garbage collector and finally blocks help here? Pretend for a moment that Java does not have networking support in the standard library and that we use something similar to our sample 1 but from Java:
public String getHtml(String url, int port) throws (Socket.Exception) { Socket client = null; try { client = new Socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); client.connect(url, port); StringBuffer requestStream = new StringBuffer("GET / HTTP/1.1\r\nHost: "); requestStream.append(url).append("\r\nConnection: Close\r\n\r\n"); client.send(requestStream.toString()); return client.receive(); } finally { if (client != null) client.close(); } }
In the getHtml method above, we have acquired some resources: a socket, a string buffer, and a couple of temporary string objects. The garbage collector takes care of the objects that ultimately need to release only memory to the system, and the socket is closed in the finally block which is executed when we leave the try block - whether we do it "normally" or via an exception.
C++ does not have a built-in garbage collector, nor does it support finally blocks; how come our function from sample 1 (or sample 2 for that matter) does not leak? The answer is usually called RAII (resource acquisition is initialization), and it really means that objects declared as local variables get destroyed after they go out of scope, regardless of the way they exit that scope. When they get destroyed, the destructors are executed first, and then the memory is returned to the system. It is the burden of the destructors to release all resources acquired by the objects - in fact the destructor of the Socket class used in sample 1 probably looks very much like the body of the finally block in sample 10. The best part is that in C++, we need to write this clean-up code only once and it is executed automatically each time an object goes out of scope. Another nice aspect of RAII is that it treats all resources in a uniform way - there is no need to distinguish between "GC-collectible" resources and "unmanaged" ones and leave the former to GC and clean up the latter in finally blocks: the cleanup is invisible, yet it reliably happens, much like error reporting with exceptions.
Am I saying here that the lack of a garbage collector and finally blocks is not really a reason not to use exceptions in C++ because RAII is a superior method of managing resources? Yes and no. RAII is indeed superior to the combination of a garbage collector and finally blocks, and it is a very straightforward idiom and easy to use. Yet, in order to get the benefits of RAII, it needs to be used consistently. There is a surprising amount of C++ code out there that looks like:
string get_html(const char* url, int port) { Socket client = new Socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); client->connect(url, port); stringstream request_stream; request_stream << "GET / HTTP/1.1\r\nHost: " << url << "\r\nConnection: Close\r\n\r\n"; client->send(request_stream.str()); string html = client->receive(); delete client; return html; }
In sample 11, RAII is used for all resources except the socket - yet it is a disaster waiting to happen: if an exception is thrown anywhere in the function, we leak a socket. If someone unplugs a network cable, our program may crash very quickly. Sure, it is possible to wrap the function in a try-catch block and then close the socket both in the catch block and after it - thus simulating the non-existing finally construct, but it is exactly the kind of repetitive and tedious task that sooner or later is forgotten and we have a serious bug.
But how common this kind of code is anyway? Creating objects on stack, when possible, is not only safer but also easier than pairing new and delete - one would expect that most programmers use RAII all the time. Unfortunately, this is not really the case. There is a lot of code out there that looks like sample 11. For instance, find the official sample code for the SAX2 parser of the popular Xerces-C library - it creates objects on the heap and deletes them after they are used - in case of an exception, there is a leak. In the early 1990s, it was considered "more object oriented" to create an object on the heap even if there were no reasons to do so. Now, many young C++ programmers learn Java first at universities and write C++ code in a Java-like manner rather than idiomatic C++. One way or another, there is a lot of existing code that does not rely on deterministic destructors to automatically release resources. If you are dealing with a code base like that, the only sane thing to do is use error codes and turn the exceptions off.
Note that preventing resource leaks is only a part of the exception safety puzzle. Sometimes a function needs to be transactional: it needs either to succeed or leave the state unchanged. In this scenario, we need to roll back the operation in case of failure before leaving the function. Unsurprisingly, we again turn to destructors to trigger such an operation if an exception is thrown. This idiom is called "Scope Guard" and rather than discussing it here, I suggest reading the original article by Andrei Alexandrescu and Petru Marginean.
The usual counter argument to this statement is that error handling in general is hard, and exceptions make it easier, not harder. While there is a lot of truth in that, the issue of the learning curve remains: complex language features often do help experienced programmers simplify their code, but the beginners mostly see the added pain of learning. To use exceptions in production code, a C++ programmer not only has to learn the language mechanism, but also the best practices of programming with exceptions. How soon a beginner learns to never throw from a destructor? Or use exceptions for exceptional conditions only and never for the normal code flow? Or catch by reference, and not by value or a pointer? How about usefulness (or the lack or thereof) of exception specifications? Exception safety guarantees? Dark corners, such as polymorphic throwing?
From a "glass half full" point of view, with exceptions or without them C++ has always been an expert-friendly language that offers very little hand-holding to beginners. Rather than relying on the constraints of the language, a good C++ programmer turns to the community to teach him the best practices of using the language. The guidelines from the community change faster than the language itself: someone who switched from C++ to Java in 1997 often gets very confused when presented with modern C++ code - it looks different, yet the language itself has not changed much. Back to the exceptions, the C++ community learned a lot on how to effectively use them since they were first introduced to the language; someone who follows new publications and newsgroups should pick up the best practices with some effort. A good coding standard that follows the community's best practices helps a lot with the learning curve.
When talking about the performance impact of a language feature or a library, usually the best advice to a developer is to measure and decide for himself or herself whether there is any performance impact and if it is acceptable in their scenarios. Unfortunately, sometimes it gets pretty hard to follow this advice when it comes to exceptions, mostly because the performance of an exception handling mechanism is very implementation dependent; therefore, the conclusions made based on measurements with one compiler may be invalid if the code is ported to another compiler, or even another version of the same compiler. At least, the good news is that compilers are getting better in producing efficient code in the presence of exceptions and it is likely that if exceptions are not impacting the performance of your code now, they will do it even less in the future.
To understand the performance impact of exception handling in general, I strongly advise reading Chapter 5.4 of Technical Report on C++ Performance (draft). It discusses in some detail the sources of performance overhead: the code added to try-catch blocks by the compiler, impact on the regular functions, and the cost of actually throwing an exception. It also compares the two most common implementation approaches: the "code" approach where the code is added to each try-catch block, and the "table" approach where the compiler generates static tables.
After getting familiar with the performance impact scenarios of exceptions in general, the best thing to do is research the topic for your particular platform and compiler. A very nice and relatively recent presentation given by Microsoft's Kevin Frei can be found at the Northwest C++ Users Group and it covers the Visual C++ compiler for 32 and 64 bit Windows platform. Another very interesting text related to the GNU C++ compiler on Itanium is Itanium C++ ABI: Exception Handling.
Before concluding the discussion on performance and exceptions, it would be worthwhile to add that current C++ implementations do not offer predictability guarantees for exceptions, which make them unsuitable for hard real-time systems.
In other words, exception safety must never be an afterthought. If the code is written without exceptions in mind, it is much better to keep exceptions out of it or completely rewrite it - there are just too many ways things can go wrong. In this aspect, it reminds me of making a code thread safe if it was originally written without thread safety in mind - just don't do it! Not only is it hard to review the code for potential problems, but more importantly, it is hard to test. How are you going to trigger all the possible scenarios that lead to exceptions being thrown?
On the other hand, if the code base is modular, it is quite possible to write new code with exceptions that would peacefully coexist with the old code. The important thing is to draw the boundaries and not let exceptions cross them.
Nice aspects of using exceptions, especially the fact that they can be easily propagated from deeply nested code structures, make them tempting to be used for tasks other than error handling - most likely for some kind of poor man's continuations.
Almost always, using exceptions to affect the "normal" flow is a bad idea. As we already discussed in section 3.1, exceptions generate invisible code paths. These code paths are arguably acceptable if they get executed only in the error handling scenarios. However, if we use exceptions for any other purpose, our "normal" code execution is divided into a visible and invisible part and it makes code very hard to read, understand, and extend.
Even if we accept that exceptions are meant to be used for error handling only, sometimes it is not obvious if a code branch represents an error handling scenario or normal flow. For instance, if std::map::find() results in a value not found, is it an error or normal flow? Sometimes, an answer is easier to find if we think in terms of "exceptional", rather than "error" state. In our example, is it an exceptional case that a value is not found in a map? In general, the answer is probably "no" - there are many "normal" scenarios in which we are checking whether a value is stored in a map and branch based on the result - none of these branches is an error state. That's why map::find does not throw in case there is no requested key in the map.
How about a functionality that depends on users' input? If a user enters invalid data, is it better to throw or not? Users' input is better considered invalid unless proven otherwise and, if possible, there should be some function that validates the input before it is processed. For these validation functions, invalid data is an expected outcome, and there is no reason for it to trigger an exception. The problem is, it is often impossible to validate the input before actually processing it (parsers, for instance); in such cases, using exceptions to break the processing and report an error is often a good approach. HtmlParser from our sample 5 throws if it cannot parse broken HTML.
My personal opinion is that an exception should never be thrown if a program is working in normal conditions and with valid data. In other words, when you test a program by running it from a debugger, be sure to set a "catchpoint" that triggers whenever an exception is thrown. If the program execution breaks because an exception is thrown, that signals either a bug that should be taken care of, or a misuse of an exception handling mechanism and that should be fixed as well. Of course, an exception may be triggered due to abnormal conditions of the environment (for instance, network connection suddenly gets lost, or a font handle allocation fails) or invalid input data and in that case the exception is thrown for a good reason.
There is no simple answer to the "exceptions or error codes" question. The decision needs to be made based on a specific situation that a development team faces. Some rough guidelines may be:
If you have a good development process and code standards that are actually being followed, if you are writing modern-style C++ code that relies on RAII to clean up resources for you, if your code base is modular, using exceptions may be a good idea.
If you are working with code that was not written with exception safety in mind, if you feel there is a lack of discipline in your development team, or if you are developing hard real-time systems, you should probably not use exceptions.
the benefits of exception handling are as follows, (a) Exception handling can control run tune errors that occur in the program. (b) It can avoid abnormal termination of the program and also shows the behavior of program to users. (d) It can separate the error handling code and normal code by using try-catch block.
What is the advantage of exception handling ? Remove error-handling code from the software's main line of code. A method writer can choose to handle certain exceptions and delegate others to the caller. An exception that occurs in a function can be handled anywhere in the function call stack.
Exception handling is the process of responding to unwanted or unexpected events when a computer program runs. Exception handling deals with these events to avoid the program or system crashing, and without this process, exceptions would disrupt the normal operation of a program.
Definition: An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program's instructions. When an error occurs within a method, the method creates an object and hands it off to the runtime system.
How do you answer a question after a presentation in a non aggressive and professional manner?
Opinions expressed by Entrepreneur contributors are their own. You have just delivered an outstanding presentation, sales call or meeting, but now come the dreaded questions and answers. For most, ...
Handling difficult questions Question for presentation Feedback after presentation
c!ranboo là gì - Nghĩa của từ c!ranboo
4 tháng trước . bởi EquestrianBicycle
Kem chống nắng dr vita review
4 tháng trước . bởi TionalJurisprudence
File .h là gì
4 tháng trước . bởi InevitableAccounting
Top 20 cửa hàng c Huyện Yên Định Thanh Hóa 2022
5 tháng trước . bởi CellularDriver
Ctrl + c la gì
5 tháng trước . bởi UnlimitedCropping


text:
Amy Madigan Net Worth
How much is Amy Madigan Worth?
Amy Madigan Net Worth:
Amy Madigan net worth: Amy Madigan is an American actress, producer, and singer who has a net worth of $25 million. That is a combined net worth with her husband since 1983, fellow actor Ed Harris. Amy made her debut in 1981 and has more than 80 acting credits to her name. Some of notable movies include "Field of Dreams", "Uncle Buck" and "Gone Baby Gone".
Amy Madigan was born in Chicago, Illinois in September 1950. She made Madigan starred as Iris Crowe on the television series Carnivale from 2003 to 2005. From 2008 to 2009 she starred as Dr. Katharine Wyatt on the TV series Grey's Anatomy. In 2018 she starred as Diane Pierce on the series Ice. Madigan has starred in several movies including Love Child, Love Letters, Places in the Heart, Streets of Fire, Alamo Bay, Twice in a Lifetime, Nowhere to Hide, The Prince of Pennsylvania, Field of Dreams, Uncle Buck, The Dark Half, Female Perversions, Loved, With Friends Like These…, Pollock, A Time for Dancing, Winter Passing, Gone Baby Gone, Once Fallen, Virginia, That's What I Am, The Lifeguard, Sweetwater, Shirin in Love, Frontera, Grey Lady, Rules Don't Apply, Stuck, and more. Amy Madigan won a Golden Globe Award in 1990 for Roe vs. Wade.
Personal Life and Real Estate: Amy married fellow actor Ed Harris in 1983. They have a daughter together, Lily Dolores Harris.
For over two decades, Ed and Amy have owned a home in Malibu, California. It's unclear what they paid for the home, but today it's worth an estimated $5 million. In 1998 they paid $660,000 for the undeveloped 2-acre property immediately next door. They tried to sell this plot in 2015 for $2.6 million but appear to still be the owners as of this writing.
Ed Harris Net Worth
Amy Ryan Net Worth
Amy Smart Net Worth
Date of Birth: Sep 11, 1950 (70 years old)
Profession: Actor, Film Producer, Singer, Pianist, Voice Actor
Hugh O'Brian Net Worth
Mary Steenburgen Net Worth
Amy Grant Net Worth
Camilla Luddington Net Worth
Delta Burke Net Worth
Katherine Heigl Net Worth


text:
Kohl and Mitterand in Verdun, 1984
French President François Mitterrand and German Chancellor Helmut Kohl in 1984 at Douaumont cemetery.
The Battle of Verdun is considered by many the most blood-stained battlefield in world history. Never before or since has there been such a lengthy battle, involving so many men, situated on such a tiny piece of land.
The battle, which lasted from 21 February 1916 until 19 December 1916 caused over an estimated 800,000 casualties (dead, wounded, and missing). The battlefield was not even a square ten kilometers.
On September 25, 1984, 70 years after the start of the First World War, German Chancellor Helmut Kohl met the French president François Mitterrand at the Douaumont cemetery in Verdun.
The men stood in long, dark coats, without an umbrella. Mitterrand extended a hand to Kohl – a gesture of friendship symbolizing the lessons learned from a frightful past. Both heads of state were silent.
They firmly held onto each other's hands, for several minutes. The German Press described the scene as "a picture that will go down in history". It was a sign, above all, for the war-torn generation that the longstanding enmity between the Germans and the French has finally come to an end.
This gesture was made more powerful by the fact that Mitterrand had been injured in the Second World War in Verdun and captured by German soldiers and Kohl's father had fought in the First World War in the surrounding hills.
As the national anthems of both countries played, Mitterand and Kohl joined hands – a gesture of friendship symbolizing the lessons learned from a frightful past.
Helmut Kohl and François Mitterrand before the catafalque, covered on one side with a German flag and the other with a French flag.
The Battle of Verdun started on February 21st, 1916, and ended on December 16th, 1916. With a duration of 303 days, it is the longest battle in human history.
Although the exact casualty figure of the battle varies considerably according to sources, it is estimated that the casualties for both sides totaled between 700,000 and 800,000. With an estimated total casualty figure of 1.25 million, it was one of the most costly battles of World War I.
Despite the Germans' plan to "bleed France white", the Battle of Verdun resulted in roughly equal casualties on each side. Since artillery blasts buried many of the fallen or rendered their remains unidentifiable, most of the recovered bodies have since been placed in the Douaumont Ossuary, a sobering memorial that contains the mixed bones of at least 130,000 French and German soldiers.


Zarejestruj się lub Zaloguj aby dodać kamilgosek1980 do przyjaciół.
O sobie: Mark possesses more than thirty-five years' practical knowledge in control plus the development involving human potential. Today, with a backdrop as a possible management inside government along with a overseer at strony www firms to add Basic Design in addition to Dell, and the assistance of excellent management including David Maxwell, they have been able to bring his or her authority realizing with a amount where by they can advisor in addition to educate management worldwide.


The author focused in his first volume on middlegames, now his attention was drawn to endgames. Romain has carefully selected more than 496 positions, which arose in real games in the recent past. He separated the exercises into 11 different categories, covering both tactics and strategy, attack and defense. This book is a fantastic training tool for any player to improve his level of chess thinking.


The joy you are going to witness in Ahmedabad's Garba is hard to explain in words. There would be gleaming light everywhere, amazing sound systems, stage performances, and all people dressed in beautifully. What else you could wish for? The sound of striking dandiya sticks will make you dance over every single beat. No matter how tired you get, you won't stop dancing midst the energetic crowd for sure. Come with your partner dressed traditionally like steal the show.
The joy of dressing can make you win great prizes. That sounds amazing! The grand a setup of Garba in Ahmedabad, the greater the awards can be for the participants. Don't miss the chance to stand out from the crowd with a stunning attire and win amazing goodies. Tighten your seat belt and play with full energy and enthusiasm to rock the dance floor and grab some surprises in the form of prizes.
Adorn your dandiya sticks the way you are going to be dressed. The markets are filled with pretty design elements you can add to your sticks. Right from chirpy trinkets and gewgaws to other decorative stuff, match the elements of your sticks with your dress. Nothing can more be attractive than a complete coordinating look!
Vibrant colors and gorgeous dresses are what you need to get into the celebration mood. Expect this during Garba events in Ahmedabad. Take advantage of the occasion and showcase your traditional side in a colorful dress having vivid patterns and interesting design. One of the best ideas to shine with your dress is by wearing coordinating dresses with your family or friends' group.
Want to add a unique factor to your overall look in Dandiya celebrations? Go for a beautiful body art or temporary tattoos depicting the theme of Garba nights. This will enhance the feel of the festival season. Artistic colorful tattoos will go perfectly with your ethnic dress and make you shine the brightest with a glittery touch.
A happening city like Ahmedabad organizes amazing events where even celebrities perform. And, this is one of the major attractions of events in Ahmedabad for which people across India come. Especially, you can encounter popular celebrities performing on stage during Navratri time. Exciting, right?
Apart from wearing a traditional colorful dress, you can accentuate your look with other pretty elements like an embellished umbrella. Boys can wear an over decorated turban to complete their desi look while the girls can carry a decorative pot on the dance floor. With these small but unique elements, you can be the charm of the night.
The festival season is going on in every corner of India. Time to forget any grudges and celebrate the beautiful time with all your family members and friends. Enjoy the Dandiya nights to the fullest by embracing the facts shared above and get into the festive flavor.


text:
/*eslint strict:0, max-statements:0*/
var fs = require('fs');

casper.test.begin('Common assertions tests', 50, function(test) {
    casper.start('tests/site/index.html', function() {
        test.assertTextExists('form', 'Tester.assertTextExists() checks that page body contains text');
        test.assertTextExist('form', 'Tester.assertTextExist() checks that page body contains text [alias]');
        test.assertTextDoesntExist('blah', "Tester.assertTextDoesntExist() checks that page body doesn't contain provided text");
        test.assertSelectorHasText('h1', 'Title', 'Tester.assertSelectorHasText() works as expected');
        test.assertSelectorDoesntHaveText('h1', 'Subtitle', 'Tester.assertSelectorDoesntHaveText() works as expected');
        test.assert(true, 'Tester.assert() works as expected');
        test.assertTrue(true, 'Tester.assertTrue() works as expected [alias]');
        test.assertTruthy('1', 'Tester.assertTruthy() works as expected');
        test.assertFalsy('', 'Tester.assertFalsy() works as expected');
        test.assertNot(false, 'Tester.assertNot() works as expected');
        test.assertEquals(true, true, 'Tester.assertEquals() works as expected');
        test.assertEqual(true, true, 'Tester.assertEqual() works as expected [alias]');
        test.assertNotEquals(true, false, 'Tester.assertNotEquals() works as expected');
        test.assertEval(function() {
            return true;
        }, 'Tester.assertEval() works as expected');
        test.assertEvaluate(function() {
            return true;
        }, 'Tester.assertEvaluate() works as expected [alias]');
        test.assertEvalEquals(function() {
            return 42;
        }, 42, 'Tester.assertEvalEquals() works as expected');
        test.assertEvalEqual(function() {
            return 42;
        }, 42, 'Tester.assertEvalEqual() works as expected [alias]');
        test.assertElementCount('ul', 1, 'Tester.assertElementCount() works as expected');
        test.assertElementCount('li', 3, 'Tester.assertElementCount() works as expected');
        test.assertElementCount('address', 0, 'Tester.assertElementCount() works as expected');
        test.assertExists('body', 'Tester.assertExists() works as expected');
        test.assertExist('body', 'Tester.assertExist() works as expected [alias]');
        test.assertFail(function() {
            test.assert(false);
        }, 'Tester.assertFail() tests for a failing assertion');
        test.assertSelectorExists('body', 'Tester.assertSelectorExists() works as expected [alias]');
        test.assertSelectorExist('body', 'Tester.assertSelectorExist() works as expected [alias]');
        test.assertDoesntExist('foobar', 'Tester.assertDoesntExist() works as expected');
        test.assertNotExists('foobar', 'Tester.assertNotExists() works as expected [alias]');
        // using file:// protocol, HTTP status is always null
        test.assertHttpStatus(200, 'Tester.assertHttpStatus() works as expected');
        test.assertMatch("the lazy dog", /lazy/, 'Tester.assertMatch() works as expected');
        test.assertMatches("the lazy dog", /lazy/, 'Tester.assertMatches() works as expected [alias]');
        test.assertRaises(function() {
            throw new Error('plop');
        }, [], 'Tester.assertRaises() works as expected');
        try {
            test.assertRaises(function() {}, []);
            test.fail("Tester.assertRaises() doesn't pass when no error is thrown");
        } catch (err) {
            test.pass("Tester.assertRaises() doesn't pass when no error is thrown");
        }
        test.assertResourceExists(/index\.html/, 'Tester.assertResourceExists() works as expected');
        test.assertResourceExist(/index\.html/, 'Tester.assertResourceExist() works as expected [alias]');
        test.assertTitle('CasperJS test index', 'Tester.assertTitle() works as expected');
        test.assertTitleMatch(/test index/, 'Tester.assertTitleMatch() works as expected');
        test.assertTitleMatches(/test index/, 'Tester.assertTitleMatches() works as expected [alias]');
        test.assertType("plop", "string", "Tester.assertType() works as expected");
        test.assertInstanceOf("plop", String, "Tester.assertInstanceOf() works as expected");
        test.assertUrlMatch(/index\.html$/, "Tester.assertUrlMatch() works as expected");
        test.assertUrlMatches(/index\.html$/, "Tester.assertUrlMatches() works as expected [alias]");
        test.assertVisible('img', 'Tester.assertVisible() works as expected');
        test.assertAllVisible('li', 'Tester.assertAllVisible() passes as expected');
        test.assertFail(function(){
            test.assertAllVisible('img, p#hidden');
        }, 'Tester.assertAllVisible() fails as expected.');
        test.assertNotVisible('p#hidden', 'Tester.assertNotVisible() works as expected');
        test.assertInvisible('p#hidden', 'Tester.assertInvisible() works as expected [alias]');
        test.assertExists('div#exports', 'Tester.assertExists() works as expected with reserved word id');
    }).run(function() {
        test.done();
    });
});

casper.test.begin('Tester.assertField(): filled inputs', 7, function(test) {
    casper.start('tests/site/form.html', function() {
        this.fill('form[action="result.html"]', {
            'email':       '',
            'content':     '',
            'check':       false,
            'choice':      '',
            'topic':       '',
            'file':        '',
            'checklist[]': []
        });
        test.assertField('email', '', 'Tester.assertField() works as expected with inputs');
        test.assertField('content', '', 'Tester.assertField() works as expected with textarea');
        test.assertField('check', false, 'Tester.assertField() works as expected with checkboxes');
        test.assertField('choice', null, 'Tester.assertField() works as expected with radios');
        test.assertField('topic', '', 'Tester.assertField() works as expected with selects');
        test.assertField('file', '', 'Tester.assertField() works as expected with file inputs');
        test.assertField('checklist[]', [], 'Tester.assertField() works as expected with check lists');
    }).run(function() {
        test.done();
    });
});

casper.test.begin('Tester.assertField(): unfilled inputs', 7, function(test) {
    var fpath = fs.pathJoin(phantom.casperPath, 'README.md');
    var fileValue = 'README.md';

    if (phantom.casperEngine === 'phantomjs') {
        if (utils.matchEngine({
            name: 'phantomjs',
            version: {min: '2.0.0', max: '2.0.0'}
        })) {
            fileValue = '';
        } else {
            fileValue = 'C:\\fakepath\\README.md'; // phantomjs/webkit sets that;
        }
    }
    if (phantom.casperEngine === 'slimerjs' && !!utils.gteVersion(slimer.version, '1.0.0')) {
        fileValue = 'C:\\fakepath\\README.md';
    }

    casper.start('tests/site/form.html', function() {
        this.fill('form[action="result.html"]', {
            'email':       'chuck@norris.com',
            'content':     'Am watching thou',
            'check':       true,
            'choice':      'no',
            'topic':       'bar',
            'file':        fpath,
            'checklist[]': ['1', '3']
        });
        test.assertField('email', 'chuck@norris.com', 'Tester.assertField() works as expected with inputs');
        test.assertField('content', 'Am watching thou', 'Tester.assertField() works as expected with textarea');
        test.assertField('check', true, 'Tester.assertField() works as expected with checkboxes');
        test.assertField('choice', 'no', 'Tester.assertField() works as expected with radios');
        test.assertField('topic', 'bar', 'Tester.assertField() works as expected with selects');
        test.assertField('file', fileValue,
            'Tester.assertField() works as expected with file inputs');
        test.assertField('checklist[]', ['1', '3'], 'Tester.assertField() works as expected with check lists');
    }).run(function() {
        test.done();
    });
});

casper.test.begin('Tester.assertField(): nonexistent fields', 2, function(test) {
    casper.start('tests/site/form.html', function() {
        test.assertFail(function() {
            test.assertField('nonexistent', '');
        }, 'Tester.assertField() only checks for existing fields');
    }).run(function() {
        test.done();
    });
});

casper.test.begin('Tester.assertField(): CSS selectors', 1, function(test) {
    casper.start('tests/site/form.html', function() {
        this.fill('form[action="result.html"]', {
            'email': 'albert@camus.com'
        });

        test.assertField({
            type: 'css',
            path: '#email'
        },
            'albert@camus.com',
            'Tester.assertField() works as expected with CSS selectors'
        );
    }).run(function() {
        test.done();
    });
});

casper.test.begin('Tester.assertField(): XPath selectors', 1, function(test) {
    casper.start('tests/site/form.html', function() {
        this.fill('form[action="result.html"]', {
            'email': 'albert@camus.com'
        });

        test.assertField({
            type: 'xpath',
            path: '/html/body/form[1]/input[1]'
        },
             'albert@camus.com',
             'Tester.assertField() works as expected with XPath selectors'
        );
    }).run(function() {
        test.done();
    });
});

casper.test.begin('Tester.assertField(): invalid selectors', 1, function(test) {
    casper.start('tests/site/form.html', function() {
        this.fill('form[action="result.html"]', {
            'email': 'albert@camus.com'
        });

        test.assertRaise(function() {
            test.assertField({
                type: 'albert'
            },
                 'albert@camus.com',
                 'Tester.assertField() works as expected with XPath selectors'
            );
        }, [], 'should throw an error for an invalid selector');
    }).run(function() {
        test.done();
    });
});

casper.test.begin('Tester.assertFieldCSS(): CSS selectors', 1, function(test) {
    casper.start('tests/site/form.html', function() {
        this.fill('form[action="result.html"]', {
            'email': 'albert@camus.com'
        });

        test.assertFieldCSS(
            '#email',
            'albert@camus.com',
            'Tester.assertFieldCSS() works as expected with CSS selectors'
        );
    }).run(function() {
        test.done();
    });
});

casper.test.begin('Tester.assertFieldXPath(): XPath selectors', 1, function(test) {
    casper.start('tests/site/form.html', function() {
        this.fill('form[action="result.html"]', {
            'email': 'albert@camus.com'
        });

        test.assertFieldXPath(
             '/html/body/form[1]/input[1]',
             'albert@camus.com',
             'Tester.assertFieldXPath() works as expected with XPath selectors'
        );
    }).run(function() {
        test.done();
    });
});

redpajama_set_name: RedPajamaGithub


Offshore Aviation is a Veteran Owned Small Business focused on conducting aviation and maritime related research and development, training, and services. The company operates the UAS training center for land and maritime based UAS training and provides supports special programs in the government. Offshore three Business units: Offshore Aviation which specializes in UAS training, OffshoreUAS which specializes in Unmanned Aircraft Development and aerial survey, and OffshorePIX which specializes in marketing and film applications across the United States. Offshore Aviation was founded in 2011.


BTW hope you all are super excited to know that all your favorite international premium brands are now available on Skingene! Yay!
Moving on, let's face it, we live in an era which moves at a lightening speed & it is hard to keep up at times, resulting in us stressing out all the time. This ultimately affects how we look & feel, especially our skin. Seriously it needs a break, like right now!
Start by detoxing! The little annoying particles which popularly go by the name of Free Radicals are the main culprits behind aging of our skin. So why put up with them? Zap Zap they need to go!
Heap your skin with antioxidants like Vitamin E & B-Carotene to tackle the free radicals. Obviously the next question would be which products will do the job. Please be careful in selecting products for your skin as you do not want to damage it. Always go for quality products & never ever compromise on that!
This awesome product helps neutralize free radicals & provides potent antioxidant protection against aging & deeply moisturizes skin leaving it supple & healthier. A definite must have!
As we leave you with these, we hope you can incorporate them into your daily beauty regimen & detoxify regularly! Let us know if you need more information on any of these products & we will be happy to help!
Have you tried any of these to detoxify your skin? We would love to hear from you.. just leave your comments below!


text:
Home / Ava Huston Ladner / F1: Max Verstappen Fumes, Lewis Hamilton Wins the Brazilian Grand Prix
Max Verstappen Leads the Way (Photo: FIA Media)
F1: Max Verstappen Fumes, Lewis Hamilton Wins the Brazilian Grand Prix
Ava Huston Ladner November 11, 2018 Ava Huston Ladner, Featured Content, Formula 1 News, Formula 1 Recap, Formula One 1 Comment
Sometimes fortune rolls a certain way. Then sometimes fortune comes in the form of Esteban Ocon spinning out race leader Max Verstappen. Lewis Hamilton found himself in the enviable position of being in second when Ocon and Verstappen collided, turned it into a five-second lead, and held on from there at Interlagos in Brazil. Verstappen steered his Red Bull across the line in second with the Ferrari of Kimi Räikkönen taking the final step on the podium.
With the combination of Hamilton's win and Valtteri Bottas' fifth-place finish, Mercedes earned their fifth consecutive Constructors Championship. This string of titles follows Red Bull's four straight championships but has not yet matched Ferrari's excellence, when they won six in a row from 1999-2004.
The Brazilian Grand Prix started just as Mercedes and Hamilton would have desired. Hamilton used his pole position spot to precision and sped away from the pack while his teammate Bottas, starting third, managed to slip past the Ferrari of Sebastian Vettel to hold down second. Things looked just about perfect.
Though Hamilton was able to earn the win, the Mercedes never showed that they were the dominant car. In fact, it was the Red Bull duo that looked to be the best on the track. Verstappen was able to claim second and teammate Daniel Ricciardo, after suffering a five-spot grid penalty for exceeding season-long engine limits, drove from tenth up to fourth and nearly pulled off third.
On lap 44 (of 71), Force India's Ocon was driving with fresh tires and sought to put himself back on the lead lap. He raced wheel-to-wheel with leader Verstappen. Right after the start-finish line, Ocon made his move on Verstappen in the Senna S. Neither left either room and banged into each other. The collision sent both cars spinning and off the track. Hamilton sped past and into the lead.
Some may conjecture that Ocon, driving a Mercedes-powered car, may have interfered so as to directly help Hamilton. While conspiracy theories are all the rage anymore, such a consideration should be thrown into the rubbish bin with haste.
The question of whether Ocon should be faulted is more worthwhile. A driver certainly has the right to race in an effort to maintain their position on the lead lap, but Ocon may have been pushing it a little too hard. The reality of the situation is that he was never going to be able to keep Verstappen in his rear views and that conceding the position would have been intelligent. But racers race, and this moment was an opportunity for Ocon to make a measure of himself.
For Verstappen, even he should endure some criticism as he could have waited until after the Senna S and re-passed Ocon with ease. Hamilton was roughly two seconds behind, so there was no real threat should Verstappen had exercised a bit of patience. The stewards agreed with Verstappen's assessment that Ocon was an idiot, however, and dropped a 10-second penalty on him.
The action didn't end once the checkered flag flew. After the race, Verstappen confronted Ocon.
There was contact on the track, and a bit off it too 😡 #BrazilGP 🇧🇷 #F1 pic.twitter.com/OajZ1UM4lL
— Formula 1 (@F1) November 11, 2018
As a result of this incident, both drivers were called to the stewards. No word as to potential penalties from the confrontation.
– For all of Ferrari's early season success, they failed to follow it or keep up as the year continued. After the summer break, they have been lackluster at best — and that is with acknowledging that they had one of the best cars on the grid.
The team could never manage to make handling, speed, and race management come together in a way that Mercedes had done, and even Red Bull had been doing. That Ferrari were still in contention for the Constructors title is a testament to the car they built but they have proven to be just a tick behind. Of course, Vettel's long, slow, brain fade should also be factored into the matter, and one of the things that the team must do during the offseason is to get his mind right for 2019.
– Charles Leclerc earned a seventh-place finish in an unremarkable Sauber car. There is little doubt that his season has been all over the place, but this finish is a highlight and should offer a bit of optimism as Leclerc prepares to move to Ferrari next season.
– One team that should be feeling good after the Brazilian GP is Haas F1. After their drivers finished 15th and 16th at the Mexican Grand Prix, the prior race, the organization was quizzical. While even the mighty Mercedes struggled at Autodromo Hermanos Rodriguez when Haas struggles they fall to the rear and don't pull off top five finishes. The efforts at the BGP, with Romain Grosjean and Kevin Magnussen earning eighth and ninth, respectively, this race served as a good rebound effort — the question will be whether or not it is a harbinger for a team set to move up the grid or an indication of their assigned spot in the field.
Drive to Forget
Marcus Ericsson would be happy if footage of his BGP were all erased from history. His day began with parts falling off his Sauber before the race had even begun. On the opening laps, more pieces removed themselves – end plates and the like – and things didn't get any better. That Ericsson started sixth (SIXTH!) and then dropped through the field as though he couldn't find a gear above second showed things were not going to be tenable. After he spun out, he and the team had seen enough and retired the car.
Brazilian Grand Prix Results (Nov. 11, 2018):
1 L. Hamilton – Mercedes·#44 1:27:09.066 25
2 M. Verstappen – Red Bull·#33 +1.469s 18
3 K. Räikkönen – Ferrari·#7 +4.764s 15
4 D. Ricciardo – Red Bull·#3 +5.193s 12
5 V. Bottas – Mercedes·#77 +22.943s 10
6 S. Vettel – Ferrari·#5 +26.997s 8
7 C. Leclerc – Sauber·#16 +44.199s 6
8 R. Grosjean – Haas·#8 +51.230s 4
9 K. Magnussen – Haas·#20 +52.857s 2
10 S. Pérez – Racing Point·#11 +1 Lap 1
11 B. Hartley – Toro Rosso·#28 +1 Lap 0
12 C. Sainz Jr. –Renault·#55 +1 Lap 0
13 P. Gasly – Toro Rosso·#10 +1 Lap 0
14 S. Vandoorne – McLaren·#2 +1 Lap 0
15 E. Ocon – Racing Point·#31 +1 Lap 0
16 S. Sirotkin – Williams·#35 +2 Laps 0
17 F. Alonso – McLaren·#14 +2 Laps 0
18 L. Stroll – Williams·#18 +2 Laps 0
19 N. Hülkenberg – Renault·#27 DNF 0
20 M. Ericsson – Sauber·#9 DNF 0
Tags Esteban Ocon Lewis Hamilton Marcus Ericsson Max Verstappen
About Ava Huston Ladner
As an editor, Ava works through some of the site's biggest columns while writing one of her own on F1 each week. "Stranded" on the islands of Oahu in Hawaii, the aspiring college professor also helps anchor other coverage while coordinating Pace Laps, our multi-series news update.
@turtlewords
Previous XFINITY Breakdown: Christopher Bell Comes from Back to Win Phoenix, Clinches Spot at Homestead
Next Kyle Busch Survives Wild Can-Am 500 to Punch His Ticket to Homestead; Championship Four Set
DoninAjax
If Ocon passed Max wouldn't he then be given the blue flags because he was a lap down?


text:
Metal Gear Solid 2: Sons Of Liberty
Posted on August 4, 2006 by Avi Tronek
Updated August 5, 2006
Game Review By: DannyV_El_Acme
Author: Hideo Kojima and Kojima Productions
Platform: Other
Publisher: Konami
Price: I've seen it as low as $15
Degree of Cyberpunk Visuals: Very High
Correlation to Cyberpunk Themes: Very High
Rating: 9 out of 10
Introduction: With Metal Gear Solid, Hideo Kojima made a name for himself as one of the most gifted and ambitious video game designers today, so when the sequel to the game was announced, and moreover on the(then) brand-new PlayStation 2, fans were overjoyed. However, instead of a sequel which only included more of the same, Kojima used the power of the new system and DVD medium to create a game that defies characterization. Metal Gear Solid 2: Sons Of Liberty is one of the most ambitious, complicated, even puzzling games ever made. But even with all its differences from the original, it is still very much a Metal Gear game, so that guarantees an incredible storyline and intense, stealth-oriented action.
The story : Two years after the events of Shadow Moses, Solid Snake and Otacon are back on the field on a new mission. Snake and Otacon are now part of a UN-backed covert organization codenamed Philanthropy, whose purpose is the eradication of any and all Metal Gears around the world. Since Shadow Moses, plans for creating a Metal Gear have surfaced on the black market, leading to a multitude of clandestine organizations creating their own version of the dreaded war mech. At the start of the game, Snake and Otacon are particularly targeting a new amphibious model, Metal Gear Ray, developed by the U.S. Marines. However, things get ugly when the tanker carrying the new machine is hijacked by Russian military forces. During the course of the hijacking, Revolver Ocelot betrays his Russian comrades and, controlled by the spirit of thought-dead Liquid Snake, steals the Metal Gear prototype and sinks the tanker, causing an oil spill with Snake in it. Snake is presumed dead.
Two years later, on a routine visit to a plant created to control the oil spill, the President of the United States is kidnapped by a group calling themselves the Sons Of Liberty, led by a rogue black-ops group nicknamed Dead Cell. SEALs are sent to rescue the President, but the group is wiped out. As a last resort, the U.S. sends agent Raiden, a newly graduated member of Foxhound, to infiltrate the facility and rescue the President. However, as can be expected, this is no ordinary terrorist attack, and the facility houses secrets which point to a secret conspiracy only known as The Patriots. What do the terrorists want, and what does Raiden's past have to do with the whole thing?
The game: While Metal Gear Solid's story and themes are pretty straightforward and well established, MGS2 goes on a much more abstract direction. The dialog and situations in this game are much more bizarre and even postmodern than those in the previous game, and paranoia is rampant. This is the most cyberpunk of all the chapters in the series, this time the story focusing on meme theory, artificial intelligence, information control, conspiracy theories, and political and military maneuvering. But above all, the topic of the dehumanizing effect of technology and the influence of genetics in human behavior really make this a fascinating game to analyze with others. Like with The Matrix trilogy, a straightforward first chapter leads to a much more complicated second one which may divide fans and confuse newcomers. However, it is this complexity which makes this probably the most important game in the series yet. The game has a sense of urgency and even fatalism that moves one to try to solve the problems contained therein, but it also constantly dangles a thread of hope to grab on to. This is probably Kojima's most personal game, and it shows.
Like the previous game, the action itself is stealth-based, but this time Snake and Raiden are MUCH better prepared and capable of dealing with the game's dangers. The jump to a new system has resulted in a much more complicated game, but also one you have more tools for taking it on with. Enemies don't instantly sound the alarm when they see you anymore, instead they have to radio in before an alarm is called. This gives you an extra second to dispose of the enemy before they alert their comrades. However, once an enemy is incapacitated, his friends start looking for him when he doesn't report in, so you might want to hide the body somewhere. You can also knock enemies out or put them to sleep instead of killing them, which would cause less of a fuss than a body would(enemies even humorously kick friends awake when they're dozing). Your characters are much more athletic, too, able to flip out of gunfire's way, and hang from ledges to hide from foes.
The cast in this game is just as great as the previous game. Snake's a little lighter in attitude and able to crack a joke, having made some new and faithful friends in the previous game, and Otacon's friendship with Snake has deepened his resolve and made him a little more sure of himself. The new characters are great, too, although some people might be put off by Raiden, the new protagonist of the series. And if Psycho Mantis was freaky, Vamp is off-the-hook SCARY.
The jump from 32-bit to 128 did wonders for the game's graphics. This game came out in 2001 and it STILL looks amazing. The amount of details in this game is incredible, and character models look gorgeous. The game is also much more cinematic, with expert direction during cinemas that makes the game even more of a blockbuster than the first. The music is also on a whole different level, composed by Harry Gregson-Williams, of The Rock, Armageddon and Enemy Of The State fame.
Availability: The game is just as available as MGS1, with many different versions. The recommended version is MGS2: Substance, the special edition of the game with lots of extra goodies. However, GET THE PS2 VERSION. The XBox version is a glitchy mess of slowdown.
The verdict : MGS2 is a worthy followup to the amazing game that was MGS, and stands on its own both as an entertaining game and a fascinating document of electronic literature. I sadly have to dock it a point because it isn't the easiest game to follow(probably the same reason that made SFAM give Matrix Reloaded 9 stars instead of 10), but that's just being fair to the first one. And it's still a spectacular game. 9 out of 10 stars: get it, play it, be thoroughly puzzled yet amazed.
This post has been filed under Cyberpunk Games, Awesome Cyberpunk Themes, Awesome Cyberpunk Visuals by DannyV_El_Acme.
Cholo »