Matthew Broderick in "War Games" Shall we play a game?: The rise of the military-entertainment complex The Army wants you to play video games: For decades, the military has been financing, inventing and perfecting them

The origins of the U.S. military’s involvement with video games lie in its century-old status as this country’s primary sponsor of new technologies. A quick checklist of the technologies that either stem from or were significantly refined in defense-funded contexts shows how pervasive the military’s influence has been: digital computers, nuclear power, high-speed integrated circuits, the first version of the Internet, semiconductors, radar, sonar, jet engines, portable phones, transistors, microwave ovens, GPS—the list goes on. As Ed Halter writes in his book "From Sun Tzu to Xbox," “The technologies that shape our culture have always been pushed forward by war.”

Take the creation of the key technological innovation of the past several decades: the digital computer. Specifically, the combination of military-sponsored technological advancements and military-related strategic and tactical needs during World War II led directly to the computer’s invention. While private industry may eventually have developed what we now think of as the digital computer, the huge amount of research funding provided by the military, coupled with a desperate need to win the war, pushed this development up by years, if not decades. The military remained the key influence on the advancement of digital computers well into the 1960s.

Advertisement:

Early in the twentieth century, the rising prominence of artillery made the calculation of ballistics a tactical necessity. Up to and throughout World War I, ballistics data had primarily been tabulated by hand, even as the growing number and variety of modern weapons called for ever more complex calculations, which became the province of skilled mathematicians known as “computers.” By World War II, however, advances in air and weapons systems required quicker means of calculation. To meet this requirement, the military sponsored the creation of the Electronic Numerical Integrator and Computer (ENIAC), popularly regarded as the world’s first digital computer. Though ENIAC wasn’t completed until the fall of 1945, after the war had drawn to a close, the military connection remained strong: ENIAC’s first task was to provide calculations used to plan the detonation of the hydrogen bomb.

Military-sponsored technological innovation continued apace for the next two decades, as the Department of Defense and its sub-agencies underwrote the great majority of computer and electronics research and development. In the years after the war’s end, the DoD founded a number of grant-giving agencies that continue to underwrite new technology today. Among these agencies were the highly influential Advanced Research Projects Agency (ARPA), now known as the Defense Advanced Research Projects Agency (DARPA); the Army Office of Scientific Research, now the Army Research Laboratory; and the Office of Naval Research. Throughout the 1950s and ’60s, the military remained what historian Paul Edwards notes was “the proving ground for initial concepts and prototype machines.”

Paralleling the rise of these DoD-operated institutions was an increasingly large defense contracting sector, ranging from companies whose sole focus was military contracting to larger, more diverse corporations, such as IBM, Raytheon, and General Electric, whose success was built on a combination of military subsidies and commercial sales. Beginning in the 1960s, the private electronics sector also experienced unprecedented growth, compelling it to begin pouring money into its own research and development. Despite this sector’s self-financed efforts, however, military funding continued to be the primary force spurring the creation of new technologies.

Advertisement:

There were several reasons for the military’s intense interest in and financing of computers, but none was as important as the huge information-processing needs of what had become an immense bureaucracy. With the advent of the Cold War, American supremacy was thought to hinge on the maintenance of a robust military, whose efficient functioning required number-crunching on a vast scale. Computers greatly accelerated this process, further sparking the growth and increasing complexity of military bureaucracy.

Beyond the military’s bureaucratic needs, the drive for computerization reflected a broader ideological shift. In the late 1940s and ’50s, computers were enlisted as tools for the newly popular practice of tackling society’s biggest problems with seemingly objective statistical and mathematical tools. In fact, computers were for many years developed specifically to meet this function. Even as the private computer industry continued to expand during the early 1960s, the military, and the defense industry as a whole, remained the prime buyer and sponsor of computer-related technology.

The other major beneficiary of computer-oriented military funding during this period was academia; the Pentagon and ARPA underwrote research in the field at such prestigious institutions as Harvard, Johns Hopkins, Stanford, and UCLA. Perhaps most notably, the Massachusetts Institute of Technology, along with its groundbreaking artificial intelligence program, received the majority of its computer-related research money from the military. In their superb analysis of the video game industry, Digital Play, Stephen Kline, Nick Dyer-Witheford, and Greig de Peuter draw on this exchange to note that the “military-industrial-academic complex provided the triangular base from which the information age would be launched.”

Advertisement:

Spacewar! and Beyond

The roots of the military’s historical involvement with video games extend beyond its sponsorship of computers. For several decades — from the 1960s to the early 1990s — the armed forces took the lead in financing, sponsoring, and inventing the specific technology used in video games. Without the largesse of such military agencies as DARPA, the technological foundation on which the commercial game industry rests would not exist. Advanced computing systems, computer graphics, the Internet, multiplayer networked systems, the 3-D navigation of virtual environments—all these were funded by the Department of Defense.

Advertisement:

Virtual military training dates back to the late 1920s, when Edwin Link, the son of an organ and automatic piano maker, developed the first flight simulator, which was made of wood and powered by organ bellows. Video games, however, derive from preparations for nuclear war and space exploration; arguably the first digital game, a faux-military simulation, was in fact called Spacewar! The game was invented in 1962 by twenty-three-year-old Steve Russell and his cohorts in the fictitious Hingham Institute Study Group on Space Warfare, a collection of like-minded, Pentagon-funded engineering graduate students at MIT. Russell and his friends were as fascinated by science fiction as they were by their basement lab’s latest acquisition: a Programmed Data Processor-1, or PDP-1, one of the first microcomputers, which Russell describes as “the size of about three refrigerators,” with “an old-fashioned computer console” and “a whole bunch of switches and lights.”

The PDP-1’s manufacturer had shipped the computer to MIT in the hope that the electrical engineering department could put it toward some new and intriguing use, though building the world’s first video game could hardly have been what the manufacturer had in mind. For a time the PDP-1 just sat idle in the corner of the engineering lab. Russell was “itching to get his fingers” on the new machine, however, so he and his friends began discussing what they could do with this new mini computer. According to Russell, “Space was very hot at the time — it was just when satellites were getting up and we were talking about putting a man on the moon. So we said, gee, space is fun, and most people don’t appreciate how to maneuver things in space. So I wrote a demo program that had two spaceships that were controlled by the switches on the computer.”

Russell’s main influence in programming Spacewar! was Edward “Doc” Smith’s science-fiction “space opera” Lensman, which appeared serially in magazines before being reworked into highly successful books. Russell and his MIT coworkers were big fans of Lensman. “The details were very good and it had an excellent pace,” Russell says. “[Smith’s] heroes had a strong tendency to get pursued by the villain across the galaxy and have to invent their way out of their problem while they were being pursued. That sort of action was the thing that suggested Spacewar! He had some very glowing descriptions of spaceship encounters and space fleet maneuvers.” “Glowing” is certainly an accurate description, as is evident in this sample from one of the Lensman books:

Advertisement:

Beams, rods, and lances of energy flamed and flared; planes and pencils cut, slashed, and stabbed; defensive screens glowed redly or flashed suddenly into intensely brilliant, coruscating incandescence. Crimson opacity struggled sullenly against violet curtains of annihilation. Material projectiles and torpedoes were launched under full-beam control; only to be exploded in mid-space, to be blasted into nothingness or to disappear innocuously against impenetrable polycyclic screens.

Russell felt that by “picking a world which people weren’t familiar with” — that is, space — “we could alter a number of parameters of the world in the interests of making a good game and of making it possible to get it onto a computer.” In the game, two players used switches and knobs to maneuver spaceships through the gravity field of a star while firing missiles at each other. The fuel and the missiles were limited, as they would be in real life; adding to the pressure, players also had to avoid colliding with the star as they fired their weapons. Players could launch their ships into hyperspace at the last minute to avoid incoming missiles, but the ships would reenter the game at random locations, with each reentry increasing the chances that the craft would explode. Graphics-wise, Spacewar! was quite primitive: the spaceships were little more than green blips on the murky blue-black background of the oscilloscope screen. Irritated by the inaccuracy of the game’s initial star field, one of Russell’s coworkers eventually rewrote the script based on real star charts.

Spacewar!’s originality derived from the interface of the PDP-1, which came equipped with a keyboard and a circular monitor. As Kline, Dyer-Witheford, and de Peuter write, the game’s “radical innovation” was that it featured “interface controls for navigation and made the screen a graphic input to the player.” These twin features of navigation and display are, the authors note, “the foundation of digital interactive entertainment — the crucial ‘core design’ subsequent hardware and software designers would work up and sophisticate through generations of games.” Russell himself had wondered whether there might be a way to commercialize the game in order to make a profit from it. After a week’s contemplation, however, he decided that no one would be willing to pay money for it. Instead, he and his friends just gave the source code to anyone who asked for it.

Spacewar! was an immediate hit among the growing network of computer programmers occupying university research institutes nationwide. Within a year, the game had grown so popular that Stanford University’s Computer Studies Department had to initiate a “no Spacewar! during business hours” policy. By the mid-1960s, a copy of the game was on virtually every research computer in the country, whether in academia, industry, or the military.

Advertisement:

Russell and his MIT associates were enthusiastic members of the emerging subset of computer virtuosos known as “hackers”—those who experimented with the programming capabilities of computers for the sheer fun of it. Young, male, and white, both nerdy and counterculture-cool, these hackers were subsidized by the burgeoning military-industrial complex, with their research going to fight the Cold War. The shock of the Soviets’ 1957 Sputnik launch had led to vastly increased funding for science and technology, most of it channeled through the Pentagon’s Advanced Research Projects Agency. Nuclear mobilization, ballistics, missilery, space defense — these were the concerns of the Pentagon and of policymakers alike. Hackers such as Russell and his friends occupied a precarious position in this new environment. They took their money and much of their guidance from the military, and yet their ethos was one of freedom and playful exploration, and they were harshly disillusioned by Vietnam and, later on, by Watergate.

It would be unfair to say that the hackers’ playful spirit was at odds with their military mandate, however. In fact, experimentation and whimsy were encouraged in places like the MIT computer engineering lab as a way of expanding the heretofore limited applications of computers. Until the early 1960s, computers were envisioned solely as sophisticated calculators and machines for modeling. Russell and other young hackers introduced the radical notion that computers could be tools not only for calculations but also for entertainment. Spacewar! wasn’t exciting because of its technology; it was exciting because it introduced a whole new way of thinking about computers — namely, that they could be sources of pleasure. Within a few years, this emphasis on enjoyment became the heart of the growing video game industry. So even though, as Ed Halter writes, video games “were not created directly for military purposes,” they nonetheless “arose out of an intellectual environment whose existence was entirely predicated on defense research.”

