Free Science and Video Lectures Online!: New Richard Feynman Video Lectures and Talks, thanks to Peteris Krumins

New Richard Feynman Video Lectures and Talks

Hey everyone, this month I've more Richard Feynman video lectures and talks. The talks include: Feynman on Computers, Feynman on Nanotechnology, Feynman on Los Alamos, Lawrence Krauss on Richard Feynman's Life in Science, and Feynman's Dirac Memorial Lecture.


Richard Feynman on Computers

• Richard Feynman Computers Lecture

Lecture description:
Richard Feynman, Winner of the 1965 Nobel Prize in Physics, gives us an insightful lecture about computer heuristics: How computers work, how they file information, how they handle data, how they use their information in allocated processing in a finite amount of time to solve problems and how they actually compute values of interest to human beings. These topics are essential in the study of what processes reduce the amount of work done in solving a particular problem in computers, giving them speeds of solving problems that can outmatch humans in certain fields but which have not yet reached the complexity of human driven intelligence. The question if human thought is a series of fixed processes that could be, in principle, imitated by a computer is a major theme of this lecture and, in Feynman's trademark style of teaching, gives us clear and yet very powerful answers for this field which has gone on to consume so much of our lives today. No doubt this lecture will be of crucial interest to anyone who has ever wondered about the process of human or machine thinking and if a synthesis between the two can be made without violating logic.


Richard Feynman's Nanotechnology Lecture

• Richard Feynman Quantum Machines Lecture

Lecture description:
Richard Feynman gave his famous talk "There's Plenty of Room at the Bottom" on December 29th 1959 at the annual meeting of the American Physical Society at the California Institute of Technology (Caltech) as his vision on how physics and engineering could move in the direction that could eventually create nanotechnology. Really good ideas and strokes of genius are often manifest in the right questions being asked: How small can information be encoded? How can information be written? How can information it be read? All of these important "Hows" were asked by Feynman in a time when computers had to be put in large rooms and when the impending space race was forcing engineers to do some serious strategic thinking in making technology small enough to be lifted by rockets into space to function as serious tools in scientific exploration and defence. Feynman himself may not have invented the technology we see in the development and continuity of the computer age, but the fact that even in the early 1960's nanotechnology was being considered as a serious field of study was definitely a factor contributing to the boom in computer technology seen in the late 20th century and continues to reach more spectacular levels of sophistication in the 21st century. In this lecture, Feynman tries to retell his 1959 lecture from a more modern perspective in that many aspects of his vision have been full filled, particularly with the invention of the electron microscope, the atomic force microscope and experimental manipulation of the atomic scale of matter. Also discussed is the current practical field of photolithography for the manufacture of bipolar transistors and junctions used in computer chips done on an industrial scale and how this process continues with ever decreasing wavelength capabilities of lasers from UV to X-rays. Feynman also discusses the boundaries of miniaturisation and how the scale differences affect the function of certain aspects of technology as well as in nature.


Richard Feynman's Los Alamos from Below Lecture

• Richard Feynman Los Alamos Lecture

Lecture description:
This is the Physicist Richard Feynman recalling his activities at Los Alamos during the World War II. This track is from an accompanying CD to the book "Classic Feynman: All the Adventures of a Curious Character" by Ralph Leighton, published by W. W. Norton.


Quantum Man: Richard Feynman's Life in Science

• Lawrence Krauss on Richard Feynman

Lecture description:
Perhaps the greatest physicist of the second half of the twentieth century, Richard Feynman changed the way we think about quantum mechanics, the most perplexing of all physical theories. Here Lawrence M. Krauss, himself a theoretical physicist and best-selling author, offers a unique scientific biography: a rollicking narrative coupled with clear and novel expositions of science at the limits. An immensely colorful persona in and out of the office, Feynman revolutionized our understanding of nature amid a turbulent life. Krauss presents that life—from the death of Feynman’s childhood sweetheart during the Manhattan Project to his reluctant rise as a scientific icon—as seen through the science, providing a new understanding of the legacy of a man who has fascinated millions. An accessible reflection on the issues that drive physics today, Quantum Man captures the story of a man who was willing to break all the rules to tame a theory that broke all the rules.


Elementary Particles and the Laws of Physics (1986 Dirac memorial lecture)

• Feynman's Dirac Memorial Video Lecture

Lecture description:
Developing a theory that seamlessly combines relativity and quantum mechanics, the most important conceptual breakthroughs in twentieth century physics, has proved to be a difficult and ongoing challenge. This book details how two distinguished physicists and Nobel laureates have explored this theme in two lectures given in Cambridge, England, in 1986 to commemorate the famous British physicist Paul Dirac. Given for nonspecialists and undergraduates, the talks transcribed in Elementary Particles and the Laws of Physics focus on the fundamental problems of physics and the present state of our knowledge. Professor Feynman examines the nature of antiparticles, and in particular the relationship between quantum spin and statistics.

Related Posts

• Free Physics Video and Audio Courses
  (Includes descriptive physics, classical mechanics, introductory physics, electricity and magnetism, vibrations and waves, symmetry and tensors)


• More Physics Video Courses
  (Includes physics for non-science majors, mechanical universe lecture series, elementary college physics, and astrophysics)


• Even More Physics Videos
  (Includes videos for general public on string theory, universe and particle smashers, then more advanced videos on string theory, particle physics, cosmology and physics demonstrations)


• Free Physics Video Lectures
  (Includes quantum mechanics, quantum physics, classical physics, classical mechanics, chaos, fractals and dynamical systems, linear dynamical systems, heat and mass transfer and general relativity.)


• Even More Physics Videos and Video Lectures
  (Lots of Richard P. Feynman lectures, compexity and chaos, universe in a nutshell, black holes, life in space, states of matter, chemistry of interstellar space, electricity and magnetism, nanophysics and many others)


• Modern Physics
  (Includes Quantum Physics, Quantum Mechanics, Quantum Field Theory, Applied Group Theory, General Relativity, Cosmology, Astrophysics, Computational Physics, Thermodynamics and a lecture on Basic Physics)


• More Modern Physics
  (Includes Special Relativity, General Relativity, Quantum Mechanics, Cosmology, Einstein's Theory, Quantum Entanglements, LHC, Dirac Strings, and Explorations of 4th Dimension. Graduate Classical Mechanics and Lee Smolin)


• Endlessly More Physics
  (Includes CERN summer school videos (particle physics and LHC). Videos from Kavli Institute for Theoretical Physics. Physics Talks from Perimeter Institute for Theoretical Physics. Lectures on String Theory, Black Holes, Fundamental Laws of Nature, Dark Matter, Moon, and search for new Suns. Lecture on Fluid dynamics. Astrophysics Workshop. Videos from Institute of Advanced Study. And some bonus lectures on geometry of manifolds, on evolutionary dynamics, and solving cubic equations)


• String Theory, Quantum Computation and Others
  (Includes 3 hour video series of The Elegant Universe - the theory about unifying all four fundamental forces and the string theory, various lectures from princeton university on black holes and others, historical perspectives of Hans Bethe and quantum computation by David Deutsch)


• Popular Science Physics Video Lectures
  (Includes Richard Feynman's Messenger Video Lectures, an interview with Richard Feynman, video of young Albert Einstein, explanation of Schrodinger's cat, ferrofluid, a trip inside LHC, video on quantum computing, upcoming revolutions in theoretical physics, video interview about multiverse and parallel universes, 100 greatest physics discoveries, and discovery of fullorene.)


• Various Physics Lectures
  (Includes Escher and Droste effect, Sir Roger Penrose and new physics, Feynman, Nikola Tesla, gyroscopes, black holes, dark matter, dark energy, modern cosmology, origins of universe, theoretical physics, particle hydrodynamics, numeric relativity, plasma, astrophysics, superstring theory, LHC, gravity, OLED technology, lasers)

Source: http://goo.gl/mag/5qUE0x
Shared via Google Currents

Sent from my iPad

I found this... punny

I found this humerus… | ilovefunnypics.com

'via Blog this'

Dissecting the elevator pitch, thanks to Nick Corcodilos

Dissecting the elevator pitch

Filed under: Getting in the door, Job Search, Q&A, Readers' Forum

In the November 27, 2012 Ask The Headhunter Newsletter, a writer asks for a job at Ask The Headhunter:

Hi Nick,

[1] I’m going to cut to the chase: I want to write for “Ask The Headhunter”! [2] My name is Melanie and I’m a former educator turned researcher/blogger. [3] I stumbled upon your blog researching for another article weeks ago. [4] My expertise/niche is education so most of my articles deal with learning — whether they’re directed at instructors, students, parents, or business leaders. [5] But of course my edu-centric pieces are always tailored to each blog’s audience. Check out some of my clips to see more of what I mean:

[6] [six URLs to her articles]

[7] Hope to discuss ideas soon,

Melanie

My Rant

Resumes make me cringe. Elevator pitches make me cringe more. Elevator pitches delivered in e-mail make me wanna barf. Nothing is more banal, misdirected, or useless to someone that doesn’t know you.

Consider how often an elevator pitch, or a cover letter, or a job inquiry reads like the note above. Maybe you’ve written one yourself.

I want to tell you what’s wrong with these pitches. Then I want to know what you think — because most people seem to believe they must “craft” a chunk of b.s. like this to get an employer’s attention.

I’ve tagged each part of the pitch I received with a number. This is gonna get ugly, but let’s tear it apart. (I offer no apologies to Melanie. She offered none to me. But I thank her for helping me write this edition of the newsletter.)

[1] Melanie isn’t cutting to the chase.

The chase is my need to produce profit for my business. What Melanie wants to do (“to write for Ask The Headhunter”) is relevant only if it fits in with my business objectives. What does she know about them?

Oops. If Melanie had spent five minutes on the ATH website, she’d know that — except for one small section, which she never mentions — all the articles are written by me.

And that’s the first problem with elevator pitches: They are by design generic and thus presumptuous. You can’t create an elevator pitch for someone you don’t know and haven’t met yet. If you think I’m full of baloney, try this elevator pitch on the next person you meet that you’re attracted to:

“My ability to make [men, women] happy by exciting them results in fun relationships and could lead to marriage.”

Trust me. When you’re on the receiving end, that’s what an elevator pitch — about anything — sounds like.

[2] I don’t care what Melanie’s former career was.

When you have just a moment or two to engage someone in a business discussion, why would your speech be “crafted” about yourself? The answer is easy: You don’t know anything about the business of the person you’re talking to — the pitch is designed to be memorized and regurgitated in elevators to any captive.

Want my attention? Tell me you know what my business is about and how you can make it better. Tell me about yourself later, after I behave as if I want to know.

[3] Melanie “stumbled” upon my blog.

The analog in our social lives is this phone call:

“Hi. I had nothing to do tonight so I thought I’d call you.”

Gimme a break.

[4] Four sentences into it, Melanie is still talking about herself.

It’s pretty clear she has no idea what Ask The Headhunter is about. She worked in education, so she will write educational articles. About whatever.

Elevator pitches are painful to create because they must account for the orator’s ignorance yet pretend to be insightful. Save yourself the trouble. If you need to break the ice with someone you don’t know, don’t talk about yourself or express what you think. Instead, ask them a question. People love it when we express interest in them. They are turned off when we recite stuff about ourselves.

[5] Melanie suggests she’s qualified.

What is Melanie qualified to do  for me? She hasn’t indicated she has any idea what I need. She’ll write anything for any audience, never mind who the audience is. And that’s the fatal flaw with any elevator pitch. By design it demonstrates one thing above all else: The speaker knows so little about the listener that she promises anything and everything.

Here’s the insult: After the recitation, an elevator pitcher wants me to go figure out what to do with her and her ideas. No thanks. I’d rather she do that work.

[6 & 7] This part of the pitch is the punch line.

Usually, an elevator pitch ends with the orator handing over a resume or suggesting the listener invest a couple of hours in breakfast or lunch to listen to more. After delivering this elevator pitch about herself, Melanie wants me to spend the next hour reading six of her articles.

She’s showing me examples of her work — and she’s telling me to go figure out whether her work is relevant to my business. I didn’t approach her — she approached me. So the burden is on the elevator pitcher to make her case. Suggesting I go figure it out is not making a case.

Consider what an elevator pitch is really about: You and your assumptions.

If you want to do business with someone, why would you open the conversation by talking about yourself and about what’s important to you? If you want to do business with me, spend the precious minute you have with me proving you know about my business and what I need. Prove you thought enough about my business in advance to offer something useful to me.

Ouch — you’d have to invest an awful lot of time and effort in me first, eh? Why would you? Why, indeed? And why should I devote two seconds to listening to you recite?

Do you have an elevator pitch? What is it? What reactions do you get when you recite it? What’s your reaction to elevator pitches? Am I just a rude S.O.B. who needs to be more tolerant and pretend to listen to anyone who wants my time? I want to know what you think.

: :

    

More (Q&A, &c) at:
Ask The Headhunter® | Nick Corcodilos – Dissecting the elevator pitch

'via Blog this'

Holidays? Best time to find a job - courtesy of Ask Annie

Ask Annie

2

 comments

Why the holidays are the best time to find a new job

By Anne Fisher, contributor November 21, 2012: 5:00 AM ET

•  
• EmailPrint

Contrary to a persistent myth, many companies do hire in December. Here are six ways to get on their radar.

FORTUNE -- Dear Annie: Can you settle a bet? A friend of mine who has been out of work for quite a while is planning to take the month of December off from job hunting because he says hiring managers are taking time off, or are distracted by their own holiday preparations, and are not hiring until after January 1. Based on my own experience as a manager, I think he's mistaken and will miss out on some great opportunities if he stops looking during the holidays. I suspect that part of his reluctance to go to big holiday parties -- which are terrific for networking -- is that he's embarrassed about being unemployed. He has agreed to keep looking if you say he should, so what do you think? —Concerned Friend

Dear C.F.: Your friend is mistaken, but he's certainly not the only one. "This 'bad time of year' myth has become conventional wisdom among job seekers," notes Harry Urschel, head of Minneapolis recruiting firm e-Executives, who adds that it isn't at all unusual for people to find new jobs even in that quiet week between Christmas and New Year's.

Other headhunters agree: A new survey of recruiters by online executive career network ExecuNet says that 69% report place as many, or even more, candidates in December as in any other month.

MORE: Why college grads are heading back...to community college

Calling off a job search during the next few weeks is counterproductive for several reasons. First, Urschel says, "there is a great deal of pressure on managers to be prepared" for the New Year, which means having people in place before it starts. Moreover, many employers have "use it or lose it" budgets that bosses have to spend before December 31, or they need to staff up before the year ends for tax purposes, so January may be too late.

"December is the easiest job market of the whole year -- followed by January, which is the toughest and most competitive," says Susan Joyce, who runs career site Job-Hunt.org. To help out during the holidays, Joyce and branding expert Meg Giuseppi compiled an e-book of tips from 25 recruiters and career coaches, called New Year, New Job! 101 Top Tips from the Job-Hunt Experts for Your Holiday Job Search. It will be available for free on all Amazon Kindle apps from midnight on Thanksgiving Day until midnight next Monday (99 cents thereafter).

A few of those tips your friend might useful:

1. Build your online network over the holidays. Reconnecting with old friends and acquaintances is natural at this time of year, so reach out to them on LinkedIn (LNKD) and Facebook (FB), and get caught up with what they're doing these days. Touch base with any recruiters you may know, as well.

2. Volunteer. Many nonprofits need extra help during the holidays, and lending a hand can lead to new relationships that will help your job search. Just as important, notes career coach Nan S. Russell, "It feels great to make a difference. It ignites your self-esteem and reminds you of what's going right in your life."

3. Send cards to companies where you've interviewed. To remind hiring managers that you're still interested in working with them, executive coach Camille Roberts suggests sending a holiday card, and maybe even a small gift like a little box of chocolates, along with a note. "Ask if there are any openings where you might be a better fit" than the job you previously applied for, she says.

4. Thank everyone who has helped you in your job search so far. Holiday cards are a great way to express appreciation to networking contacts, recruiters, and anyone else you've been in touch with about your job hunt -- and to stay on their radar screens for opportunities they may know about right now.

5. Go to holiday parties. Professional-association get-togethers are particularly helpful. "I know hiring managers who go to holiday parties looking for people to hire," says e-Executives' Urschel. Once you get there, adds Jeff Lipschultz, president of Southlake, Texas, recruiting firm A-List Solutions, "make it your goal to meet all the people there. Any one of them could be a hiring manager or a recruiter."

6. Throw your own party. "Invite friends for dinner, cookies, coffee, or a glass of holiday cheer at your home or in a restaurant, bakery, or bar," suggests Barbara Safani, Job-Hunt.org's finance industry job search expert. "This is a great, low-key way to practice your pitch and reconnect with people who may be able to help you with your search."

Speaking of parties, New Year, New Job! includes a chapter about handling the party chitchat that tends to make unemployed people uncomfortable. "Prepare what I call 'Teflon' answers to questions you dread," says Phyllis Mufson, a career coach at Job-Hunt.org who specializes in helping Baby Boomers find new jobs. An example of a Teflon answer: If someone says, "It's so awful that you got laid off. How are you?" you can reply, "My old job was great, but I'm excited to find new ways to use my skills. Thanks for your concern." Then steer the conversation to less awkward ground.

MORE: Globalism goes backward

"Don't hide, and don't apologize," adds Job-Hunt.org's Joyce. "You've done nothing wrong, and anyway, unemployment is a temporary state. It's not who you are."

Talkback: Have you ever found a job during the holiday season, or hired someone at year-end? Leave a comment below.

Posted in: careers, Employment, holiday job search, Job hunting, job search, Networking

Why the holidays are the best time to find a new job - Ask Annie - Fortune Management

'via Blog this'

Cadence Partner Udacity Brings Higher Education to the World, thanks to Richard Goering and Cadence

This sounds like free education in functional verification, FYI:

Cadence Partner Udacity Brings Higher Education to the World

By Richard Goering on November 26, 2012Comments(0)Filed under: Industry Insights, Functional Verification, UVM, Cadence, coverage, e language, debugging, Stanford, hardware verification, David Evans, on-line classes, verification engineers, artificial intelligence, Udacity, Scherer, university, Sebastian Thune, on-line instructionOn-line education pioneer Udacity is partnering with Cadence to offer an upcoming free class in functional hardware verification - but Udacity's overall mission is quite a bit broader than that. Says David Evans, vice president of education at Udacity (right): "Our mission is to make high-quality higher education available to everyone in the world, and to keep it free."
It's an ambitious goal for the young company, which started last year when two artificial intelligence experts - Prof. Sebastian Thune, now Udacity CEO, and Peter Norvig, now Google's director of research - decided to go on-line with a class they were teaching at Stanford University. It went viral, was picked up by the New York Times, and within a few weeks 160,000 students in over 190 countries had signed up for Udacity's first class, "Introduction to Artificial Intelligence."
Today Udacity offers the following classes:

• Beginner courses in computer science, physics, and statistics
• Intermediate courses in algorithms, web development, software testing, programming languages, theoretical computer science, differential equations, software debugging, and "how to build a startup"
• Advanced courses in design of computer programs, artificial intelligence, and applied cryptography

Functional hardware verification will be offered in early 2013 as an advanced course. Other upcoming courses include HTML5 game development, interactive rendering, and introduction to parallel programming.
Interactive Experience
While the classes are as challenging as traditional university classes, they take advantage of new technology. "Instead of having a traditional lecture style, where the professor is talking at the students, we have a much more interactive, engaging style with exercises, videos, and short explanations," Evans said. Students generally can't interact with instructors in real time, as they could in a physical classroom, but Udacity provides discussion forums at which students can get answers from other students or instructors.
Udacity classrooms are "open" 24 hours a day and students can progress at whatever pace they like. Classes are available to anyone with Internet access. Accreditation is "something we're working on," Evans said.
Evans, who is currently on leave from  his post as a professor of computer science at the University of Virginia, noted that only a very small fraction of the world's population can afford to take four years to attend brick-and-mortar universities. "Traditional universities are organized around the same ideas and processes as they were 1,000 years ago," he said. "Our belief is that by using technology we can make the cost per student really low while delivering a high-quality learning experience."
So how does Udacity make money? The business model is still under development, but one possibility is through add-on services such as certified testing. Recruiting fees represent another revenue source. Here, Udacity would identify students who could be valuable to potential employers, and the employers would pay recruiting fees to find them.
Functional Verification Class
So why teach hardware IC verification? This is not, after all, a topic that's likely to draw 160,000 students in a few weeks. But as I heard at the DVCon conference earlier this year, many chip design companies are struggling to find qualified verification engineers, a job function that requires a combination of hardware and software skills that many university graduates lack.
"We're really excited about the hardware verification class and the partnership with Cadence to make it available to many more people," Evans said. "Certainly it's in an area we think is important. In terms of useful, employable skills, it will provide a tremendous amount of value." The Cadence partnership was announced October 18 along with Udacity partnerships with Google, nVidia, Microsoft, and Autodesk.
The verification class is titled Functional Hardware Verification: How to Verify Chips and Eliminate Bugs. It will be taught by Cadence verification experts Axel Scherer and Hannes Froehlich in early 2013. (Scherer is a frequent Cadence blogger, and you can read his post and see a short video about the Udacity class here.) The training will be based on the e Hardware Verification Language, but does not require a knowledge of e up front.
Scherer said that Cadence is offering the class in response to global demands for verification training, and the difficulty in reaching many parts of the world with in-person training. The class can serve design engineers moving into verification, part-time verification engineers who only use directed test, college students, engineers who want to broaden their skill sets, and unemployed engineers looking to get back into the labor market. Students should be familiar with programming in general and have some understanding of object-oriented programming.
Course content will include basic verification environments, adaptable verification environments, verification concepts, functional coverage, data checking and scoreboards, the Universal Verification Methodology, debugging, and environment control and synchronization. The class will leverage automated techniques such as constrained-random test generation.
For more information, see the Udacity web site and the functional hardware verification class description.
Richard Goering

Cadence Partner Udacity Brings Higher Education to the World - Industry Insights - Cadence Community

'via Blog this'

DejaGnu, gcc, and runtest: Running Tests

DejaGnu: The GNU Testing Framework
Prev		Next

---

4. Running Tests

There are two ways to execute a testsuite. The most common way is when there is existing support in the Makefile. This support consists of a check target. The other way is to execute the runtest program directly. To run runtest directly from the command line requires either all the correct options, or the Local Config File must be setup correctly.

4.1. Make check

To run tests from an existing collection, first use configure as usual to set up the build directory. Then try typing:

make check
      

If the check target exists, it usually saves you some trouble. For instance, it can set up any auxiliary programs or other files needed by the tests. The most common file the check builds is the site.exp. The site.exp file contains various variables that DejaGnu used to determine the configuration of the program being tested. This is mostly for supporting remote testing.
The check target is supported by GNU Automake. To have DejaGnu support added to your generated Makefile.in, just add the keyword dejagnu to the AUTOMAKE_OPTIONS variable in yourMakefile.am file.
Once you have run make check to build any auxiliary files, you can invoke the test driver runtest directly to repeat the tests. You will also have to execute runtest directly for test collections with no check target in the Makefile.

4.2. Runtest

runtest is the executable test driver for DejaGnu. You can specify two kinds of things on the runtest command line: command line options, and Tcl variables for the test scripts. The options are listed alphabetically below.
runtest returns an exit code of 1 if any test has an unexpected result; otherwise (if all tests pass or fail as expected) it returns 0 as the exit code.

4.2.1. Output States

runtest flags the outcome of each test as one of these cases. A POSIX Conforming Test Framework for a discussion of how POSIX specifies the meanings of these cases.

PASS

The most desirable outcome: the test succeeded, and was expected to succeed.

XPASS

A pleasant kind of failure: a test was expected to fail, but succeeded. This may indicate progress; inspect the test case to determine whether you should amend it to stop expecting failure.

FAIL

A test failed, although it was expected to succeed. This may indicate regress; inspect the test case and the failing software to locate the bug.

XFAIL

A test failed, but it was expected to fail. This result indicates no change in a known bug. If a test fails because the operating system where the test runs lacks some facility required by the test, the outcome isUNSUPPORTED instead.

UNRESOLVED

Output from a test requires manual inspection; the testsuite could not automatically determine the outcome. For example, your tests can report this outcome is when a test does not complete as expected.

UNTESTED

A test case is not yet complete, and in particular cannot yet produce a PASS or FAIL. You can also use this outcome in dummy ``tests'' that note explicitly the absence of a real test case for a particular property.

UNSUPPORTED

A test depends on a conditionally available feature that does not exist (in the configured testing environment). For example, you can use this outcome to report on a test case that does not work on a particular target because its operating system support does not include a required subroutine.

runtest may also display the following messages:

ERROR

Indicates a major problem (detected by the test case itself) in running the test. This is usually an unrecoverable error, such as a missing file or loss of communication to the target. (POSIX testsuites should not emit this message; use UNSUPPORTED, UNTESTED, or UNRESOLVED instead, as appropriate.)

WARNING

Indicates a possible problem in running the test. Usually warnings correspond to recoverable errors, or display an important message about the following tests.

NOTE

An informational message about the test case.

4.2.2. Invoking Runtest

This is the full set of command line options that runtest recognizes. Arguments may be abbreviated to the shortest unique string.

--all (-a)

Display all test output. By default, runtest shows only the output of tests that produce unexpected results; that is, tests with status FAIL (unexpected failure), XPASS (unexpected success), or ERROR (a severe error in the test case itself). Specify --all to see output for tests with status PASS (success, as expected) XFAIL (failure, as expected), or WARNING (minor error in the test case itself).

--build [string]

string is a full configuration ``triple'' name as used by configure. This is the type of machine DejaGnu and the tools to be tested are built on. For a normal cross this is the same as the host, but for a canadian cross, they are separate.

--host [string]

string is a full configuration ``triple'' name as used by configure. Use this option to override the default string recorded by your configuration's choice of host. This choice does not change how anything is actually configured unless --build is also specified; it affects only DejaGnu procedures that compare the host string with particular values. The procedures ishost, istarget, isnative, and setupxfail} are affected by --host. In this usage, host refers to the machine that the tests are to be run on, which may not be the same as the build machine. If --build is also specified, then --host refers to the machine that the tests wil, be run on, not the machine DejaGnu is run on.

--host_board [name]

The host board to use.

--target [string]

Use this option to override the default setting (running native tests). string is a full configuration ``triple'' name of the form cpu-vendor-os as used by configure. This option changes the configuration runtestuses for the default tool names, and other setup information.

--debug (-de)

Turns on the expect internal debugging output. Debugging output is displayed as part of the runtest output, and logged to a file called dbg.log. The extra debugging output does not appear on standard output, unless the verbose level is greater than 2 (for instance, to see debug output immediately, specify --debug-v -v}). The debugging output shows all attempts at matching the test output of the tool with the scripted patterns describing expected output. The output generated with --strace also goes into dbg.log.