The military’s specific interest in computer-based war gaming can be traced to the late 1970s, when the Army War College introduced the board game Mech War into its staff officer training curriculum. Much more common during this period, however, was the development of high-end computer simulations, not games, for military training. In the 1980s, collaborators from the military, the entertainment industry, and academia began building “distributed interactive simulations” (DIS) — simulations that use distributed software or hardware to create virtual theaters of war, in which participants could interact in real time. These simulations employed the latest advances in computer graphics and virtual-reality technology, which added to the immersive qualities of their synthetic environments. As DIS technology continued to evolve into the next decade, an increasing focus on content and on compelling narratives brought these simulations closer in basic form to commercial video games.

The military’s interest in the kinds of video games popular today dates to 1980, when Atari released its groundbreaking Battlezone. Not only did Battlezone evoke a three-dimensional world, as opposed to the two-dimensional worlds of such previous arcade hits as Asteroids and Tempest, but players viewed the action from a first-person perspective, as if they themselves were tank gunners peering through their periscopes at the battlefield outside — in this case, a spare moonscape with mountains and an erupting volcano in the distance. This first-person element made Battlezone a direct ancestor of today’s enormously popular first-person shooters.

Advertisement:

Soon after Battlezone took off, the army’s Training and Doctrine Command (TRADOC) requested Atari’s help in building a modified version of the game that could be used as a training device for the then-new Bradley infantry fighting vehicle. General Donn Starry, the head of TRADOC at the time, had recognized early on that soldiers would be more responsive to electronic training methods than to print-and lecture-based ones. “[Today’s soldiers have] learned to learn in a different world,” Starry told a TRADOC commanders’ conference in 1981, “a world of television, electronic toys and games, computers, and a host of other electronic devices. They belong to a TV and technology generation . . . [so] how is it that our soldiers are still sitting in classrooms, still listening to lectures, still depending on books and other paper reading materials, when possibly new and better methods have been available for many years?” Yet while Army Battlezone (also known as Bradley Trainer) was eventually produced, the game was never used to train any actual soldiers.

The military’s digital efforts took a major step forward with DARPA’s construction of SIMNET, a real-time distributed networking project for combat simulation. Until the 1980s, simulators had been built as stand-alone systems that focused on such specific tasks as piloting a tank and landing a jet on an aircraft carrier. Each of these systems cost tens of millions of dollars — often twice the amount of the real systems for which the soldiers were training. To rectify this expensive and unwieldy practice, in 1982 DARPA drafted the help of air force captain Jack A. Thorpe, who years earlier had floated the idea that simulators did not need to physically replicate the full vehicles they were representing but could simply be used to enhance the training for these vehicles. Take aircraft: there was no need to use simulators to teach an air force pilot everything he needed to know about flying; simulators could train him only in things that he couldn’t learn from flying during peacetime. Why not, Thorpe asked, determine first which training functions were needed and then base the simulator hardware on that?

Thorpe’s experience with simulators began in 1976, when he worked as a research scientist in flight training at Williams Air Force Base in Arizona. Tasked with improving the state of flight simulators, which at the time were three-story mechanical contraptions in which pilots were shaken around like leaves, he looked for a way to change these single-pilot machines into ones that could teach group skills. “Group interactions are the most complicated combat operations,” he says. “They also tend to be the ones in which the costs of screwing up are the highest. Yet because it is so difficult and expensive to organize groups, pilots get very little training in collective skills. They have to learn these skills on the job, during combat, which makes casualties disproportionately high during the first few missions.”

To rectify the situation, Thorpe conceived of a network — anything from dozens to hundreds of individual simulators all interacting with each other. He thought it was wasteful for simulator training devices to focus on individual service members; the network he envisioned would allow for a collective training experience centered on entire crews and units.

Advertisement:

By the time of Thorpe’s DARPA appointment in the early 1980s, the environment seemed ripe for him finally to put his networking concept into practice. ARPANET—the forerunner of the Internet— had exploded onto the military scene and was generating a great deal of positive interest in the science of networking. Aware that building the kind of system he envisioned would be economically infeasible, Thorpe looked to affordable, non-DoD technology such as computer and video games to make his vision a reality. He hired military contractor Bolt, Beranek and Newman to develop the networking and system software necessary to bring SIMNET—that is, simulator networking—to life. The originality of Thorpe’s vision later prompted Wired magazine to declare, “William Gibson didn’t invent cyberspace, Air Force Captain Jack Thorpe did.”

By January 1990, the first SIMNET units were finally ready to go. The army stepped in first, buying several hundred units for its Close Combat Tactical Trainer system. SIMNET’s training value became apparent one year later, during the first Gulf War. In the war’s most significant engagement, known as the Battle of 73 Easting, the U.S. 2nd Armored Cavalry Regiment destroyed dozens of Iraqi fighting vehicles in just under two hours, while killing or wounding more than six hundred Iraqi soldiers. Because the 2nd Armored Cavalry had prepared for the war by training extensively on SIMNET, the military decided to use the Battle of 73 Easting as a model for future networked training. The goal was to provide a much more rounded experience of battle than simulation had previously allowed for, one that emphasized the stresses and fears, the emotional experience of war, as much as it did the tactical ones. To this end, the SIMNET team assembled reams of data on 73 Easting: extensive interviews with 150 participants, radio and tape recordings from the battle, overhead photographs of the skirmishing, action logs, even a step-by-step re-creation on the actual battlefield by soldiers from the 2nd Cavalry. The results of this effort pointed the way toward the future of military training: interactive, immersive, complex, and variable scenarios in which the total experience of war could be brought forth in its digital replication. Because simulation was given much of the credit for the military’s Gulf War success, the postwar period saw DARPA’s SIMNET-related research and development efforts expand significantly.

The next major step in the military’s video game history came with the 1993 release of the blockbuster first-person shooter fantasy Doom. According to Timothy Lenoir and Henry Lowood, historians of science, Doom is solely responsible for changing practically every facet of PC-based gaming, including “graphics and networking technology, . . . styles of play, notions of authorship, and public scrutiny of game content.” (One of the game’s innovations was a new mode of play called “death match,” which, like Doom’s other innovations, is now a standard feature of many first-person shooter games.) Doom was an immediate sensation among gamers, with sales soon climbing into the millions.

Around the same time that Doom was released, the Marine Corps Modeling and Simulation Office (MCMSO) received a mandate from the annual General Officers Symposium to begin looking for commercial video games that might prove useful for training. Because the Marine Corps budget is a great deal smaller than that of the other services, the corps has a long history of seeking cost-effective training solutions. General Charles Krulak, its commandant at the time, believed that PC-based war games held great potential for teaching Marines critical decision-making skills.

Advertisement:

Lieutenants Scott Barnett and Dan Snyder of MCMSO immediately began combing through dozens of military-related video games to see if any might be useful for training. They developed the online Personal Computer Based Wargames Catalog, on which they posted detailed reviews of the numerous games they investigated. Barnett and Snyder were looking for a fast-action first-person shooter — one that, crucially, allowed user modification. Of the many games they examined, only Doom (or rather its sequel, Doom II) fit the bill. As part of its marketing strategy, Doom’s developer, id Software, had released parts of the game as shareware and encouraged players to enact their own modifications.

Throughout the spring and summer of 1995, Snyder transformed the game from an outer-space gothic fantasy into a military fire-team simulation. The Martian terrain and alien demons of the original Doom were replaced by a dun-colored landscape of pockmarked concrete bunkers and enemies who had been drawn from scans of GI Joe action figures. The cost of production? A mere $49.95—the price of one copy of Doom II.

The point of the modified game, known as Marine Doom, was to teach Marines not how to fire their weapons but how to work together in teams and make split-second decisions in the midst of combat. “A real firefight is not a good time to explore new ideas,” Snyder explains. The game had another, equally significant, rationale. “Kids who join the Marines today grew up with TV, videogames, and computers,” Barnett reasons. “So we thought, how can we educate them, how can we engage them and make them want to learn?” Barnett and Snyder’s calculations were correct: their creation became a huge hit among Marines, though, like Army Battlezone, it was never actually used for training. According to Barnett, Marines would plead to be allowed into his base’s gaming lab even after it closed at night.

Marine Doom was created at a time when the Pentagon had begun embracing simulation for a broad range of activities. As scholar Sharon Ghamari-Tabrizi relates, these activities included “part-task training; mission rehearsal; operational planning; strategic and tactical analyses; weapons systems modeling during research and development, testing and evaluation, and acquisitions; and long-range future studies.” Much of this emphasis on simulation was the result of post– Cold War military downsizing. With the collapse of the Soviet Union, the military’s budget had been reduced to a level commensurate with what Congress assumed was a greatly reduced geopolitical threat. The relative affordability of simulation technologies matched well with the military’s newly tightened budget.

The Federal Acquisition Streamlining Act of 1994 also forced the military to change its procurement policies. No longer could it underwrite defense contractors’ R&D and acquisitions on an unlimited basis; instead, the Pentagon had to rely on what are known as “commercial off-the-shelf” (COTS) technologies—technologies that already exist and that have been developed by commercial industry. Take SIMNET: put together by military contractors, it required $140 million, ten years, and several hundred employees to build, even though it did use some commercial technologies. By contrast, Marine Doom, which relied exclusively on commercial technologies, was built by eight people in six months for $25,000. Military contractors now had to take on the stripped-down and flexible management practices of corporations—in effect, to become commercial businesses themselves. This had a deep and immediate impact on the defense sector, resulting in the merger or closure of a number of prominent companies.

In order to maintain their livelihoods, defense contractors had to find other customers to whom they could peddle their high-tech gadgets. Yet even in this time of seeming crisis, the contractors ended up coming out ahead, as it quickly became apparent that another industry was hungry for their wares: the entertainment industry. The relationship born of this outcome was symbiotic: defense contractors would spin their technologies off into the commercial game industry, and the commercial game industry would spin its technologies right back. In an update of Eisenhower’s classic formulation, cyberpunk writer Bruce Sterling termed this win-win relationship the “military-entertainment complex”—the relentless exchange of technologies, personnel, and money that defines the bond between the military and the video game industry.

The military’s reduced budgets in the 1990s also led to a greater dependence on reservist troops, which only increased the use of distributed interactive simulation systems for training. These systems enabled reservists to participate in large-scale training exercises and maneuvers no matter where they were based. As a further cost-cutting method, the immediate post–Cold War period saw the military’s emphasis shift to all-encompassing joint operations, as opposed to individual service missions. Two new declarations of military doctrine— Joint Vision 2010 (1996) and Joint Vision 2020 (2000)—codified this focus. In the effort to develop new simulation platforms that would meet the requirement for a jointly linked system, the four services of the armed forces were directed to overcome their traditional rivalries. The ultimate result of this attempt at cooperation was the Joint Simulation System (JSIMS), a single, integrated virtual battlefield — in technical terms, a mission rehearsal and command simulation environment — in which participants from all four services could operate regardless of location.