--help (-he)

Prints out a short summary of the runtest options, then exits (even if you also specify other options).

--ignore [name(s)]

The names of specific tests to ignore.

--objdir [path]

Use path as the top directory containing any auxiliary compiled test code. This defaults to .. Use this option to locate pre-compiled test code. You can normally prepare any auxiliary files needed with make.

--outdir [path]

Write output logs in directory path. The default is .}, the directory where you start runtest. This option affects only the summary and the detailed log files tool.sum and tool.log. The DejaGnu debug logdbg.log always appears (when requested) in the local directory.

--reboot [name]

Reboot the target board when runtest initializes. Usually, when running tests on a separate target board, it is safer to reboot the target to be certain of its state. However, when developing test scripts, rebooting takes a lot of time.

--srcdir [path]

Use path as the top directory for test scripts to run. runtest looks in this directory for any subdirectory whose name begins with the toolname (specified with --tool). For instance, with --toolgdb},runtest uses tests in subdirectories gdb.* (with the usual shell-like filename expansion). If you do not use --srcdir, runtest looks for test directories under the current working directory.

--strace [number]

Turn on internal tracing for expect, to n levels deep. By adjusting the level, you can control the extent to which your output expands multi-level Tcl statements. This allows you to ignore some levels of case orif statements. Each procedure call or control structure counts as one ``level''. The output is recorded in the same file, dbg.log, used for output from --debug.