There was one more reason for the military’s turn to simulation: modern high-tech warfare was increasingly fought through electronic and digital interfaces resembling video games. Early on, this rapid growth in the electronic mediation of warfare caused confusion even among military professionals. An oft-repeated anecdote involves the war game Operation Internal Look, undertaken by the U.S. military in July 1990, during the run-up to the first Gulf War. General Norman Schwarzkopf relates the tale in his memoirs: “As [Internal Look] got under way, the movements of Iraq’s real-world ground and air forces eerily paralleled the imaginary scenario of the game . . . As the war game began, the message center also passed along routine intelligence bulletins about the real Middle East. Those concerning Iraq were so similar to the game dispatches that the message center ended up having to stamp the fictional reports with a prominent disclaimer: ‘Exercise Only.’”

Linking Entertainment and Defense

In the 1990s, no less an entertainment icon than Mickey Mouse presided over the tightening of the military–video game industry bond. At a mid-1990s meeting of the Army Science Board, that service’s senior scientific advisory body, four-star general Paul Kern met Bran Ferren, an entertainment industry futurist with a friendly, expansive manner and a wild red beard. Ferren was the influential head of creative technology at Walt Disney Imagineering, the design and development arm of the Walt Disney Company based in Glendale, California. (Since its founding in 1952, Walt Disney Imagineering has developed dozens of innovations in the areas of special effects, interactive entertainment, fiber optics, robotics, and film techniques.)

General Kern’s first thought upon meeting Ferren, with his tan explorer’s jacket and his untamed facial hair, was, “What’s this crazy liberal doing here in the middle of our organization?” As soon as he heard Ferren speak, however, Kern found him to be an inspiring, intellectually challenging figure who crystallized many of the nascent doubts Kern had been harboring about the static state of military simulation. Listening to Ferren describe the cutting-edge virtual-reality development efforts he was leading at Walt Disney Imagineering, Kern came to the abrupt realization that the entertainment industry had leaped far ahead of the military in regard to high technology—and, equally important, in the cost of that technology.

Ferren pointed out to the assembled army officials that when he and his entertainment industry associates looked at the military’s modeling and simulation offerings, the offerings were, frankly, “unaffordable and pretty crappy.” The software was “lousy” and the hardware was “clunky and inflexible.” Ferren posed a series of questions to prod the army officials’ thinking. “How much texture memory can we have in the graphics process unit?” he asked as an example. He received a number of blank stares. “Texture memory?” someone responded. “What’s that?”

Kern’s education was in mechanical engineering, and over the previous two decades he had gained a great deal of experience with computing and simulation, including the SIMNET program. He found Ferren such a font of valuable information and advice that he began meeting with him regularly, sometimes at Disney Imagineering headquarters, other times in his own office in the Pentagon. Their conversations were technical and wide-ranging, but Ferren took pains to drive home to Kern a simple message: “You gotta be where the action is.” If the military wanted to be part of the emerging technology base in Hollywood, which was linked to Silicon Valley, then it had to establish a presence there.

Kern was so impressed by his meetings with Ferren that he charged his subordinates with making the military more Disney-like. The military had been at the forefront of technological development for decades, he told them. Why couldn’t it now develop its capabilities to match those of the entertainment industry?

As it turns out, he wasn’t the only one asking that question. In 1996, professor Michael Zyda of the Naval Postgraduate School in Monterey, California, had chaired a National Research Council study titled “Modeling and Simulation: Linking Entertainment and Defense.” As tightly connected as the military and the game industry had always been, Zyda’s report argued that the two entities nonetheless had a great deal more to offer each other. When General Kern sent his subordinates scrambling to find someone who could better meld the entertainment industry’s technological know-how with the military’s training needs, Zyda’s name was at the top of the list.

An intriguing combination of laid-back Southern California surfer and overcaffeinated Silicon Valley entrepreneur, Zyda frequently uses words like “awesome” and “totally,” yet those words are delivered with rapid-fire intensity and a buzzing physical energy. Compact and sturdy, with a gray mustache and thinning gray hair, Zyda is one of the people most responsible for the partnership between the military and the entertainment industry. While that link is hardly new—think of the numerous propaganda films produced by Hollywood during World War II — the mid-1990s witnessed the start of an unprecedented level of collaboration between the two groups. More than any other single person, Mike Zyda played a seminal role in this process.

Zyda’s interest in computers dates back to his undergraduate years at the University of California at San Diego, where, as a freshman math major in 1973, he got a job working in the lab of a physical chemistry professor named Kent Wilson. The job interview was brief, with Wilson asking Zyda only whether he was willing to learn three things: computer graphics, programming, and how to write grant proposals.

Wilson’s lab offered the kind of freewheeling intellectual and creative environment that marked the high-tech world at the time. Zyda worked alongside seventeen other undergraduates, experimenting with computers, lasers, and chemicals. Among his coworkers were Bud Tribble and Bill Atkinson, both now legendary in the annals of computing. Atkinson, the eleventh employee of Apple Computers, is the creator of MacPaint, QuickDraw, and HyperCard, while Tribble managed the original Macintosh software development team and helped design the Mac OS and user interface.

The “life-changing” experience of working for Wilson led Zyda to pursue a master’s degree in computer information sciences at the University of Massachusetts at Amherst, where his adviser was Victor Lesser, a major figure in the field of simulation. After receiving his doctorate from Washington University in St. Louis, Zyda entered a job market that was remarkably ripe for new PhDs in computer science.

At the time of Zyda’s graduation, many universities around the country were just beginning to create computer science programs, but the lack of graduates with relevant experience meant that there was a dearth of qualified faculty. Without even sending out applications, Zyda was recruited by the Naval Postgraduate School (NPS) in Monterey, California.

Zyda’s focus when he arrived at the school, in February 1984, was real-time graphics. The army’s SIMNET program had started the year before, and there was growing momentum in the military for visual simulators, which at the time cost between $10 million and $30 million each. In 1988 the army tasked Zyda with building a visual simulation system for the fiber-optic-guided missile. The FOG-M was an early version of a drone; it had a TV camera in the front and a thirty-kilometer fiber-optic cable spilling out the back. A soldier watching a video screen would guide the missile with a joystick and crash it into the intended target. Rather than relying on technology built by defense contractors, Zyda and his students built their simulation system to run on a $60,000 Silicon Graphics machine. They finished in six short weeks. When they presented their system to the army personnel at nearby Fort Hunter-Liggett, the response was immediate. “We’re cutting you a check for $100,000,” they told Zyda. “We want to take this system out into the field starting today.”

Zyda and his students next built a simulator for the vehicle on which the FOG-M was mounted, after which they needed to network the two systems together. Luckily, Zyda had learned networking while on a three-week consulting trip in 1987 to Tokyo, where he had built a piece of code that would allow any number of workstations to be connected. He and his students now used that software to build a networked virtual environment that they called the “NPS Moving Platform Simulator.” Soon after, Zyda received a phone call from a man named George Lukes at the U.S. Army Topographic Engineering Center.

“I just read a paper you wrote on your Moving Platform Simulator system,” Lukes told Zyda. “It looks like SIMNET. Can I come to Monterey and talk with you?”

Zyda had never heard of SIMNET, because DARPA hadn’t written any papers or given any talks on it. “What’s SIMNET?” he asked, confused.

After sending Zyda a paper describing SIMNET, Lukes went out to NPS for a demonstration of Moving Platform. After the demonstration, Lukes took Zyda aside and told him how impressive it was. He then offered a proposal.

“Listen,” Lukes said, “the army is just about to take ownership of SIMNET from the defense contractors, but no one in the military knows how to read and write the networking packets. There’s also no one who knows how to read the terrain databases that the contractors have created. Will you do it?”

This was just the kind of challenge that Zyda and the students in his graphics class enjoyed. Using money provided by Lukes, they taught themselves how to read SIMNET’s packets and databases. The source code they created led them to build the Naval Postgraduate School Net, or NPSNET, a collection of Silicon Graphics workstations attached to a local-area Ethernet. NPSNET was in essence a SIMNET-connected simulator that enabled officers both to observe and to participate in the virtual training of their soldiers.

Zyda and his students’ efforts quickly attracted the attention of numerous Department of Defense offices, all of which were interested in the training possibilities of virtual technology. In 1995, Zyda was asked to take part in a National Research Council (NRC) study called “Virtual Reality: Scientific and Technological Challenges,” which advised the government on the kinds of virtual-reality research it should invest in. Though he was a relatively lowly member of the team, Zyda ended up writing about one-third of the final report.

Because of these efforts, the next year Zyda received another call from the National Research Council. The NRC had just received funding from Anita Jones, the Pentagon’s director of defense research and engineering—who was responsible for overseeing the department’s science and technology program, research laboratories, and DARPA — to put together a conference and a report on areas of potential collaboration between the defense and entertainment industries. Would Zyda be willing to chair the committee?

Anita Jones’s interest in the subject stemmed from her previous tenure as chair of the University of Virginia Computer Science Department. There she had hired Randy Pausch, the computer science professor whose book The Last Lecture, published shortly before his death in 1998, became a national sensation. While teaching at UVA, Pausch had taken a sabbatical to go to Disney Imagineering in Orlando, where he worked on DisneyQuest, an indoor interactive theme park filled with virtual-reality attractions. Pleased with the results, Pausch invited Jones — who by then had moved to the Pentagon — to pay a visit to Orlando. As she toured DisneyQuest, Jones had a sudden realization: she was paying various Pentagon outfits heaps of money to build large-scale visual simulations, and yet what Disney had was far better and cheaper. This realization led her to fund Zyda’s National Research Council conference and study.

The conference took place in Irvine, California, over two days in October 1996. Two very different groups were involved. One consisted of military representatives from all four services, DARPA, the Defense Modeling and Simulation Office, and the Office of the Secretary of Defense. The other group consisted of entertainment industry personnel from such companies as Paramount, Disney, Pixar, and Industrial Light and Magic. Zyda, like Jones, wanted to capitalize on technological advances occurring not just in the military but in the worlds of entertainment and digital technology as well. While the specifics of these advances might have varied between fields, Zyda felt there was a key point at which they overlapped: simulation.

The conference featured testimony from the military side about its oft-failed attempts to do physically based modeling for virtual environments. The problem, the military people said, was that they would get wrapped up in the physics and the virtual environments would be difficult to upgrade. The entertainment group offered some simple advice. Look, they said, all you have to do is give people the illusion of an explosion happening; you don’t have to do the actual physics. This was a wake-up call for the military folks, who, from the entertainment group’s perspective, were trying to solve a bunch of problems that they didn’t need to solve. Why not use games built by people who actually know how to build games, the entertainment people suggested, as opposed to using games built by defense contractors?

The Zyda committee’s final report, “Modeling and Simulation: Linking Entertainment and Defense,” claimed that by “sharing research results, coordinating research agendas, and working collaboratively when necessary, the entertainment industry and the DoD may be able to more efficiently and effectively build a technological base for modeling and simulation that will improve the nation’s security and economic performance.” In addition, the report declared it essential that academia be involved in this collaboration, arguing that the entertainment industry and the Department of Defense needed to band together to sponsor the development or further enhancement of academic programs dedicated to the fields of modeling, simulation, and virtual reality — all in the name of national security.

Not everyone was enamored of “Linking Entertainment and Defense.” Anita Jones had delivered the funding for the study through the Defense Modeling and Simulation Office (DMSO). At the time, the DMSO was pushing something called the High Level Architecture, a new infrastructure for networking virtual environments and simulations across the entire Department of Defense. Testimony at the NRC conference pointed out several limitations of the High Level Architecture, but the DMSO insisted that Zyda’s report praise it as the future for networking games. When Zyda refused, the DMSO was furious. After the study came out, Zyda asked Captain Jim Hollenback, the DMSO’s director, what he thought of it. Hollenback did not mince words: “We hated your fucking report,” he told Zyda. “We threw all the copies in the trash.”

The End (and Beginning) of a Dream

Zyda had to wait two more years before the military was ready to accept his report’s recommendations. In January 1999, he received a phone call from Mike Andrews, the chief scientist of the army, and Michael Macedonia, one of his former PhD students at the Naval Postgraduate School. Macedonia was now the chief technology officer at STRICOM, the Pentagon’s simulation and training office. When General Kern had laid down his order to make the military more like Disney, Andrews and Macedonia were on the receiving end. They told Zyda they wanted him to write the operating and research plan for a new institute they planned to build at the University of Southern California, UCLA, or UC Berkeley. This facility, to be named the Institute for Creative Technologies, would give the army direct access to the game and virtual environment technology being developed by the entertainment industry and academia and would be funded by a Pentagon seed grant of $100 million. Andrews and Macedonia felt that “Linking Entertainment and Defense” provided the perfect road map.

The call couldn’t have come at a better time for Zyda. After spending most of his career at the Naval Postgraduate School, he was looking for a way out. Working from “Linking Entertainment and Defense,” Zyda wrote the research agenda and operating plan for the Institute for Creative Technologies in thirty days. He flew to USC to meet with the dean of cinema, the dean of engineering, and the director of the Information Sciences Institute. Then, in March 1999, Zyda went to the Pentagon to meet with Andrews and Macedonia in person. Both of them were enthusiastic about his document. “This is great!” they told him. “Why don’t you go back and spend some more time socializing at USC? We want to build the institute there.”

Zyda spent the next three months working on setting up the ICT. That June, however, Andrews and Macedonia abruptly stopped returning his e-mails and phone calls. He soon learned that the position of ICT director, which he had been promised, had instead gone to former Paramount television executive Richard Lindheim, a veteran of Star Trek and a close friend of USC dean Elizabeth Daly. Zyda had spent most of 1997 doing technology consulting for Lindheim, advising him on building the StoryDrive Engine for Star Trek: Voyager.

Denied the job he wanted, Zyda decided to create a research institute like ICT at the Naval Postgraduate School. Again using “Linking Entertainment and Defense” as a template, he set up the MOVES (Modeling, Virtual Environments, and Simulation) Institute, staffed by a combination of researchers and graduate students dedicated to modeling and simulation, with a core emphasis on computer gaming. This put Zyda in the unique position of building his own research institute to compete against the other research institute he had founded.

Both the ICT and MOVES ended up playing crucial roles in advancing the military’s use of video games for training and education as well as for recruiting and mental health treatment. In later chapters we will see how the ICT and MOVES — along with the army’s simulation and gaming office — are two key sites from which the twenty-first-century military-entertainment complex has expanded. Today the ICT in particular remains influential, and is helping to keep alive the military’s tradition of technological innovation.

Yet the soil from which the military-entertainment complex has grown consists of more than just technology and video games. Equally relevant to this growth is the military’s extensive, yet little noted, legacy of educational innovation. As we are about to see, this legacy— like that of technology — possesses surprisingly deep roots.

Excerpted from "War Play," © 2013 by Corey Mead. Reproduced by permission of Houghton Mifflin Harcourt. All rights reserved.


Routine HIV screening among blood donors in Buenos Aires (Argentina): results from six years' experience and report of a single window-period donation.
Blood donor HIV antibody detection has been mandatory in Argentina since 1991, and p24 antigen screening was recommended in 1997. A total of 30,132 consecutive donations were screened. Repeatedly reactive samples were tested by another screening test and/or by Western blot (WB) for HIV Ab, or by a neutralization assay for p24 Ag. Among the total, 0.3623% of samples were repeatedly reactive and 0.2084% were true HIV-infected donors. Only one donor tested nonreactive for HIV Ab, repeatedly reactive for p24 Ag, positive by neutralization assay, and seroconverted later. Samples with a signal-to-cutoff (S/CO) ratio >/= 3.00 on routine HIV Ab testing were 100.0% positive by WB and/or repeatedly reactive by the second test. In samples with a S/CO ratio < 3.00, 11.1% were positive by WB and/or the majority were nonreactive by the second test. Among HIV-infected donors, 89.5% possessed risk factors (which had been denied previously), 56.5% were repeatedly reactive by other screening procedures and 88.6% were coinfected with other blood-transmissible viruses. When the EIA S/CO ratio is >/= 3.00, WB can be replaced by a second screening test. The pre-donation questionnaire should be improved to detect risk behavior in prospective donors. There was a high association between HIV and other blood-transmissible viruses.


Dealing with clinical heterogeneity in meta-analysis. Assumptions, methods, interpretation.
There is an ongoing debate how to interpret findings of meta-analyses when substantial clinical heterogeneity is present among included trials. The aim of the present study was to demonstrate various ways of dealing with clinical heterogeneity along with underlying assumptions and interpretation. A recent meta-analysis on long-term psychodynamic psychotherapy (LTPP) was used as an illustrative example. Re-analysis of published data including calculation of a prediction interval, heterogeneity tests, Bayesian meta-analysis, meta-regression, and subgroup analysis to explore and interpret summary estimates in clinically heterogeneous studies. Meta-analytic results and their implications varied considerably depending on whether and how clinical heterogeneity was addressed. Whether or not to trust summary estimates in meta-analysis depends largely on the subjective relevance of clinical heterogeneity present. No single analysis and interpretation strategy can be valid in every context or paradigm, thus, reflection of own beliefs on the role of heterogeneity is needed.


Q:

Can Not Set Value of DOM Element Unless New Value Is Strictly Numeric

DISCLAIMER: total beginner with regards to browser extensions and javascript.
BACKGROUND:
I'm trying to develop a proof-of-concept Chrome extension that picks up the text from the input fields in the HTML form of the web page loaded into one tab, and enters the same text on analogous fields of the page in another tab.
In my particular example, the source page is a minimal, local HTML file with two input fields ("user name" and "password"), and the destination is the login page for Apple's Developer Website (https://developer.apple.com/account/).
Reading the official guides and questions here, I've put together some code that seems to work.
THE PROBLEM:
Only text consisting of digits (e.g.: "111111") gets copied from one tab to the other. As soon as my input field contains letters (e.g.: "111111a"), nothing happens.