--connect [program]

Connect to a target testing environment as specified by type, if the target is not the computer running runtest. For example, use --connect to change the program used to connect to a ``bare board'' boot monitor. The choices for type in the DejaGnu 1.4 distribution are rlogin, telnet, rsh, tip, kermit, and mondfe. The default for this option depends on the configuration most convenient communication method available, but often other alternatives work as well; you may find it useful to try alternative connect methods if you suspect a communication problem with your testing target.

--baud [number]

Set the default baud rate to something other than 9600. (Some serial interface programs, like tip, use a separate initialization file instead of this value.)

--target_board [name(s)]

The list of target boards to run tests on.

--tool[name(s)]

Specifies which testsuite to run, and what initialization module to use. --tool is used only for these two purposes. It is not used to name the executable program to test. Executable tool names (and paths) are recorded in site.exp and you can override them by specifying Tcl variables on the command line. For example, including "--tool gcc" on the runtest command line runs tests from all test subdirectories whose names match gcc.*, and uses one of the initialization modules named config/*-gcc.exp. To specify the name of the compiler (perhaps as an alternative path to what runtest would use by default), use GCC=binname on the runtest command line.

--tool_exec [name]

The path to the tool executable to test.

--tool_opts [options]

A list of additional options to pass to the tool.

--verbose (-v)

Turns on more output. Repeating this option increases the amount of output displayed. Level one (-v) is simply test output. Level two (-v-v}) shows messages on options, configuration, and process control. Verbose messages appear in the detailed (*.log) log file, but not in the summary (*.sum) log file.

--version (-V)

Prints out the version numbers of DejaGnu, expect and Tcl, and exits without running any tests.

--D[0-1]

Start the internal Tcl debugger. The Tcl debugger supports breakpoints, single stepping, and other common debugging activities. See the document "Debugger for Tcl Applications" by Don Libes. (Distributed in PostScript form with expect as the file expect/tcl-debug.ps.. If you specify -D1, the expect shell stops at a breakpoint as soon as DejaGnu invokes it. If you specify -D0, DejaGnu starts as usual, but you can enter the debugger by sending an interrupt (e.g. by typing C-c).

testfile.exp[=arg(s)]

Specify the names of testsuites to run. By default, runtest runs all tests for the tool, but you can restrict it to particular testsuites by giving the names of the .exp expect scripts that control them. testsuite.exp may not include path information; use plain filenames.

testfile.exp="testfile1 ..."

Specify a subset of tests in a suite to run. For compiler or assembler tests, which often use a single .exp script covering many different source files, this option allows you to further restrict the tests by listing particular source files to compile. Some tools even support wildcards here. The wildcards supported depend upon the tool, but typically they are ?, *, and [chars].

tclvar=value

You can define Tcl variables for use by your test scripts in the same style used with make for environment variables. For example, runtest GDB=gdb.old defines a variable called GDB; when your scripts refer to $GDB in this run, they use the value gdb.old. The default Tcl variables used for most tools are defined in the main DejaGnu Makefile; their values are captured in the site.exp file.

4.2.3. Common Options

Typically, you don't need must to use any command-line options. --tool used is only required when there are more than one testsuite in the same directory. The default options are in the local site.exp file, created by "make site.exp".
For example, if the directory gdb/testsuite contains a collection of DejaGnu tests for GDB, you can run them like this:

eg$ cd gdb/testsuite
   eg$ runtest --tool gdb
 

Test output follows, ending with:

=== gdb Summary ===

  # of expected passes 508
  # of expected failures 103
  /usr/latest/bin/gdb version 4.14.4 -nx
 

You can use the option --srcdir to point to some other directory containing a collection of tests:

eg$ runtest--srcdir /devo/gdb/testsuite
 

By default, runtest prints only the names of the tests it runs, output from any tests that have unexpected results, and a summary showing how many tests passed and how many failed. To display output from all tests (whether or not they behave as expected), use the --all option. For more verbose output about processes being run, communication, and so on, use --verbose. To see even more output, use multiple --verboseoptions. for a more detailed explanation of each runtest option.
Test output goes into two files in your current directory: summary output in tool.sum, and detailed output in  tool.log. (tool refers to the collection of tests; for example, after a run with --tool gdb, look for output files gdb.sum and gdb.log.)

4.3. The files DejaGnu produces.

DejaGnu always writes two kinds of output files: summary logs and detailed logs. The contents of both of these are determined by your tests.
For troubleshooting, a third kind of output file is useful: use --debug to request an output file showing details of what Expect is doing internally.

4.3.1. Summary File

DejaGnu always produces a summary output file tool.sum. This summary shows the names of all test files run; for each test file, one line of output from each pass command (showing status PASS or XPASS) orfail command (status FAIL or XFAIL); trailing summary statistics that count passing and failing tests (expected and unexpected); and the full pathname and version number of the tool tested. (All possible outcomes, and all errors, are always reflected in the summary output file, regardless of whether or not you specify --all.)
If any of your tests use the procedures unresolved, unsupported, or runtested, the summary output also tabulates the corresponding outcomes.
For example, after runtest --tool binutils, look for a summary log in binutils.sum. Normally, DejaGnu writes this file in your current working directory; use the --outdir option to select a different directory.

Example 19. Here is a short sample summary log

Test Run By rob on Mon May 25 21:40:57 PDT 1992
   === gdb tests ===
 Running ./gdb.t00/echo.exp ...
 PASS:   Echo test
 Running ./gdb.all/help.exp ...
 PASS:   help add-symbol-file
 PASS:   help aliases
 PASS:   help breakpoint "bre" abbreviation
 FAIL:   help run "r" abbreviation
 Running ./gdb.t10/crossload.exp ...
 PASS:   m68k-elf (elf-big) explicit format; loaded
 XFAIL:  mips-ecoff (ecoff-bigmips) "ptype v_signed_char" signed C types
                === gdb Summary ===
 # of expected passes 5
 # of expected failures 1
 # of unexpected failures 1
 /usr/latest/bin/gdb version 4.6.5 -q
      

4.3.2. Log File

DejaGnu also saves a detailed log file tool.log, showing any output generated by tests as well as the summary output. For example, after runtest --tool binutils, look for a detailed log in binutils.log. Normally, DejaGnu writes this file in your current working directory; use the --outdir option to select a different directory.

Example 20. Here is a brief example showing a detailed log for G++ tests

Test Run By rob on Mon May 25 21:40:43 PDT 1992

                === g++ tests ===

 --- Running ./g++.other/t01-1.exp ---
        PASS:   operate delete

 --- Running ./g++.other/t01-2.exp ---
        FAIL:   i960 bug EOF
 p0000646.C: In function `int  warn_return_1 ()':
 p0000646.C:109: warning: control reaches end of non-void function
 p0000646.C: In function `int  warn_return_arg (int)':
 p0000646.C:117: warning: control reaches end of non-void function
 p0000646.C: In function `int  warn_return_sum (int, int)':
 p0000646.C:125: warning: control reaches end of non-void function
 p0000646.C: In function `struct foo warn_return_foo ()':
 p0000646.C:132: warning: control reaches end of non-void function

 --- Running ./g++.other/t01-4.exp ---
        FAIL:   abort
 900403_04.C:8: zero width for bit-field `foo'
 --- Running ./g++.other/t01-3.exp ---
        FAIL:   segment violation
 900519_12.C:9: parse error before `;'
 900519_12.C:12: Segmentation violation
 /usr/latest/bin/gcc: Internal compiler error: program cc1plus got fatal signal

                === g++ Summary ===

 # of expected passes 1
 # of expected failures 3
 /usr/latest/bin/g++ version cygnus-2.0.1
 

4.3.3. Debug Log File

With the --debug option, you can request a log file showing the output from Expect itself, running in debugging mode. This file (dbg.log, in the directory where you start runtest) shows each pattern Expectconsiders in analyzing test output.
This file reflects each send command, showing the string sent as input to the tool under test; and each Expect command, showing each pattern it compares with the tool output.

Example 21. The log messages begin with a message of the form

expect: does {tool output} (spawn_id n)
  match pattern {expected pattern}?

        

For every unsuccessful match, Expect issues a no after this message; if other patterns are specified for the same Expect command, they are reflected also, but without the first part of the message (expect... match pattern).
When Expect finds a match, the log for the successful match ends with yes, followed by a record of the Expect variables set to describe a successful match.

Example 22. Here is an excerpt from the debugging log for a GDB test:

send: sent {break gdbme.c:34\n} to spawn id 6
 expect: does {} (spawn_id 6) match pattern {Breakpoint.*at.* file
 gdbme.c, line 34.*\(gdb\) $}? no
 {.*\(gdb\) $}? no
 expect: does {} (spawn_id 0) match pattern {return} ? no
 {\(y or n\) }? no
 {buffer_full}? no
 {virtual}? no
 {memory}? no
 {exhausted}? no
 {Undefined}? no
 {command}? no
 break gdbme.c:34
 Breakpoint 8 at 0x23d8: file gdbme.c, line 34.
 (gdb) expect: does {break gdbme.c:34\r\nBreakpoint 8 at 0x23d8:
 file gdbme.c, line 34.\r\n(gdb) } (spawn_id 6) match pattern
 {Breakpoint.*at.* file gdbme.c, line 34.*\(gdb\) $}? yes
 expect: set expect_out(0,start) {18}
 expect: set expect_out(0,end) {71}
 expect: set expect_out(0,string) {Breakpoint 8 at 0x23d8: file
 gdbme.c, line 34.\r\n(gdb) }
 epect: set expect_out(spawn_id) {6}
 expect: set expect_out(buffer) {break gdbme.c:34\r\nBreakpoint 8
 at 0x23d8: file gdbme.c, line 34.\r\n(gdb) }
        PASS:   70      0       breakpoint line number in file
 

This example exhibits three properties of Expect and DejaGnu that might be surprising at first glance:

• Empty output for the first attempted match. The first set of attempted matches shown ran against the output {} --- that is, no output. Expect begins attempting to match the patterns supplied immediately; often, the first pass is against incomplete output (or completely before all output, as in this case).
• Interspersed tool output. The beginning of the log entry for the second attempted match may be hard to spot: this is because the prompt {(gdb) } appears on the same line, just before the expect: that marks the beginning of the log entry.
• Fail-safe patterns. Many of the patterns tested are fail-safe patterns provided by GDB testing utilities, to reduce possible indeterminacy. It is useful to anticipate potential variations caused by extreme system conditions (GDB might issue the message virtual memory exhausted in rare circumstances), or by changes in the tested program (Undefined command is the likeliest outcome if the name of a tested command changes).
  The pattern {return} is a particularly interesting fail-safe to notice; it checks for an unexpected RET prompt. This may happen, for example, if the tested tool can filter output through a pager.
  These fail-safe patterns (like the debugging log itself) are primarily useful while developing test scripts. Use the error procedure to make the actions for fail-safe patterns produce messages starting withERROR on standard output, and in the detailed log file.
  
  
  

Running Tests:

'via Blog this'