This is the source page (local file:///):
<html>
  <head>
    <title>Source Page</title>
    <meta charset="utf-8" />
    <script src="popup.js"></script>
  </head>
  <body>
    <form>
      <input id="accountname_src" name="appleId" placeholder="Apple ID" /><br />
      <input id="accountpassword_src" name="password" placeholder="Password" />
    </form>
  </body>
</html>

The destination HTML (Apple's page) has similar input fields with element ids of accountname and accountpassword, respectively.
My extension's script is as follows:
document.addEventListener('DOMContentLoaded', function(){
    // The button in the browser action popup:
    var button = document.getElementById('autofill');

    var sourceTabID = null;
    var destTabID = null;

    // Get the SOURCE tab id:
    chrome.tabs.query({'title': 'Source Page'}, function(tabArray){
        sourceTabID = tabArray[0].id;
    });

    // Get the DESTINATION tab id:
    chrome.tabs.query({'title': 'Sign in with your Apple ID - Apple Developer'}, function(tabArray){
        destTabID = tabArray[0].id;
    });

    if (button !== null){
        button.addEventListener('click', function(){

            // Get entered text from Source page:
            chrome.tabs.executeScript(sourceTabID, {file: "read_input.js"}, function(results){

                var credentials = results[0];
                var userName = String(credentials[0]);
                var password = String(credentials[1]);

                // Pass values to Apple login page:
                var insertUserNameCode = "document.getElementById('accountname').value = " + userName + ";"
                var insertPasswordCode = "document.getElementById('accountpassword').value = " + password + ";"
                var autofillCode = insertUserNameCode + insertPasswordCode;

                chrome.tabs.executeScript(destTabID, {code:autofillCode});
            });

            //window.close();
        });
    }
});

of course, the contents of read_input.js are:
var userName = document.getElementById("accountname_src").value;
var password = document.getElementById("accountpassword_src").value;

var attributes = [userName, password];

attributes  // (Final expression, passed to callback of executeScript() as 'results')

It feels like there could be a type inference problem somewhere, but can't tell where.

Bonus Question:
I can read the input fields in the source page using an external script (read_input.js above) and the method chrome.tabs.executeScript(..., file:...; but when I try to write the values to the destination tab using a similar approach, the script does not run (that is why I'm using chrome.tabs.executeScript(..., code:... in my code). Any idea what can be happening?

A:

Silly me (again)... Some console.logging led me in the right direction...
I was not escaping the value in the script; these lines:
var insertUserNameCode = "document.getElementById('accountname').value = " + userName + ";"
var insertPasswordCode = "document.getElementById('accountpassword').value = " + password + ";"

...should be:
var insertUserNameCode = "document.getElementById('accountname').value = '" + userName + "';"
var insertPasswordCode = "document.getElementById('accountpassword').value = '" + password + "';"

(added single ticks around the values)
...so that the code ends up as:
document.getElementById('accountname').value = '111111a';

...instead of:
document.getElementById('accountname').value = 111111a;

Still not sure why a numbers-only value works, though.


*ID: 4521
*UPC/EAN: 63448XXXXXX
* includes Snake, Guardian, and Stalker Predator
*approximately 6.75 in (17.2 cm) tall
*blistercard packaging
*based on the series Predators 2
*produced by Neca An amazing collection of all new Predator figures based on the Lost tribe of Predators as seen in Predator 2. Many of these are action figure firsts! Never before seen in action figure form, all with improved articulation including double knee joints and ball jointed hips. Over 25 points of articulation on each figure! Series five includes the Snake, Guardian, and Stalker Predator all with movie accurate accessories. Item is kept in it's original packaging. Ships in a box to ensure item arrives in perfect condition.. See more Reptiles Reptiles in San Francisco.

*ID: 4573
*UPC/EAN: 69978XXXXXX
*approximately nine in (22.9 cm) tall
*based on the movie The Amazing Spider-Man *designed and Sculpted by Gentle Giant
*produced by Diamond Select A Diamond Select Release! Designed and Sculpted by
Gentle Giant! Prowling the sewers of New York, it's the
creature who was once Dr. Curt Connors -- the Lizard! This
bust of the Spidey's main villain from The Amazing
Spider-Man stands 9" H atop his decorative pedestal. Item is kept in it's original packaging. Ships in a box to ensure item arrives in perfect condition.. See more Reptiles Reptiles in San Francisco.

*ID: 4646
*UPC/EAN: 63448XXXXXX
* includes only Snake Predator; others sold separately
*approximately 6.75 in (17.2 cm) tall
*blistercard packaging
*based on the series Predators 2
*produced by Neca An amazing collection of all new Predator figures based on the Lost tribe of Predators as seen in Predator 2. Many of these are action figure firsts! Never before seen in action figure form, all with improved articulation including double knee joints and ball jointed hips. Over 25 points of articulation on each figure! Series five includes the Snake, Guardian, and Stalker Predator all with movie accurate accessories. Item is kept in it's original packaging. Ships in a box to ensure item arrives in perfect condition.. See more Reptiles Reptiles in San Francisco.

*ID: 8057
*UPC/EAN: 63448XXXXXX
*approximately eight in (20.3 cm) tall
*blister card packaging
*based on the series Escape from New York
*manufactured by Neca Action figure and action movie fans will both rejoice at our latest offering: a brand new Snake Plissken doll based on the 1981 film Escape from New York, and featuring the likeness of actor Kurt Russell! This poseable 8" figure is dressed in fabric clothing similar to the toy lines that helped define the licensed action figure market in the 1970s. Snake wears his iconic camo pants, muscle tee and assault boots and comes with a removable jacket, holster belt, and enough weaponry to take down a small army. Blister card packaging with removable protective clamshell. Item is new and unopened in original packaging.. See more Reptiles Reptiles in San Francisco.

*ID: 8057
*UPC/EAN: 63448XXXXXX
*approximately eight in (20.3 cm) tall
*blister card packaging
*based on the series Escape from New York
...

*ID: 8119
*UPC/EAN: 4571368445209
*approximately four in (10 cm) tall
*prepainted ABS & PVC
*window box packaging
*based on the series Metal Gear Solid
*manufactured by Nice Smile Company An action figure ready to infiltrate any location! From "METAL GEAR SOLID" comes a Nendoroid of the main character of the series, the infiltration specialist 'Solid Snake'! The rough look of his character has been preserved while still giving him the cuter appearance provided by the Nendoroid design! He is the 1st ever Nendoroid designed to be posed in a prone position, allowing you to display him sneaking around just like in the game! Optional parts include his handgun, an assault rifle as well as a cardboard box to keep him hidden! An optional low-polygon face part is also included, allowing fans of the original game to enjoy the classic Snake once again! Item is new and unopened in original packaging.. See more Reptiles Reptiles in San Francisco.

*ID: 8951
*UPC/EAN: 4545784063538
*approximately 6.3 in (16 cm) tall
*based on the game Metal Gear Solid 2: Sons of Liberty
*manufactured by Max Factory "Kept you waiting, huh? I'm at the sneak-point." From the popular game 'METAL GEAR SOLID 2: SONS OF LIBERTY' comes a figma of the main character, Solid Snake! Using the smooth yet posable joints of figma, you can act out a variety of different scenes. He comes with a standard expression with movable eyes as well as alternate expression with clenched teeth. The tranquilizer gun, assault rifle and cardboard box Snake uses in the game are all included. The assault rifle also comes with shooting effect parts. He also comes with various hand parts including 'hanging' hand parts to avoid detection as well as a hand holding a cigarette. An articulated figma stand is included, which allows various poses to be taken. Item is new and unopened in original packaging.. See more Reptiles Reptiles in San Francisco.

We upgraded our tank when our lizard got too big for this one. It's a twenty gallon glass tank with a screen top, with dimensions 30ins by 12ins by 12ins. It comes with two food/water bowls, two in-tank thermometers, and two nets. The tank also comes with a background sticker featuring a majestic Australian desert landscape. (I'm not really sure if the desert is authentically Australian, but if you don't tell your lizard, I won't either.) We're selling it for $50 OBO. Thanks!. See more Reptiles Reptiles in San Francisco.

Boots is a lovable looking, docile snake that I've had for almost a year. I am selling him because my roommates aren't his biggest fans (not everyone likes snakes, weird!) He comes with his 30 gallon tank (2x2ft base, 2.5 feet tall), cabinet/stand for tank (2x2ft base, 2.5in tall), plastic bucket for bedding, which fits nicely in the cabinet, and his water dish. He is a lovely, friendly snake and I would like to find a nice home for him. I'm going to say $75 for the entire setup- definitely a steal. He is under 2yrs old and is three feet, 6 ins long. See pictures below.. See more Reptiles Reptiles in San Francisco.

Boots is a lovable looking, docile snake that I've had for almost a year. I am selling him because my roommates aren't his biggest fans (...


Welcome to StewardShip

Your free trial and membership will be finalized when you check out.

*Bordeaux Futures, Wine Clubs and Corporate Gifts are not eligible. Applies to standard shipping, which is quite speedy! Expedited shipping available at discounted rates for StewardShip members.Learn More

Winemaker's Notes

Deep ruby with flickers of violet, its delicate aromas of truffle, five spice and spring flowers are supported by a rich core of licorice, saddle leather and Provencal herbs. Very "Burgundian" in style, the palate is elegant and pure with subtle notes of crushed cherries, earth and cedar all neatly wound by a taut spine of acidity and ripe supple tannins.

Critical Acclaim

JH94

Australian Wine Companion - "A blend of grenache, shiraz and mataro that has greater weight and complexity than the colour would suggest, even to the extent of touches of spice and chocolate; the overall balance between fruit, oak and tannins is good, and merits medium-term cellaring."

RP93

The Wine Advocate - "Medium to deep garnet in color with a touch of purple, the 2010 The Steading is a Grenache, Shiraz and Mataro (Mourvedre) blend that radiates a gorgeous nose of dried mulberries, kirsch and red currant jelly enhanced by a baking spice undercurrent. Full-bodied, rich and concentrated on the palate, it has a medium to firm level of velvety tannins and enough acid to give lift through the long finish."

WS92

Wine Spectator - "Polished, expressive and layered, with violet-tinged blackberry, cherry and a gloss of meaty, smoky and spicy flavors, finishing with a sensation of sweetness and purity. Has depth and grace. Grenache, Shiraz and Mataro. Drink now through 2020."

Torbreck Winery

Torbreck, founded in 1994 by David Powell, is situated at Marananga on the western ridge of the Barossa. Since that time he has produced some of the world?s finest 'Rhone varietal' wines, exclusively from Barossa fruit; this has been acknowledged by the wine press in Europe, America and Australia. The overwhelming majority of his vines are dry-grown, nearly all are 80 - 125 years old and are tended and harvested by hand.

The wines have an extraordinary combination of power, intesity, complexity and great finesse, and bearing in mind the age of the vines and the laughably low yields, no Torbreck wine could ever be accused of being heavy, cloying or over-extracted.
View all Torbreck Wines

About Barossa Valley

The Barossa zone consists of two sections - the Barossa Valley and the Eden Valley. Wines from the Eden Valley can be labelled Barossa or Barossa Valley.

Situated just a bit east of the large city of Adelaide, Barossa is Australia's wine headquarters. Mega producers are based here, boutique wineries call it home and a majority of the habitants claim their income on the wine industry. The valley is strewn with a series of hamlets, small towns spotted throughout the region.

Barossa Valley

Barossa is red-wine territory, with red grapes consisting of about two-thirds of the region's plantings. The reds, Shiraz in particular, are lauded for their rich, concentrated flavors and aging potential. Old vines of Shiraz and Grenache are popular, many up to 80 years old. The valley is home to some of the most famous vineyards of Australia - this is where the first Penfolds Grange was made. Whites are also found, mainly from the Semillon grape – these wines are as full-bodied as the reds although harder to find. Riesling and Chardonnay are also planted.

Eden Valley

Right next to Barossa Valley, but a bit higher in elevation, Eden Valley is an ideal neighbor. Many wineries source vineyards from both areas as the climate difference in Eden Valley leads to wines of a different character. Reds are still mainly Shiraz and Grenache, but the wines are often more restrained and less dense than those in the Barossa Valley proper. Whites are popular here too. Eden Valley Rieslings and Semillons are particularly excellent.

About Australia

Like the United States, which is about the same size, Australia's winemaking regions are huddled into one or two pockets of the country. The state of South Australia, which produces about 60% of the country's wine, also has the most wineries and sub-regions, including McLaren Vale, Clare Valley, Coonawarra and Barossa Valley. New South Wales is home to the Hunter Valley, while the smaller, southern state of
Victoria is best known for theYarra Valley. Head way west to the very large state of Western Australia and you'll find the tiny region of Margaret River at the southern tip.

The Shiraz offers dark plum fruits, mulberries and licorice with plenty of concentration, depth and velvety tannin.The Grenache adds a
lovely lusciousness to the wine with raspberry, blueberry and floral notes adding prettiness. Both of the afore mentioned varieties also ...

It is a garnet red colored wine with a blue hue. Its scent of ripe fruit is dominated by black
currants underlined with hints of spices and pepper. In the mouth, it is round and harmonious with long smooth tannins. ...

The 2012 Plexus is a crimson purple red color. The wine offers an array of red and black berry aromatics,
wild berries and cassis. Generous, with soft texture and fine tannins. Flavors of blackberry and dark cherry with hints of ...

Alcohol By Volume Guide

Most wine ranges from 10-16% alcohol by volume. Some varietals tend to have higher (for example Zinfandel and Cabernet Sauvignon) or lower alcohol levels (Pinot Noir and many white varietals), but there is always some variation from producer to producer. Some wine falls outside of this range, for instance Port weighs in closer to 20%, while Muscat and Riesling are usually a bit below 10%.

Wine Style Guide

Light & Fruity

Red wines that are more fruit-forward and lighter in tannin and body.

Smooth & Supple

Medium bodied reds that go down easy, with smooth tannins and supple fruit.


Q:

Facebook Graph API - Video Upload

With the REST api in the process of being deprecated, I'm trying to convert our existing application to use the facebook c# sdk.
One of the things we can currently do, is post a video by uploading it.
I've created a POST request as follows, but I'm getting a failure of 'Unsupported Post Request'.
            byte[] video = File.ReadAllBytes(TESTDATA_DIR + "Snowboarding penguin.mov");

        if (_FBClient != null)
        {
            var parameters = new Dictionary<string, object>();
            parameters.Add("message", "This is a Graph API unit test message containing a video! (" + DateTime.Now.ToString() + ")");
            parameters["caption"] = "This is the caption for the unit test message!";
            parameters["description"] = "This is description for the unit test message!";
            parameters["name"] = "This is name of the unit test message!";
            parameters["req_perms"] = "publish_stream";
            parameters["scope"] = "publish_stream";

            var mediaObject = new FacebookMediaObject
            {
                FileName = "Snowboarding penguin.mov",
                ContentType = "video/mov",
            };
            mediaObject.SetValue(video);
            parameters.Add("source", mediaObject);

            _FBClient.Post("me/videos", parameters);
        }

I see lots of general posts about video uploading not being supported by the GRAPH API, but hopefully this has been resolved by FB now.
Can anyone steer me in the right direction for getting this request to work?
TIA

A:

Video uploading is not supported by the graph api. You will need to use the old rest api.

        var videoPath = "c:\\sample.3gp";
        byte[] video = File.ReadAllBytes(videoPath);

        var mediaObject = new FacebookMediaObject
                              {
                                  FileName = "sample.3gp",
                                  ContentType = "video/3gpp"
                              };
        mediaObject.SetValue(video);

        dynamic parameters = new ExpandoObject();
        parameters.source = mediaObject;
        parameters.method = "video.upload";
        parameters.access_token = "access_token";

        var fb = new FacebookClient();
        dynamic result = fb.Post(parameters);

UPDATE
Facebook recently supported uploading video via graph api. You can find the details on how to use graph api video upload from Facebook C# SDK at http://blog.prabir.me/post/Facebook-CSharp-SDK-Uploading-Video-via-Graph-Api.aspx
Requires Facebook C# SDK v5.0.46 or higher.
var fb = new FacebookClient("access_token");
dynamic parameters = new ExpandoObject();
parameters.source = new FacebookMediaObject { ContentType = "video/3gpp", FileName = "video.3gp" }.SetValue(File.ReadAllBytes(@"c:\video.3gp"));
parameters.title = "video title";
parameters.description = "video description";
dynamic result = fb.Post("/me/videos", parameters);
Console.WriteLine(result);


For sale is a seed spreader/aerator. It is in great condition. The blades on the inside are known to rust cause they are usually cheap steel I had the replaced with stainless steel so you shouldn't have to worry about them rusting. $95. Bracket added to hook up to 4 wheeler can be removed.

For sale is a seed spreader/aerator. It is in great condition. The blades on the inside are known to rust cause they are usually cheap steel I had the replaced with stainless steel so you shouldn't have to worry about them rusting. $95. Bracket added to hook up to 4 wheeler can be removed.

Nice item in perfect shape. Can be used for fertilizer, ant killer, weed killer, grass seed, etc etc etc. Great time to put stuff down and have it come up during the Spring. Works great, larger and high quality. Selling cheap, much better than buying from the store, Lowes, ACE, or Home Depot. As long as the ad is up then I still have it available, I will delete this ad when its gone.

Corsicana 3pt No Till Pasture Renovator / Grass Seeder - 6ft Wide. Specially designed rippers break the soil and the seed is dropped in the furrows. All in good working condition. $385 Cash. Call John at cell or home If no answer leave message.


Your Good Health: Correct medical marijuana dosage elusive

Dear Dr. Roach: Recently in your column, you discussed the need for dosages to be exact in some situations. What about the medical marijuana issue? In our small town, there are four dispensaries. If someone truly felt he or she needed it for medical issues, would that person get the same dosage at each location? If the doctor prescribes Aspirin, he doesn’t have me go to the willow tree or to the willow dispensary down the street.

J.O.

You are exactly right that the content of the active components of marijuana varies from strain to strain and even from plant to plant. This makes getting exact dosages impossible. This is a general problem with natural products, which is why Western medicine has preferred to identify, extract and purify the active ingredients.

There is a potential downside to this philosophy, which is that the purification might remove other substances, which could themselves have an effect or modify the effect of a substance found in the original natural product.

This appears to be the case with marijuana, as there are at least two compounds with important potential medical benefits, tetrahydrocannabinol (THC, which has several subtypes, especially delta-9 and delta-4) and cannabidiol (CBD).

The effect of dronabinol (Marinol), a synthetic form of delta-9 THC, is reported as being very different from natural marijuana by most people who have used both, though this might be an effect of dose, of speed of onset or of expectations.

Hence, the interest in medical marijuana, with its multiple compounds and ability for growers to emphasize the THC or CBD content.

Recreational users of marijuana have experience in achieving the correct dosage; however, for medical use (such as seizures), that ability isn’t relevant. I suspect the future will include a greater degree of chemical analysis of the THC and CBD content in a given batch.

Dear Dr. Roach: I was told that a gastric bypass only makes the stomach smaller and does not affect metabolism. Is this true?

D.R.

There are several types of bariatric surgery (surgical procedures designed to help people lose weight). About 50 per cent of bariatric procedures done now are of a type called Roux-en-Y gastric bypass.

This procedure does indeed make the stomach smaller: The primary means for weight loss is a sensation of the stomach feeling full after ingesting less food. However, the small intestine also is bypassed, causing some food not to be properly absorbed.

Also, removing a portion of the stomach changes some of the hormones involved in weight loss (especially one called ghrelin, which promotes hunger and is made in the portion of the stomach that is removed). So it does affect metabolism.

Lower levels of ghrelin lead to less hunger.

After two years, the expected loss of excess weight (the difference between what the person weighed and what he or she should weigh) is about 70 per cent with a Roux-en-Y.

Part of the reason this type of bariatric surgery might be more effective than other types, such as the gastric sleeve procedure or gastric banding, could be due to the hormonal changes associated with removing the ghrelin-producing cells.

Bariatric surgery remains the most effective long-term weight solution for people with serious weight problems, but it is not for everybody.

Dr. Roach regrets that he is unable to answer individual letters, but will incorporate them in the column whenever possible. Readers may email questions to ToYourGoodHealth@med.cornell.edu.


"Filed out from Dolphin Smalltalk 7"!

TestCase subclass: #STONWriterTest
	instanceVariableNames: ''
	classVariableNames: ''
	poolDictionaries: ''
	classInstanceVariableNames: ''!
STONWriterTest guid: (GUID fromString: '{c786d815-b405-4113-a350-3ee3370c7879}')!
STONWriterTest comment: ''!
!STONWriterTest categoriesForClass!STON-Tests-Writer! !
!STONWriterTest methodsFor!

serialize: anObject
	^ String streamContents: [ :stream |
		STON writer
			on: stream;
			nextPut: anObject ]!

serializeAsciiOnly: anObject
	^ String streamContents: [ :stream |
		STON writer
			on: stream;
			asciiOnly: true;
			nextPut: anObject ]!

serializeJson: anObject
	^ String streamContents: [ :stream |
		STON jsonWriter
			on: stream;
			nextPut: anObject ]!

serializePretty: anObject
	^ String streamContents: [ :stream |
		STON writer
			on: stream;
			prettyPrint: true;
			nextPut: anObject ]!

testAssociation
	self assert: (self serialize: 'foo' -> 1) equals: '''foo'':1'.
	self assert: (self serialize: #bar -> 2) equals: '#bar:2'.
	self assert: (self serialize: 'foo bar' -> #ok) equals: '''foo bar'':#ok'.
	self assert: (self serialize: 123 -> 456) equals: '123:456'!

testBag
	self
		assert: (self serialize: (Bag withAll: #(a a)))
		equals: 'Bag{#a:2}'.
	self
		assert: (self serialize: Bag new)
		equals: 'Bag{}'
!

testBoolean
	self assert: (self serialize: true) equals: 'true'.
	self assert: (self serialize: false) equals: 'false'!

testByteArray
	self assert: (self serialize: #(1 2 3) asByteArray) equals: 'ByteArray[''010203'']'!

testClass
	self assert: (self serialize: Point) equals: 'Class[#Point]'!

testColor
	self
		assert: (self serialize: Color red)
		equals: 'Color[#red]'.
	self
		assert: (self serialize: (Color red copy setAlpha: 0.4))
		equals: 'Color{#red:1.0,#green:0.0,#blue:0.0,#alpha:0.4}'.
	"This test is sensitive to the precision of the representation. As Color's in Dolphin have only 255 distinct values for each of the primary colours, rounding error gives a different result."
	self
		assert: (self serialize: Color red lighter lighter)
		equals: 'Color{#red:1.0,#green:0.063,#blue:0.063,#alpha:1.0}' "'Color{#red:1.0,#green:0.061,#blue:0.061,#alpha:1.0}'."
!

testCustomNewline
	| output |
	output := String streamContents: [ :out |
		(STON writer on: out)
			newLine: String lf;
			prettyPrint: true;
			nextPut: #( 1 ) ].
	#dolphin. "withCRs does not behave in a portable manner"
	self
		assert: output
		equals: ('[\	1\]' withCRs "replaceAll: Character cr with: Character lf" copyWithout: Character cr)!

testDate
	| date |
	self skip. "Dolphin's legacy Dates do not support TZ offset."
	date := (Date year: 2012 month: 1 day: 1) translateToUTC.
	self assert: (self serialize: date) equals: 'Date[''2012-01-01Z'']'.
	date := (Date year: 2012 month: 1 day: 1) translateTo: 1 hour.
	self assert: (self serialize: date) equals: 'Date[''2012-01-01+01:00'']'.!

testDateAndTime
	| dateAndTime |
	dateAndTime := DateAndTime
		year: 2012
		month: 1
		day: 1
		hour: 6
		minute: 30
		second: 15
		offset: 1 hour.
	self assert: (self serialize: dateAndTime) equals: 'DateAndTime[''2012-01-01T06:30:15+01:00'']'!

testDictionary
	| collection |
	collection := STON mapClass new
		at: 1 put: 1;
		at: 2 put: 2;
		yourself.
	self assert: (self serialize: collection) equals: '{1:1,2:2}'.
	self assert: (self serialize: STON mapClass new) equals: '{}'!

testDictionaryWithComplexKeys
	| collection |
	collection := STON mapClass new at: true put: 1; at: #(foo) put: 2; yourself.
	self assert: (#('{true:1,[#foo]:2}' '{[#foo]:2,true:1}') includes: (self serialize: collection))!

testDoubleQuotedString
	| string |
	self assert: (self serializeJson: 'foo') equals: '"foo"'.
	self assert: (self serializeJson: 'FOO') equals: '"FOO"'.
	self assert: (self serializeJson: 'élève en Français') equals: '"élève en Français"'.
	string := String withAll: {$" . $' . $\ . $/ . Character tab . Character cr . Character lf . Character newPage . Character backspace}.
	"Note that in JSON mode, double quotes get escaped, and single quotes not"
	self assert: (self serializeJson: string) equals: '"\"''\\/\t\r\n\f\b"'!

testEmptyArrayPretty
	self assert: (self serializePretty: STON listClass new) equals: '[ ]' !

testEmptyDictionaryPretty
	self assert: (self serializePretty: STON mapClass new) equals: '{ }' !

testFloat
	self assert: (self serialize: 1.5) equals: '1.5'.
	self assert: (self serialize: 0.0) equals: '0.0'.
	self assert: (self serialize: -1.5) equals: '-1.5'.
	self assert: ((self serialize: Float pi) beginsWith: '3.14159').
	self assert: ((self serialize: (1 / 3) asFloat) beginsWith: '0.333').
	self assert: (self serialize: (10 raisedTo: 100) asFloat) equals: '1.0e100'.
	self assert: (self serialize: (10 raisedTo: -50) asFloat) equals: '1.0e-50'.
	self assert: (self serialize: (10 raisedTo: -50) asFloat negated) equals: '-1.0e-50'!

testFraction
	self assert: (self serialize: 1/3) equals: '1/3'.
	self assert: (self serialize: -1/3) equals: '-1/3'.
	self assert: (self serialize: 10/100) equals: '1/10'.
	self assert: (self serialize: 100/10) equals: '10'.
	self assert: (self serialize: 123/123) equals: '1'.
	self assert: (self serialize: 100/11) equals: '100/11'.!

testIdentityDictionary
	| collection |
	collection := IdentityDictionary new
		at: 1 put: 1;
		at: 2 put: 2;
		yourself.
	self assert: (self serialize: collection) equals: 'IdentityDictionary{1:1,2:2}'.
	self assert: (self serialize: IdentityDictionary new) equals: 'IdentityDictionary{}'!

testInteger
	self assert: (self serialize: 1) equals: '1'.
	self assert: (self serialize: 0) equals: '0'.
	self assert: (self serialize: -1) equals: '-1'.
	self assert: (self serialize: 1234567890) equals: '1234567890'.
	self assert: (self serialize: -1234567890) equals: '-1234567890'!

testIsSimpleSymbol
	self assert: (STON writer isSimpleSymbol: #foo).
	self assert: (STON writer isSimpleSymbol: #az).
	self assert: (STON writer isSimpleSymbol: #AZ).
	self assert: (STON writer isSimpleSymbol: #N0123456789).
	self assert: (STON writer isSimpleSymbol: #foo123).
	self assert: (STON writer isSimpleSymbol: #'Foo/Bar').
	self assert: (STON writer isSimpleSymbol: #'Foo.Bar').
	self assert: (STON writer isSimpleSymbol: #'Foo-Bar').
	self assert: (STON writer isSimpleSymbol: #'Foo_Bar').
	self assert: (STON writer isSimpleSymbol: #foo).
	self deny: (STON writer isSimpleSymbol: #'#^&$%')!

testKeepingNewLines
	| input result output |
	input := 'line ending with CR', String cr,
		'line ending with LF', String lf,
		'line ending with CRLF', String crlf.
	output := '''line ending with CR', String crlf,
		'line ending with LF', String crlf,
		'line ending with CRLF', String crlf, ''''.
	result := String streamContents: [ :out |
		(STON writer on: out) newLine: String crlf; keepNewLines: true; nextPut: input ].
	self assert: result equals: output.
	output := '''line ending with CR', String cr,
		'line ending with LF', String cr,
		'line ending with CRLF', String cr, ''''.
	result := String streamContents: [ :out |
		(STON writer on: out) newLine: String cr; keepNewLines: true; nextPut: input ].
	self assert: result equals: output!

testList
	self assert: (self serialize: (STON listClass withAll: #(1 2 3))) equals: '[1,2,3]'.
	self assert: (self serialize: STON listClass new) equals: '[]'.
	self assert: (self serialize: (STON listClass withAll: {1 . -1 . 0 . #foo . 'a b c' . true . false . nil})) equals: '[1,-1,0,#foo,''a b c'',true,false,nil]'!

testMap
	| map serialized |
	(map := STON mapClass new)
		at: #foo put: 1;
		at: #bar put: 2.
	#dolphin.	"Test should not assume any ordering of pairs"
	serialized := self serialize: map.
	self assert: (serialized = '{#foo:1,#bar:2}' or: [serialized = '{#bar:2,#foo:1}']).
	self assert: (self serialize: STON mapClass new) equals: '{}'.
	map removeAll.
	map at: 'foo bar' put: #ok.
	self assert: (self serialize: map) equals: '{''foo bar'':#ok}'.
	map removeAll.
	map at: 123 put: 456.
	self assert: (self serialize: map) equals: '{123:456}'!

testMetaclass
	self assert: (self serialize: Point class) equals: 'Metaclass[#Point]'!

testNil
	self assert: (self serialize: nil) equals: 'nil'!

testNonBMPCharacterEncoding
	"Characters not in the Basic Multilingual Plane are encoded as a UTF-16 surrogate pair"

	| string json |
	string := String with: 16r1D11E asCharacter. "MUSICAL SYMBOL G CLEF"
	json := String streamContents: [ :out |
		(STON writer on: out) asciiOnly: true; nextPut: string ].
	self assert: json equals: '''\uD834\uDD1E'''!

testNull
	self assert: (self serializeJson: nil) equals: 'null'!

testOrderedCollection
	| collection |
	collection := OrderedCollection with: 1 with: 2 with: 3.
	self assert: (self serialize: collection) equals: 'OrderedCollection[1,2,3]'.
	self assert: (self serialize: OrderedCollection new) equals: 'OrderedCollection[]'!

testPoint
	self assert: (self serialize: 1 @ 2) equals: 'Point[1,2]'!

testReferenceCycle
	| array |
	array := STON listClass with: 1 with: nil.
	array at: 2 put: array.
	self assert: (self serialize: array) equals: '[1,@1]'!

testReferenceSharing
	| array one |
	one := {#one}.
	array := STON listClass with: one with: one with: one.
	self assert: (self serialize: array) equals: '[[#one],@2,@2]'!

testReferenceSharingError
	| serializer array one |
	serializer := [ :object |
		String streamContents: [ :stream |
			STON writer
				on: stream;
				referencePolicy: #error;
				nextPut: object ] ].
	one := { #one }.
	array := STON listClass with: one with: one with: one.
	self
		should: [ (serializer value: array) = '[[#one],[#one],[#one]]' ]
		raise: STONWriterError
!

testReferenceSharingIgnore
	| serializer array one |
	serializer := [ :object |
	String
		streamContents: [ :stream |
			STON writer
				on: stream;
				referencePolicy: #ignore;
				nextPut: object ] ].
	one := {#one}.
	array := STON listClass with: one with: one with: one.
	self assert: (serializer value: array) equals: '[[#one],[#one],[#one]]'!

testRestrictedClassesInJsonMode
	self should: [ self serializeJson: 1@2 ] raise: STONWriterError.
	self should: [ self serializeJson: #foo->100 ] raise: STONWriterError.
	self should: [ self serializeJson: STONTestUser dummy ] raise: STONWriterError.
!

testScaledDecimal
	self assert: (self serialize: 1/3s2) equals: '1/3s2'.
	self assert: (self serialize: -1/3s2) equals: '-1/3s2'.
	self assert: (self serialize: 1/3s10) equals: '1/3s10'.
	self assert: (self serialize: -1/3s10) equals: '-1/3s10'.!

testString
	| string |
	self assert: (self serialize: 'foo') equals: '''foo'''.
	self assert: (self serialize: 'FOO') equals: '''FOO'''.
	self assert: (self serializeAsciiOnly: 'élève en Français') equals: '''\u00E9l\u00E8ve en Fran\u00E7ais'''.
	self assert: (self serialize: 'élève en Français') equals: '''élève en Français'''.
	string := String withAll: {$" . $' . $\ . $/ . Character tab . Character cr . Character lf . Character newPage . Character backspace}.
	self assert: (self serialize: string) equals: '''"\''\\/\t\r\n\f\b'''!

testSymbol
	self assert: (self serialize: #foo) equals: '#foo'.
	self assert: (self serialize: #FOO) equals: '#FOO'.
	self assert: (self serialize: #bytes) equals: '#bytes'.
	self assert: (self serialize: #'foo.bar') equals: '#foo.bar'.
	self assert: (self serialize: #'foo-bar') equals: '#foo-bar'.
	self assert: (self serialize: #foo_bar) equals: '#foo_bar'.
	self assert: (self serialize: #'foo/bar') equals: '#foo/bar'.
	self assert: (self serialize: #'foo bar') equals: '#''foo bar'''.
	self assert: (self serialize: #foo123) equals: '#foo123'!

testSymbolAsString
	self assert: (self serializeJson: #foo) equals: '"foo"'.
	self assert: (self serializeJson: #FOO) equals: '"FOO"'!

testTime
	| time |
	time := Time hour: 6 minute: 30 second: 15.
	self assert: (self serialize: time) equals: 'Time[''06:30:15'']'.
	time := Time hour: 6 minute: 30 second: 15 nanoSecond: 123.
	self assert: (self serialize: time) equals: 'Time[''06:30:15.000000123'']'.
!

testUser
	| user |
	(user := STONTestUser new)
		username: 'john@foo.com';
		password: 'secret1'.
	self
		assert: (self serialize: user)
		equals: 'TestUser{#username:''john@foo.com'',#password:''secret1'',#enabled:true}'!

testUser2
	| user |
	(user := STONTestUser2 new)
		username: 'john@foo.com';
		password: 'secret1'.
	self
		assert: (self serialize: user)
		equals: 'TestUser2{#username:''john@foo.com'',#password:''secret1'',#enabled:true}'!

testUser3Nil
	| user |
	user := STONTestUser3 new.
	self
		assert: (self serialize: user)
		equals: 'TestUser3{#username:nil,#password:nil,#enabled:true}'!

testUserNil
	| user |
	user := STONTestUser new.
	self assert: (self serialize: user) equals: 'TestUser{#enabled:true}'! !
!STONWriterTest categoriesFor: #serialize:!private! !
!STONWriterTest categoriesFor: #serializeAsciiOnly:!private! !
!STONWriterTest categoriesFor: #serializeJson:!private! !
!STONWriterTest categoriesFor: #serializePretty:!private! !
!STONWriterTest categoriesFor: #testAssociation!public!tests! !
!STONWriterTest categoriesFor: #testBag!public!tests! !
!STONWriterTest categoriesFor: #testBoolean!public!tests! !
!STONWriterTest categoriesFor: #testByteArray!public!tests! !
!STONWriterTest categoriesFor: #testClass!public!tests! !
!STONWriterTest categoriesFor: #testColor!public!tests! !
!STONWriterTest categoriesFor: #testCustomNewline!public!tests! !
!STONWriterTest categoriesFor: #testDate!public!tests! !
!STONWriterTest categoriesFor: #testDateAndTime!public!tests! !
!STONWriterTest categoriesFor: #testDictionary!public!tests! !
!STONWriterTest categoriesFor: #testDictionaryWithComplexKeys!public!tests! !
!STONWriterTest categoriesFor: #testDoubleQuotedString!public!tests! !
!STONWriterTest categoriesFor: #testEmptyArrayPretty!public!tests! !
!STONWriterTest categoriesFor: #testEmptyDictionaryPretty!public!tests! !
!STONWriterTest categoriesFor: #testFloat!public!tests! !
!STONWriterTest categoriesFor: #testFraction!public!tests! !
!STONWriterTest categoriesFor: #testIdentityDictionary!public!tests! !
!STONWriterTest categoriesFor: #testInteger!public!tests! !
!STONWriterTest categoriesFor: #testIsSimpleSymbol!public!tests! !
!STONWriterTest categoriesFor: #testKeepingNewLines!public!tests! !
!STONWriterTest categoriesFor: #testList!public!tests! !
!STONWriterTest categoriesFor: #testMap!public!tests! !
!STONWriterTest categoriesFor: #testMetaclass!public!tests! !
!STONWriterTest categoriesFor: #testNil!public!tests! !
!STONWriterTest categoriesFor: #testNonBMPCharacterEncoding!public!tests! !
!STONWriterTest categoriesFor: #testNull!public!tests! !
!STONWriterTest categoriesFor: #testOrderedCollection!public!tests! !
!STONWriterTest categoriesFor: #testPoint!public!tests! !
!STONWriterTest categoriesFor: #testReferenceCycle!public!tests! !
!STONWriterTest categoriesFor: #testReferenceSharing!public!tests! !
!STONWriterTest categoriesFor: #testReferenceSharingError!public!tests! !
!STONWriterTest categoriesFor: #testReferenceSharingIgnore!public!tests! !
!STONWriterTest categoriesFor: #testRestrictedClassesInJsonMode!public!tests! !
!STONWriterTest categoriesFor: #testScaledDecimal!public!tests! !
!STONWriterTest categoriesFor: #testString!public!tests! !
!STONWriterTest categoriesFor: #testSymbol!public!tests! !
!STONWriterTest categoriesFor: #testSymbolAsString!public!tests! !
!STONWriterTest categoriesFor: #testTime!public!tests! !
!STONWriterTest categoriesFor: #testUser!public!tests! !
!STONWriterTest categoriesFor: #testUser2!public!tests! !
!STONWriterTest categoriesFor: #testUser3Nil!public!tests! !
!STONWriterTest categoriesFor: #testUserNil!public!tests! !


Q:

Cannot phoenix::bind qi::_val with boost 1.53 (regression ?)

The code below, using boost::spirit, used to work with boost 1.44 and boost 1.49:
qi::string("a_token")
[
    boost::phoenix::bind(&node_t::some_func, *qi::_val, true)
]

I updated boost to version 1.53, but now this code does not compile anymore. g++ complains about
error: pointer to member type 'void (node_t::)(bool)' incompatible with object type 'boost::error_cant_deduce_type'

I can't figure out how to fix it. The following code compiles :
qi::string("a_token")
[
    boost::phoenix::bind(&node_t::some_func, (node_t*)0, true)
]

So I guess the problem is with qi::val_... Did the API of boost::spirit changed or am I missing an include file ?
I'm using g++4.7, with --std=c++0x.
Here I tried a small test case to reproduce the problem. The error message is not the same (but it's still big !), but once again the dereference operator seems to be the problem.
#include <boost/spirit/include/qi.hpp>
#include <boost/spirit/include/phoenix_operator.hpp>
#include <boost/spirit/include/phoenix_bind.hpp>
#include <boost/shared_ptr.hpp>

struct node_t
{
    void foo(bool){}
};

int main()
{
    namespace qi = boost::spirit::qi;

    boost::spirit::qi::rule
    <
        std::string::const_iterator,
        boost::shared_ptr<node_t>(),
        boost::spirit::ascii::space_type
    > rule;

    rule = qi::string("true")
        [boost::phoenix::bind(&node_t::foo, *qi::_val, true)];
}

A:

This is an answer made from the helpfull comments above (thanks to llonesmiz).
Changes made in boost::shared_ptr affects old version of boost::pheonix when trying to use the dereference operator * over a boost::shared_ptr.
Before including boost::spirit, #define BOOST_SPIRIT_USE_PHOENIX_V3 1 can be added to the source.
Also, some includes such as #include <boost/spirit/home/phoenix/ ... > are to be removed because it will conflict with spirit v3. Instead, include files such as #include <boost/spirit/include/phoenix.hpp>.


The White House has not created a fake TV network devoted to primates to keep President Donald Trump entertained — but if you’ve been anywhere near Twitter lately, you may have been led to believe it did exactly that.

Such is the power of the Gorilla Channel, which has joined jokes about eating Tide Pods on the list of the biggest early memes of 2018.

Thanks to the same man who brought the world Milkshake Duck, a certain swath of the politically engaged internet spent much of Friday enmeshed in what is by far the most hilarious and unexpected development in the controversy around Michael Wolff’s salacious exposé of the Trump White House.

It involves fighting apes, the president of United States, and a very silly joke that lots of people apparently think is alarmingly close to reality.

What is the Gorilla Channel and what does it have to do with politics?

For the past week, many have been hypnotized by the scandal and intrigue surrounding Fire and Fury, Wolff’s just-released new book about the Trump administration. Social media has been teeming for days with chatter about several shocking excerpts from the book — from the claim that Trump never actually wanted to win the election to allegations that his former chief strategist Steve Bannon believed that Donald Trump Jr.’s 2016 meeting with a Russian lawyer was “treasonous.”

The book has sparked a maelstrom of response, from criticism of its gossipy tone to praise for its revealing glimpse inside a tumultuous administration. It’s even drawn ire (as well as a possible lawsuit) from the commander-in-chief himself.

Enter Ben Ward, who is better known online as Twitter user @pixelatedboat, a.k.a the creator of the popular Milkshake Duck meme that was everywhere toward the end of 2017. That meme took well over a year and a half to percolate and enter the mainstream. But on January 4, Ward created a new meme that went massively viral in under a day.

In the middle of the uproar over Fire and Fury, Ward tweeted a fake excerpt from the book, one in which Trump kicked off his tenure as president by complaining about the TV programming options available to him in the White House.

“On his first night in the White House, President Trump complained that the TV in his bedroom was broken, because it didn’t have ‘the gorilla channel’,” Ward’s fake excerpt declared. “Trump seemed to be under the impression that a TV channel existed that screened nothing but gorilla content, 24 hours a day.”

Wow, this extract from Wolff’s book is a shocking insight into Trump’s mind: pic.twitter.com/1ZecclggSa — the gorilla channel thing is a joke (@pixelatedboat) January 5, 2018

Ward’s fake excerpt immediately took off, garnering nearly 20,000 retweets in under 24 hours, and setting off a wave of “gorilla channel” jokes across social media.

It also caused an incredible amount of confusion, at least initially, because so many people — including major Twitter influencers and members of the media — actually thought it was a real excerpt from Wolff’s book. The confusion was so widespread that Snopes was forced to debunk the excerpt as a “false” internet hoax, and Ward was inspired to temporarily change his Twitter profile name to “the gorilla channel thing is a joke.”

I can't believe people are actually falling for the gorilla channel thing pic.twitter.com/XuBeSXMmBC — Will Sommer (@willsommer) January 5, 2018

For his part, Ward instantly realized that he’d created a monster:

tfw you parody a guy making up shit about Trump but people believe it so you become part of the problem — the gorilla channel thing is a joke (@pixelatedboat) January 5, 2018

Ward’s remorse notwithstanding, once it became clear that the Gorilla Channel story was a parody, it quickly became a meme as people on social media — not to mention several corporate entities eager to get in on the fun — took the joke and ran with it.

┏┓

┃┃╱╲ in

┃╱╱╲╲ this

╱╱╭╮╲╲house

▔▏┗┛▕▔ we

╱▔▔▔▔▔▔▔▔╲

watch the gorilla channel and the gorilla channel only

╱╱┏┳┓╭╮┏┳┓ ╲╲

▔▏┗┻┛┃┃┗┻┛▕▔ — gabe bergado (@gabebergado) January 5, 2018

What makes for a Gorilla Channel? A lot of eating, sleeping, and, of course, playtime! pic.twitter.com/cnXOSSY07z — AnimalPlanet (@AnimalPlanet) January 5, 2018

please stop calling our customer service hotline to ask if we have The Gorilla Channel — Netflix US (@netflix) January 6, 2018

Vice liked the idea so much that it actually launched its own Gorilla Channel — so you can watch yourself and see if it’s worth the hype.

We just made the fake Trump Gorilla Channel a reality. Go bananas watching it here. https://t.co/0fokgdkUri — VICE News (@vicenews) January 5, 2018

Why did a single joke about Trump watching gorillas fight go so viral?

There are several converging reasons for the success of this insta-meme.

For starters, the great Harambe meme of 2016 has already shown us that gorillas + the internet = meme magic.

There absolutely IS a Gorilla Channel, or how else would Koko have seen Dad’s movies?

WAKE UP SHEEPLE! pic.twitter.com/tB9uRxjkRS — Zelda Williams (@zeldawilliams) January 5, 2018

For another, Ward, having already achieved Twitter fame thanks to the popularity of the Milkshake Duck meme and his consistently humorous feed, had, with 170,000 followers, the reach to spread the joke far and wide instantly — much to the chagrin of those who were quick to point out that creating meme lightning in a bottle twice is kind of unholy:

I can't believe @pixelatedboat got to coin Milkshake Duck and Gorilla Channel and now they're both just straight up media terms it's not fair IT'S NOT FAIR — Daniel Kibblesmith ⛄⚔ (@kibblesmith) January 5, 2018

Creating Milkshake Duck *and* Gorilla Channel is like the year Travolta did Saturday Night Fever and Grease. pic.twitter.com/cQpLece7PF — Schooley (@Rschooley) January 6, 2018

Then there’s the context of the joke itself. President Trump is not only notorious for his “post-literate” obsession with cable TV, but Ward’s characterization of the president as insisting on watching only gorilla fight scenes has a real-life antecedent: a 1997 New Yorker report in which Trump made one of his sons fast-forward through an action movie solely so he could watch only the fight scenes.

Finally, there’s the fast-and-loose caliber of many of the anecdotes in Fire and Fury, which Wolff apparently sourced through a blend of both on- and off-the-record, semi-formal White House access. So much of what is actually in the book is wild, yet seemingly plausible, yet impossible to verify, that it’s no wonder that the book has reportedly been flying off shelves.

In essence, the concept of the “Gorilla Channel” is one of those quintessentially meta-memes tied to current discourse around politics and reality creation, one that playfully calls out uneasy aspects of society — in this case, the relationship between the president, reality TV, and the dumbing down of American culture.

And actually, that might give the meme a lot more gravitas than its creator surely ever intended — which would make it a ... Milkshake Duck?