Advanced Micro Devices is launching its code-named Kaveri processors today, which represent one of the biggest technical advances that the company has made in some time. Kaveri chips are meant for games and other high-performance applications.

AMD

Kaveri has 2.4 billion transistors.

The new chips show that AMD is moving in a very different direction from Intel, which at last week’s 2014 International CES put a lot of emphasis on “perceptual computing,” or using gestures and other new kinds of interfaces to control computers. Instead of interfaces, AMD is focusing on powerful graphics capabilities. AMD says Kaveri has 2.4 billion transistors (the basic building blocks of computer electronics), and 47 percent of them are aimed at better, high-end graphics.

Although the code name is Kaveri, the new chips will officially be called the A-Series Accelerated Processing Units (APUs). Like most AMD processors, they combine both graphics and central processing unit functions on the same chip. AMD’s chips will include up to four CPUs and eight graphics processing units (GPUs) on a single piece of silicon.

Nine out 10 PCs are now shipping with CPUs and GPUs on the same chip, according to Jon Peddie Research.

The Kaveri line is the first series of chips to use a new approach to computing dubbed the Heterogeneous System Architecture (HSA), which makes it easier to get around bottlenecks inside a PC and speed the whole system up.

Kaveri chips also include Graphics Core Next (GCN), an architecture designed for next-generation games.

AMD claims that its GPUs are much more powerful than Intel’s. For example, AMD said that its A10-7850K chip is 24 percent faster than the system performance of the higher-priced Intel Core i5-4670K chip. It says its graphics performance is 87 percent better than Intel’s, and its compute performance is 63 percent better than Intel’s.

AMD says the new chips will also use Mantle, an applications programming interface that makes it easier for developers to write high-performance games for AMD chips — it’s kind of like AMD’s own version of Microsoft’s DirectX technology. The chips will also have AMD TrueAudio technology, a 32-channel surround audio technology. The A-series chips will support screen resolutions up to 4K, or UltraHD, which puts four times as many pixels on a screen as 1080p high-definition TV.

AMD

AMD Kaveri benchmarks

“AMD maintains our technology leadership with the 2014 AMD A-Series APUs, a revolutionary next generation APU that marks a new era of computing,” said Bernd Lienhard, corporate vice president and general manager of the client business unit at AMD. “With world-class graphics and compute technology on a single chip, the AMD A-Series APU is an effective and efficient solution for our customers and enable industry-leading computing experiences.”

HSA is pretty arcane technical material for consumers, but if it takes off, AMD says it will lead to faster and more power-efficient personal computers, tablets, smartphones and cloud servers. It goes hand-in-hand with hUMA, a new way for processors to access the memory inside an Accelerated Processing Unit, or a single chip that combines both a microprocessor and graphics.

The problem is that it isn’t easy for programmers to harness the power of the GPU, or graphics processing unit, inside an APU. The HSA has been designed to fix this problem, making graphics an equal partner with the CPU (central processing unit) and other processors, such as a digital signal processor, inside a computing system.

All of these functions used to be part of separate chips. But now they can be packaged inside the same system-on-chip, or SoC, on the same piece of silicon. The three different kinds of processors access data in different ways, but AMD wants to change and simplify that.

AMD

AMD APUs target a lot of applications.

GPUs can be used for non-graphics computing tasks, but it often takes too long to route requests for data through a CPU. Most developers don’t want to deal with the difficulty of optimizing their code for this kind of work. But a new technique, dubbed “heterogenous queuing,” allows applications to directly communicate with the GPU, treating it as an equal partner along side a CPU when it comes to accessing data quickly. That means an application won’t have to wait for the CPU when what it really needs to is to access the GPU.

With HSA and heterogenous queuing, the GPU doesn’t have to wait for the CPU to feed it data. It can spawn its own tasks on its own.

Nathan Brookwood, an analyst at Insight 64, calls this change the “same kind of conceptual breakthrough that the introduction of the virtual memory wrought in the 1970s,” when engineers figured out a better way to manage memory in a computer.

AMD also said that Mantle will make it easy for developers to access new features in graphics chips. It allows developers to write games “closer to the metal,” getting rid of some of the overhead associated with running a PC and letting them get more access to the hardware’s real firepower.

In a demo called Star Swarm, Oxide Games created a Mantle-based science fiction scene with a gigantic space battle involving thousands of spaceships.

Patrick Moorhead, analyst at Moor Insights & Strategy, said, “Kaveri is the most interesting chip AMD has launched in years, and I really like what I have seen so far with third-party benchmarks on next generation workloads. It really is the culmination of the seven years since AMD acquired ATI.”

He added, “Kaveri’s market success will be directly proportional to the speed at which [it] can enable more and more software to become HSA-aware, where it can much more easily tap into the gigaflops of the GPU’s performance. AMD now needs either a Google or Microsoft to commit to optimizing their operating system for HSA to seal the deal, as it will make software that much easier to write.”

The new A-Series chips will range in price from $119 to $173, while the power consumption will range from 45 watts to 95 watts. CPU frequency ranges from 3.1 gigahertz to 4.0 gigahertz. The A-Series APUs are available today.

AMD

AMD HSA speeds graphics and CPU processing.

Value is created by doing.

It’s easy to forget this.  A lot of stuff feels like work—commenting on HN, tweeting, reading about other companies’ funding rounds, grabbing coffee, etc [1]—is not actually work.  (If you count that as work, think really hard about the value you’re creating in your job.)  These activities can be worthwhile in small doses—it’s important to network and meet interesting people to stay in the flow of ideas—but they are not by themselves how new wealth gets created.

Value gets created when a company does things like build widgets and sell them to customers.  As a rough guideline, it’s good to stay in roles where you’re close to the doing.

Of course you have to do the right things.  Writing software no one wants does not create value—that’s called a class project.  So it’s critical to figure out the right thing to work on, and strategy is far more valuable than a lot of pivot-happy companies would have you believe.  But strategy alone has no value—value gets captured by execution.

It’s easier to sit around and talk about building a startup than it is to actually start a startup.  And it’s fun to talk about.  But over time, the difference between fun and fulfilling becomes clear.  Doing things is really hard—it’s why, for example, you can generally tell people what you’re working on without NDAs, and most patents never matter.  The value, and the difficulty, comes from execution.

There are good tricks for keeping yourself honest here.  When I was running a company, I used to make a list of everything I got done at the end of the day.  It was remarkable how I could feel like I had a really busy day and realize that night I got nothing done.  Similarly, I could have a day that felt only somewhat busy, but accomplish 3 or 4 major things. 

Err on the side of doing too much of the sort of work that matters and blowing off all the rest, or as Machiavelli said:

You build what you measure—if you measure your productivity by the number of meetings you have in a day, you will have a lot of meetings.  If you measure yourself by revenue growth or number of investments closed or something like that, you will probably have fewer meetings.

Another example of not-quite-work is every night in San Francisco, there are dinner parties where people get together and talk about the future.  It’s always fun and usually not very contentious—most people agree we need to go to space, for example.  But at the end of it, everyone goes home and works on something else.

If you believe that going to space is the most important project for humanity, then work on it.  If you can’t figure out to raise hundreds of millions of dollars, go work for SpaceX (joining a great company is a much better plan than starting a mediocre one).  If enterprise software is what you really love, then work on that. [2]

If you’re reading this and feeling unproductive, there’s a silver lining.  You can just close the browser window.  The good news is that it’s easy to course-correct, and it feels great.

[1] I count blogging as a marginal use of time, but the reason I started is because I realized it was important to be good at writing, I was bad at it, and the only way I was going to improve was with lots of practice.  And sometimes I meet really interesting founders because of something I wrote.

[2] This isn’t meant as any sort of relative value judgment; if what you want to do is build an enterprise software company, then you should do that.  The problem comes when what you really want to do is build rockets.  A lot of people feel like they first should do something to make money and then do what they care about (or first work at a company for awhile before starting a company they really want to start).  While you of course should take care of your family before anything else, you should try to work on what you really care about.  You can usually find a way.  The danger is that life is short and you only get to work on a small number of companies over the course of a career—it’s worth trying to make them count.

WePay has outgrown its roots.

Originally designed to help friends collect money from each other online, the payments startup is shutting down its direct-to-consumer offering. It’s now focused squarely on its payments API, which powers online payments and fraud detection for crowdfunding sites, merchants, and small businesses.

Although WePay is much smaller than the eBay-owned Braintree or Stripe, two competing payments companies, it demonstrated strong growth last year, particularly in the crowdfunding market. In October, the company announced it was processing an average 648 percent more crowdfunding volume every month compared to 2012 — or up to $1.5 million daily.

And WePay has raised $15 million to continue growing throughout 2014, the company announced Thursday morning.

The Palo Alto-based company will use the new capital to continue hiring: Clerico expects his 50-strong team to grow to 75 by the end of 2014, with a focus on engineering talent. But its primary use will be international expansion.

“The hardest part of going international for us is learning how to underwrite merchants in all these different markets,” WePay CEO Bill Clerico told VentureBeat. “We’re not only facilitating payment platforms, but taking on all the fraud risk.”

Beyond the language barriers, tax and credit checks vary wildly across countries, and “it requires a lot of work” to adapt, noted Clerico. WePay uses social media data to underwrite some of it, but that requires plenty of research, too. While Yelp has a good reputation data in the U.S., for example, it’s less reliable in some other countries.

WePay has been thinking about the global market for at least nine months and is on the cusp of making some “exciting announcements” regarding international expansion, said Clerico.

Phil Purcell of Continental Investors led the $15 million funding round in WePay. Before heading Continental, Purcell cofounded the Discover Card and served as CEO of Morgan Stanley. He’ll be joining WePay’s board.

“It’s really rare that you get someone who has deep payments expertise but also has great experience in late stage and public investments,” said Clerico.

Other investors include Max Levchin, former chief technology officer of PayPal; Maynard Webb, former chief operating officer of eBay; and angel investor Raymond Tonsing. All existing institutional investors — Highland Capital Partners, August Capital, and Ignition Partners — also participated in the round, which brings WePay’s total financing to $35 million.

The National Security Agency has collected almost 200 million text messages a day from across the globe, using them to extract data including location, contact networks and credit card details, according to top-secret documents.

The untargeted collection and storage of SMS messages – including their contacts – is revealed in a joint investigation between the Guardian and the UK’s Channel 4 News based on material provided by NSA whistleblower Edward Snowden.

The documents also reveal the UK spy agency GCHQ has made use of the NSA database to search the metadata of “untargeted and unwarranted” communications belonging to people in the UK.

The NSA program, codenamed Dishfire, collects “pretty much everything it can”, according to GCHQ documents, rather than merely storing the communications of existing surveillance targets.

The NSA has made extensive use of its vast text message database to extract information on people’s travel plans, contact books, financial transactions and more – including of individuals under no suspicion of illegal activity.

An agency presentation from 2011 – subtitled “SMS Text Messages: A Goldmine to Exploit” – reveals the program collected an average of 194 million text messages a day in April of that year. In addition to storing the messages themselves, a further program known as “Prefer” conducted automated analysis on the untargeted communications.

The Prefer program uses automated text messages such as missed call alerts or texts sent with international roaming charges to extract information, which the agency describes as “content-derived metadata”, and explains that “such gems are not in current metadata stores and would enhance current analytics”.

On average, each day the NSA was able to extract:

• More than 5 million missed-call alerts, for use in contact-chaining analysis (working out someone’s social network from who they contact and when)

• Details of 1.6 million border crossings a day, from network roaming alerts

• More than 110,000 names, from electronic business cards, which also included the ability to extract and save images.

• Over 800,000 financial transactions, either through text-to-text payments or linking credit cards to phone users

The agency was also able to extract geolocation data from more than 76,000 text messages a day, including from “requests by people for route info” and “setting up meetings”. Other travel information was obtained from itinerary texts sent by travel companies, even including cancellations and delays to travel plans.

Communications from US phone numbers, the documents suggest, were removed (or “minimized”) from the database – but those of other countries, including the UK, were retained.

The revelation the NSA is collecting and extracting personal information from hundreds of millions of global text messages a day is likely to intensify international pressure on US president Barack Obama, who on Friday is set to give his response to the report of his NSA review panel.

While US attention has focused on whether the NSA’s controversial phone metadata program will be discontinued, the panel also suggested US spy agencies should pay more consideration to the privacy rights of foreigners, and reconsider spying efforts against allied heads of state and diplomats.

In a statement to the Guardian, a spokeswoman for the NSA said any implication that the agency’s collection was “arbitrary and unconstrained is false”. The agency’s capabilities were directed only against “valid foreign intelligence targets” and were subject to stringent legal safeguards, she said.

The ways in which the UK spy agency GCHQ has made use of the NSA Dishfire database also seems likely to raise questions on the scope of its powers.

While GCHQ is not allowed to search through the content of messages without a warrant – though the contents are stored rather than deleted or “minimized” from the database – the agency’s lawyers decided analysts were able to see who UK phone numbers had been texting, and search for them in the database.

The GCHQ memo sets out in clear terms what the agency’s access to Dishfire allows it to do, before handling how UK communications should be treated. The unique property of Dishfire, it states, is how much untargeted or unselected information it stores.

“In contrast to [most] GCHQ equivalents, DISHFIRE contains a large volume of unselected SMS traffic,” it states (emphasis original). “This makes it particularly useful for the development of new targets, since it is possible to examine the content of messages sent months or even years before the target was known to be of interest.”

It later explains in plain terms how useful this capability can be. Comparing Dishfire favourably to a GCHQ counterpart which only collects against phone numbers that have specifically been targeted, it states “Dishfire collects pretty much everything it can, so you can see SMS from a selector which is not targeted”.

The document also states the database allows for broad, bulk searches of keywords which could result in a high number of hits, rather than just narrow searches against particular phone numbers: “It is also possible to search against the content in bulk (e.g. for a name or home telephone number) if the target’s mobile phone number is not known.”

Analysts are warned to be careful when searching content for terms relating to UK citizens or people currently residing in the UK, as these searches could be successful but would not be legal without a warrant or similar targeting authority.

However, a note from GCHQ’s operational legalities team, dated May 2008, states agents can search Dishfire for “events” data relating to UK numbers – who is contacting who, and when.

“You may run a search of UK numbers in DISHFIRE in order to retrieve only events data,” the note states, before setting out how an analyst can prevent himself seeing the content of messages when he searches – by toggling a single setting on the search tool.

Once this is done, the document continues, “this will now enable you to run a search without displaying the content of the SMS, especially useful for untargeted and unwarranted UK numbers.”

A separate document gives a sense of how large-scale each Dishfire search can be, asking analysts to restrain their searches to no more than 1,800 phone numbers at a time.

The note warns analysts they must be careful to make sure they use the form’s toggle before searching, as otherwise the database will return the content of the UK messages – which would, without a warrant, cause the analyst to “unlawfully be seeing the content of the SMS”.

The note also adds that the NSA automatically removes all “US-related SMS” from the database, so it is not available for searching.

A GCHQ spokesman refused to comment on any particular matters, but said all its intelligence activities were in compliance with UK law and oversight.

But Vodafone, one of the world’s largest mobile phone companies with operations in 25 countries including Britain, greeted the latest revelations with shock. 

“It’s the first we’ve heard about it and naturally we’re shocked and surprised,” the group’s privacy officer and head of legal for privacy, security and content standards told Channel 4 News.

“What you’re describing sounds concerning to us because the regime that we are required to comply with is very clear and we will only disclose information to governments where we are legally compelled to do so, won’t go beyond the law and comply with due process.

“But what you’re describing is something that sounds as if that’s been circumvented. And for us as a business this is anathema because our whole business is founded on protecting privacy as a fundamental imperative.”

He said the company would be challenging the UK government over this. “From our perspective, the law is there to protect our customers and it doesn’t sound as if that is what is necessarily happening.”

The NSA’s access to, and storage of, the content of communications of UK citizens may also be contentious in the light of earlier Guardian revelations that the agency was drafting policies to facilitate spying on the citizens of its allies, including the UK and Australia, which would – if enacted – enable the agency to search its databases for UK citizens without informing GCHQ or UK politicians.

The documents seen by the Guardian were from an internal Wikipedia-style guide to the NSA program provided for GCHQ analysts, and noted the Dishfire program was “operational” at the time the site was accessed, in 2012.

The documents do not, however, state whether any rules were subsequently changed, or give estimates of how many UK text messages are collected or stored in the Dishfire system, or from where they are being intercepted.

In the statement, the NSA spokeswoman said: “As we have previously stated, the implication that NSA's collection is arbitrary and unconstrained is false.

“NSA's activities are focused and specifically deployed against – and only against – valid foreign intelligence targets in response to intelligence requirements.

“Dishfire is a system that processes and stores lawfully collected SMS data. Because some SMS data of US persons may at times be incidentally collected in NSA’s lawful foreign intelligence mission, privacy protections for US persons exist across the entire process concerning the use, handling, retention, and dissemination of SMS data in Dishfire.

“In addition, NSA actively works to remove extraneous data, to include that of innocent foreign citizens, as early as possible in the process.”

The agency draws a distinction between the bulk collection of communications and the use of that data to monitor or find specific targets.

A spokesman for GCHQ refused to respond to any specific queries regarding Dishfire, but said the agency complied with UK law and regulators.

“It is a longstanding policy that we do not comment on intelligence matters,” he said. “Furthermore, all of GCHQ's work is carried out in accordance with a strict legal and policy framework which ensures that our activities are authorised, necessary and proportionate, and that there is rigorous oversight, including from the Secretary of State, the Interception and Intelligence Services Commissioners and the Parliamentary Intelligence and Security Committee.”

GCHQ also directed the Guardian towards a statement made to the House of Commons in June 2013 by foreign secretary William Hague, in response to revelations of the agency’s use of the Prism program.

“Any data obtained by us from the US involving UK nationals is subject to proper UK statutory controls and safeguards, including the relevant sections of the Intelligence Services Act, the Human Rights Act and the Regulation of Investigatory Powers Act,” Hague told MPs.

Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..

webkit.js

An experimental port of WebKit (Specifically, webcore) to JavaScript aimed at running in both node.js and browsers. This is currently non-functional and is intended for developers and contributors.

Goals

• Produce a renderer in pure JavaScript that supports rendering to WebGL/Canvas contexts.
• Develop frameworks for image/webpage capturing and automated web testing (similar to PhantomJS).
• Develop a framework for prototyping CSS filters, HTML elements and attributes.
• Experimental harness for pure javascript rendering performance.
• Develop a javascript based browser in nodejs (just for fun).

Status

Toolchain

• (BAD) Currently will only compile with Emscripten 1.8.2 on MacOSX in Xcode.

Building

• (GOOD) Currently the latest nightly WebKit builds.

Linking

• (HORRIFIC) There are plenty of linking issues to be addressed; however visibility into this is minimal. Currently the system links but has quite a few unresolved symbols that will cause the renderer to crash.

Tests

• (NON EXISTANT) Tests for javascript<->C++ needs to be developed (non-layout related code)
• (BAD) Unit tests that integrate with WebKit's LayoutTests

Supported Features

• (GOOD) Features that are not currently supported:

  • Accelerated 2D Canvas
  • CSS Image Resolution
  • CSS Image Orientation
  • CSS3 Text
  • Draggable Regions
  • Encrypted Media
  • Font Load Events
  • Input Speech
  • Audio
  • Video
  • Media Streams
  • JavaScript Debugger / Inspector
  • MHTML
  • PDF/PDFKit
  • Quota's
  • Web Workers
  • Web Sockets
  • Shadow DOM
  • Web Timing
  • XSLT
  • Native Widgets (IFRAME, Buttons, Text Boxes, etc.)
  • Any Resource Loaders
  • Font Rendering

Frameworks

• (NON EXISTANT) Frameworks to easily perform common tasks with the renderer under various contexts.

Documentation

• (NON EXISTANT) Lots and lots of documentation, currently this is it.

Building

Requirements

• MacOS X Lion with Xcode 4+
• Emscripten 1.8.2+
• At least 16GB of free space (seriously)
• At least 4GB of RAM

Building webkit.js step-by-step

• Clone the repo.
• Go to WebKitJS/tools and in a terminal run sh cp -pa ./WebKitJS/tools/EmscriptenXcode.xcplugin /Applications/Xcode.app/Contents/PlugIns/EmscriptenXcode.plugin vim /Applications/Xcode.app/Contents/PlugIns/EmscriptenXcode.xcplugin/Contents/Resources/GCC\ 4.5.xcspec
• Modify line 35 and set ExecPath to the path of em++ included with Emscripten.
• Then run:sh vim WebKit/Source/WebCore/Configurations/Base.xcconfig
• Replace "EMSCRIPTEN_SYSTEM" with the path to the system headers for emscripten.
• Open WebKit.xcworkspace in Xcode
• Change the Schema to "WebcoreJS" and make sure you build in Release (some systems Normal), not Debug. Hit Play and get some coffee or go do some chores.

• Your linking will most likely fail. If so, just run the terminal command:

  em++ -r -isysroot /Path/To/Emscripten/1.8.2/system /Path/To/Your/WebKitBuild/*.o -std=c++11 -s FULL_ES2=1 -O2 -stdlib=libc++ -s LINKABLE=1 -o /Path/To/Your/WebKitBuild/webkit.js

• You can also create individual js files for each class in WebKit to ease debugging. Run:

  find . -name "*.o"| xargs -I {} em++ -isysroot /Path/To/Your/Emscripten/1.8.2/system {} -std=c++11 -s FULL_ES2=1 -O2 -stdlib=libc++ -s LINKABLE=1 -s SIDE_MODULE=1 -o /Some/Folder/For/Output/{}.js

Contributing

There's so much to be done any help is appreciated, at the moment I have a brutal wrapper/harness that can render DIV's with various colors to a WebGL surface in Chrome 32. It's not impressive but its a proof of concept.

Getting around the code

• /WebKit/ This is a modified version of Apple's official repo.
• /WebKit/Source/WebCore This is where 90% of the work is done.
• /WebKit/Source/WebCore/bindings/scripts This is an important folder where WebKit autogenerates bindings
• /WebKit/Source/WTF/ is a cross-platform library for common tasks such as HashMaps, etc.
• /WebKit/Source/WTF/PlatformJS.h these are C++ pre-process settings for PLATFORM(JS)

• /WebKit/Source/WebCore/Configurations/ these are important compile-time configurations for WebCore

• /WebKitJS/ When compiled the output of WebKit is placed in WebKitJS/webkit.js

• /WebKitJS/tools/ Any helpful tools i've come across (only one for now...)
• /WebKitJS/tools/cppfilter.js This demangles C++ symbols contained in emscripten.js
• /WebKitJS/tools/EmscriptenXcode.plugin This is a Xcode plugin, and a temporary hack for using emscripten

It's important to know

• The code within the WebKit folder is pulled from upstream, be careful not to move any files, remove any files or heavily refactor any source file as it will cause headaches when merging.

• Place a .gitignore on ./WebKit/WebKitBuild/ so you do not accidently commit build files.

• Enabling/disabling settings within the Configurations folder in WebCore will have a lot of consequences, most of the disabled features are disabled because there's no possible work around for including the platform specific code (it needs to be created in JS from scratch)
• A good amount of the bindings and code within the WebCore is auto generated from scripts, be careful when you have build errors to make sure you're not modifying a "Derived Source" otherwise you'll find your changes will be just over-written the next time the derived sources runs.
• The current webkit.js in WebKitJS folder was compiled exposing its symbols, this results in a heavy file size (current 44MB - 1/15/14). This can come down considerably once a framework/API is developed, tests are created and optimizations can become a priority.
• Do not modify code within ./WebKitJS/webkit.js or ./WebKitJS/debug/ these files are over-written when WebKit is built, so its somewhat pointless unless you're testing.

What's Desperately Needed

• A build toolchain similar to GYP/gconfig. QtWebkit has one already, possibly re-map that.
• Create "Debug" and "Release" modes that allow for easier debugging. In addition creating anything that helps debug and spot problems easier.
• Scripts to auto-generate code with Emscripten JS Bindings (e.g., IDL generation, and some other bindings/scripts tasks)
• Integration of WTF library into WebCore
• Closer examination of optimization/best practices/guidance on Emscripten.
• Closer examination of optimization/best practices/guidance on compiling WebCore/renderer.
• Removal of "oddity" code (e.g., no mans land code, existing dead code, platform specific code)
• Start smaller with GYP and only develop one pass layout system from CSS/HTML/DOM code with minimal features and build up.
• Take each file one by one in ./webkitjs/debug/ and port?...
• Conversation, topics, discussions on best practices, methods and use cases
• Dependency and/or symbol graph that rebuilds automatically after a compile (expressed as a HTML doc?) The core reason for this is to visualize dependencies between classes, unresolved symbols still to be developed, and spot key integration points. This can be done by regex over the existing ./webkitjs/debug for symbols and building a D3 graph to show the symbols dependency possibly? Is there already key software that does this? Can emscripten/llvm spit this out?
• Identify what key import symbols may require significant retooling.
• Integrate libxml.js (rather than depending on browser pass through decoding to a buffer)
• Integrate libxslt.js (currently unsupported)
• Integrate ffmpeg.js ?.... pure javascript video support?..... .
• Integrate libpng.js (rather than depending on browser pass through decoding to a buffer)
• Integrate libjpeg-turbo.js/libjpeg.js (rather than depending on browser pass through decoding to a buffer)
• Integrate zlib (rather than depending on browser pass through decoding to a buffer)
• Use embind/cppfilter.js to automatically generate all the WebCore C++ interfaces (derived from WebCore.exp) directly into javascript, then simply reuse existing webcore demos/examples.

License

BSD License (see http://www.webkit.org/coding/bsd-license.html) Use of this source code is governed by a BSD-style license that can be found in the LICENSE files contained in the root of the respective source code.

© True Interactions 2014

[trevor linton]:mailto:trevor dot linton plus github at gmail dot com

For New Year's Eve 2014, my girlfriend and I went to a dance party where wearable electronics were not only encouraged but also on display from a variety of hobbyists. I decided to use this as an opportunity to combine two of my favorite hobbies: sewing and electronics.

It is my goal to encourage more people to weave wearable electronics into their own clothing. It's the future and we might as well look the part. Plus it's easy to get started and to modify existing code.

The full source code for this dress is available on GitHub.

Hardware

I attached six addressable LED strands from Sparkfun ($20 each) to the lining of Brittany's dress, and then used a Flora module from Adafruit ($25) to control them. I then used a 3 x AAA battery holder from Adafruit ($2).

Setup

I used Adafruit's NeoPixel library to control the LEDs. There were 60 LEDs per 1 meter-long strand. We only needed 40 of the LEDs, but instead of cutting them off, we simply sewed the unused third underneath the strand and cut the software off at 40 LEDs. This way we can repurpose the LED strands when we decide to move them to a new dress.

In order to make the connections between the LED strands and the Flora module, I used 30 AWG wire, which is an extremely thin and light wire. The gauge is 0.01" and is as fine as thread. This allowed me to sew the wire into the fabric. I could have used conductive thread, but this wire wrap has a sheath that prevents it from shorting other wires when they touch. It's also extremely light-weight, so having 18 wires (3 wires per LED strand: power, ground, data) looping around the dress wasn't an issue.

I also want to mention that the code below is hard-coded for six stands. There is a fine line between a hack and a project, and for this, due to my limited time budget, was closer to hack than reusable project. You can easily abstract the code below to account for more or fewer strands, but I was able to ship before midnight on NYE, so I'm considering it a success.

void setup() {
 // To ensure that the first random color in `loop` is never the same.
 randomSeed(analogRead(0));
 led_a.begin();
 led_b.begin();
 led_c.begin();
 led_d.begin();
 led_e.begin();
 led_f.begin();
 clearLEDs(true);
}
void loop() {
 for (int i=0; i<2; i++) {
 hulahoop(randomColor(), random(20,60));
 }
 sparkle(randomColor(), random(30,70));
 raindrops(randomColor(), random(20,60));
 spiral(randomColor(), random(15,30));
}

Above we have the code for setup and loop, the two main Arduino routines. Notice that I am repeating the hula hoop routine, since it's pretty quick and looks good on repeat.

I also want to note that every single routine gets its own random color and random delay. This bit of randomness is something I weave into all of my wearable electronics, since it goes just a bit further than off-the-shelf components and shows that there was some intelligence behind the routine.

By giving a random delay to each routine I am actually changing the speed of the routine. Sometimes the raindrops would fall quickly, sometimes the hula hoop would have a slow fall and rise. It's all part of making mesmerizing patterns.

Hula hoop

For the hula hoop routine, I chose to use cylons at equal positions that move up and down the strand. To make the transition from one LED to the next, I use a cylon, which is a fancy way of saying that the LEDs immediately above and below the active LED are also on, but at a reduced brightness.

In this case the cylon is 5 LEDs wide. 100% brightness for the middle/active LED, 1/18th brightness for the two adjacent LEDs, and 1/36th brightness for the two LEDs further out from there.

So what you see to the left are actually 5 LEDs turned on per-strand, although they get quite dim as you get further from the active LED. You can adjust the dimness of the adjacent LEDs by adjusting the weight parameter.

void hulahoop(unsigned long color, byte wait) {
 // weight determines how much lighter the outer "eye" colors are
 const byte weight = 18; 
 // It'll be easier to decrement each of these colors individually
 // so we'll split them out of the 24-bit color value
 byte red = (color & 0xFF0000) >> 16;
 byte green = (color & 0x00FF00) >> 8;
 byte blue = (color & 0x0000FF);
 // Start at closest LED, and move to the outside
 for (int i=0; i<=LED_COUNT-1; i++) {
 clearLEDs(false);
 led_a.setPixelColor(i, red, green, blue);
 led_b.setPixelColor(i, red, green, blue);
 led_c.setPixelColor(i, red, green, blue);
 led_d.setPixelColor(i, red, green, blue);
 led_e.setPixelColor(i, red, green, blue);
 led_f.setPixelColor(i, red, green, blue);
 // Now set two eyes to each side to get progressively dimmer
 for (int j=1; j<3; j++) {
 byte redWJ = red/(weight*j);
 byte greenWJ = green/(weight*j);
 byte blueWJ = blue/(weight*j);
 if (i-j >= 0) {
 led_a.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
 led_b.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
 led_c.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
 led_d.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
 led_e.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
 led_f.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
 }
 if (i-j <= LED_COUNT) {
 led_a.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
 led_b.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
 led_c.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
 led_d.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
 led_e.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
 led_f.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
 }
 }
 led_a.show();
 led_b.show();
 led_c.show();
 led_d.show();
 led_e.show();
 led_f.show();
 delay(wait);
 }
 // Now we go back to where we came. Do the same thing.
 for (int i=LED_COUNT-2; i>=1; i--) {
 clearLEDs(false);
 led_a.setPixelColor(i, red, green, blue);
 led_b.setPixelColor(i, red, green, blue);
 led_c.setPixelColor(i, red, green, blue);
 led_d.setPixelColor(i, red, green, blue);
 led_e.setPixelColor(i, red, green, blue);
 led_f.setPixelColor(i, red, green, blue);
 // Now set two eyes to each side to get progressively dimmer
 for (int j=1; j<3; j++)
 {
 byte redWJ = red/(weight*j);
 byte greenWJ = green/(weight*j);
 byte blueWJ = blue/(weight*j);
 if (i-j >= 0) {
 led_a.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
 led_b.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
 led_c.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
 led_d.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
 led_e.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
 led_f.setPixelColor(i-j, redWJ, greenWJ, blueWJ);
 }
 if (i-j <= LED_COUNT) {
 led_a.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
 led_b.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
 led_c.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
 led_d.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
 led_e.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
 led_f.setPixelColor(i+j, redWJ, greenWJ, blueWJ);
 }
 }
 led_a.show();
 led_b.show();
 led_c.show();
 led_d.show();
 led_e.show();
 led_f.show();
 delay(wait);
 }
}

Sparkles

This is by far the easiest routine to program yet the one that brought the most attention. It simply flashes a random LED across all of the LED strips.

void sparkle(unsigned long color, uint8_t wait) {
 for (int i=0; i < LED_COUNT * STRIP_COUNT; i++) {
 clearLEDs(true);
 int strip = floor(random(STRIP_COUNT));
 int led = floor(random(LED_COUNT));
 switch (strip) {
 case 0:
 led_a.setPixelColor(led, color);
 led_a.show();
 break;
 case 1:
 led_b.setPixelColor(led, color);
 led_b.show();
 break;
 case 2:
 led_c.setPixelColor(led, color);
 led_c.show();
 break;
 case 3:
 led_d.setPixelColor(led, color);
 led_d.show();
 break;
 case 4:
 led_e.setPixelColor(led, color);
 led_e.show();
 break;
 case 5:
 led_f.setPixelColor(led, color);
 led_f.show();
 break;
 }
 delay(wait);
 }
}

Raindrops

This is by far the most difficult of the routines. This one sends down cylons (5 LEDs, with the center LED being the brightest and the adjacent LEDs becoming decreasingly bright, so as to give the impression of smoother animation).

But you should notice that the next raindrop starts when the previous raindrop is half-way down the dress. In order to make it seamless, at the beginning of the routine I actually start another LED at the half-way mark, referred to in the below code as e_alt. This means that there is no point at which the dress looks spent and is waiting for the routine to start over.

void raindrops(unsigned long color, byte wait) {
 // weight determines how much lighter the outer "eye" colors are
 const byte weight = 18; 
 // It'll be easier to decrement each of these colors individually
 // so we'll split them out of the 24-bit color value
 byte red = (color & 0xFF0000) >> 16;
 byte green = (color & 0x00FF00) >> 8;
 byte blue = (color & 0x0000FF);
 double sludge = 0.5;
 double a_offset = 0;
 double b_offset = 3;
 double c_offset = 1;
 double d_offset = 2;
 double e_offset = 4;
 double f_offset = 5;
 // Start at closest LED, and move to the outside
 for (int i=0; i<LED_COUNT*(STRIP_COUNT-1)*sludge+LED_COUNT*10; i++) {
 clearLEDs(false);
 double n = i % (int)(LED_COUNT*(STRIP_COUNT+1)*sludge-LED_COUNT*sludge);
 double led_count = (double)LED_COUNT;
 bool a_on = (sludge*a_offset*led_count) <= n && 
 n <= (sludge*a_offset*led_count+led_count);
 bool b_on = (sludge*b_offset*led_count) <= n && 
 n <= (sludge*b_offset*led_count+led_count);
 bool c_on = (sludge*c_offset*led_count) <= n && 
 n <= (sludge*c_offset*led_count+led_count);
 bool d_on = (sludge*d_offset*led_count) <= n && 
 n <= (sludge*d_offset*led_count+led_count);
 bool e_on = (sludge*e_offset*led_count) <= n && 
 n <= (sludge*e_offset*led_count+led_count);
 bool e_alt= (sludge*a_offset*led_count) <= n && 
 n <= (sludge*a_offset*led_count+led_count*sludge);
 bool f_on = (sludge*f_offset*led_count) <= n && 
 n <= (sludge*f_offset*led_count+led_count);
 if (!a_on && !b_on && !c_on && !d_on && !e_on && !f_on) {
 clearLEDs(true);
 break;
 }
 int a = n-a_offset*LED_COUNT*sludge;
 int b = n-b_offset*LED_COUNT*sludge;
 int c = n-c_offset*LED_COUNT*sludge;
 int d = n-d_offset*LED_COUNT*sludge;
 int e = n-e_offset*LED_COUNT*sludge;
 if (e_alt) {
 e = a+(LED_COUNT/2);
 }
 int f = n-f_offset*LED_COUNT*sludge;
 if (a_on) led_a.setPixelColor(a, red, green, blue);
 if (b_on) led_b.setPixelColor(b, red, green, blue);
 if (c_on) led_c.setPixelColor(c, red, green, blue);
 if (d_on) led_d.setPixelColor(d, red, green, blue);
 if (e_on || e_alt) led_e.setPixelColor(e, red, green, blue);
 if (f_on) led_f.setPixelColor(f, red, green, blue);
 // Now set two eyes to each side to get progressively dimmer
 for (int j=1; j<3; j++) {
 byte redWJ = red/(weight*j);
 byte greenWJ = green/(weight*j);
 byte blueWJ = blue/(weight*j);
 if (a-j >= 0 && a_on) 
 led_a.setPixelColor(a-j, redWJ, greenWJ, blueWJ);
 if (b-j >= 0 && b_on) 
 led_b.setPixelColor(b-j, redWJ, greenWJ, blueWJ);
 if (c-j >= 0 && c_on) 
 led_c.setPixelColor(c-j, redWJ, greenWJ, blueWJ);
 if (d-j >= 0 && d_on) 
 led_d.setPixelColor(d-j, redWJ, greenWJ, blueWJ);
 if (e-j >= 0 && e_on) 
 led_e.setPixelColor(e-j, redWJ, greenWJ, blueWJ);
 if (f-j >= 0 && f_on) 
 led_f.setPixelColor(f-j, redWJ, greenWJ, blueWJ);
 if (a-j <= LED_COUNT && a_on) 
 led_a.setPixelColor(a+j, redWJ, greenWJ, blueWJ);
 if (b-j <= LED_COUNT && b_on) 
 led_b.setPixelColor(b+j, redWJ, greenWJ, blueWJ);
 if (c-j <= LED_COUNT && c_on) 
 led_c.setPixelColor(c+j, redWJ, greenWJ, blueWJ);
 if (d-j <= LED_COUNT && d_on) 
 led_d.setPixelColor(d+j, redWJ, greenWJ, blueWJ);
 if (e-j <= LED_COUNT && e_on) 
 led_e.setPixelColor(e+j, redWJ, greenWJ, blueWJ);
 if (f-j <= LED_COUNT && f_on) 
 led_f.setPixelColor(f+j, redWJ, greenWJ, blueWJ);
 }
 led_a.show();
 led_b.show();
 led_c.show();
 led_d.show();
 led_e.show();
 led_f.show();
 delay(wait);
 }
}

Spiral

This routine is better in theory than in practice. The idea is to have a quick succession of LEDs light up in a spiral pattern. This would work a bit better with more LED strands wrapped around the dress.

In this case, I'm simply looping through the strands and lighting up successive LEDs. But the nice thing about this routine is that it has a dramatic crescendo to the top, at which point the hula hoop routine begins and it looks like the action started at the bottom and quickly worked its way up to the top, only to smoothly fall back down. It's a mesmerizing effect.

void spiral(unsigned long color, byte wait) {
 const byte weight = 18; 
 byte red = (color & 0xFF0000) >> 16;
 byte green = (color & 0x00FF00) >> 8;
 byte blue = (color & 0x0000FF);
 for (int level=LED_COUNT-1; level >= 0; level--) {
 for (int strip=0; strip < STRIP_COUNT; strip++) {
 clearLEDs(false);
 switch (strip) {
 case 0:
 led_f.setPixelColor(level, red/weight, green/weight, blue/weight);
 led_a.setPixelColor(level, color);
 led_b.setPixelColor(level, red/weight, green/weight, blue/weight);
 break;
 case 1:
 led_a.setPixelColor(level, red/weight, green/weight, blue/weight);
 led_b.setPixelColor(level, color);
 led_c.setPixelColor(level, red/weight, green/weight, blue/weight);
 break;
 case 2:
 led_b.setPixelColor(level, red/weight, green/weight, blue/weight);
 led_c.setPixelColor(level, color);
 led_d.setPixelColor(level, red/weight, green/weight, blue/weight);
 break;
 case 3:
 led_c.setPixelColor(level, red/weight, green/weight, blue/weight);
 led_d.setPixelColor(level, color);
 led_e.setPixelColor(level, red/weight, green/weight, blue/weight);
 break;
 case 4:
 led_d.setPixelColor(level, red/weight, green/weight, blue/weight);
 led_e.setPixelColor(level, color);
 led_f.setPixelColor(level, red/weight, green/weight, blue/weight);
 break;
 case 5:
 led_e.setPixelColor(level, red/weight, green/weight, blue/weight);
 led_f.setPixelColor(level, color);
 led_a.setPixelColor(level, red/weight, green/weight, blue/weight);
 break;
 }
 led_a.show();
 led_b.show();
 led_c.show();
 led_d.show();
 led_e.show();
 led_f.show();
 delay(wait);
 }
 } 
}

Random Colors

Since randomness is the spice that gives this dress its mesmerizing qualities, it's important to have a good list of colors to use.

unsigned long COLORS[] = {
 NAVY, DARKBLUE, MEDIUMBLUE, BLUE, DARKGREEN, GREEN, TEAL, DARKCYAN, 
 DEEPSKYBLUE, DARKTURQUOISE, MEDIUMSPRINGGREEN, LIME, SPRINGGREEN, 
 AQUA, CYAN, MIDNIGHTBLUE, DODGERBLUE, LIGHTSEAGREEN, FORESTGREEN, 
 SEAGREEN, DARKSLATEGRAY, LIMEGREEN, MEDIUMSEAGREEN, TURQUOISE, 
 ROYALBLUE, STEELBLUE, DARKSLATEBLUE, MEDIUMTURQUOISE, INDIGO, 
 DARKOLIVEGREEN, CADETBLUE, CORNFLOWERBLUE, MEDIUMAQUAMARINE, DIMGRAY, 
 SLATEBLUE, OLIVEDRAB, SLATEGRAY, LIGHTSLATEGRAY, MEDIUMSLATEBLUE, 
 LAWNGREEN, CHARTREUSE, AQUAMARINE, MAROON, PURPLE, OLIVE, GRAY, 
 SKYBLUE, LIGHTSKYBLUE, BLUEVIOLET, DARKRED, DARKMAGENTA, SADDLEBROWN, 
 DARKSEAGREEN, LIGHTGREEN, MEDIUMPURPLE, DARKVIOLET, PALEGREEN, 
 DARKORCHID, YELLOWGREEN, SIENNA, BROWN, DARKGRAY, LIGHTBLUE, 
 GREENYELLOW, PALETURQUOISE, LIGHTSTEELBLUE, POWDERBLUE, FIREBRICK, 
 DARKGOLDENROD, MEDIUMORCHID, ROSYBROWN, DARKKHAKI, SILVER, 
 MEDIUMVIOLETRED, INDIANRED, PERU, CHOCOLATE, TAN, LIGHTGRAY, 
 THISTLE, ORCHID, GOLDENROD, PALEVIOLETRED, CRIMSON, GAINSBORO, PLUM, 
 BURLYWOOD, LIGHTCYAN, LAVENDER, DARKSALMON, VIOLET, PALEGOLDENROD, 
 LIGHTCORAL, KHAKI, ALICEBLUE, HONEYDEW, AZURE, SANDYBROWN, WHEAT, 
 BEIGE, WHITESMOKE, MINTCREAM, GHOSTWHITE, SALMON, ANTIQUEWHITE, 
 LINEN, LIGHTGOLDENRODYELLOW, OLDLACE, RED, FUCHSIA, MAGENTA, 
 DEEPPINK, ORANGERED, TOMATO, HOTPINK, CORAL, DARKORANGE, LIGHTSALMON, 
 ORANGE, LIGHTPINK, PINK, GOLD, PEACHPUFF, NAVAJOWHITE, MOCCASIN, 
 BISQUE, MISTYROSE, BLANCHEDALMOND, PAPAYAWHIP, LAVENDERBLUSH, SEASHELL, 
 CORNSILK, LEMONCHIFFON, FLORALWHITE, SNOW, YELLOW, LIGHTYELLOW, IVORY
};
unsigned long randomColor() {
 return COLORS[random(sizeof(COLORS)/sizeof(unsigned long))];
}

Dancing to 2014

And what good is a beautiful light-up dress without a well lit dance partner? Here I am decked out in blue EL wire. I spent the better part of three hours sewing this wire into the edges of one of my jackets. But while hand-sewing can take half a day, the result is a great fit and a capable match for Brittany's dress.

The full source code for this dress is available on GitHub.

INNOVATION, the elixir of progress, has always cost people their jobs. In the Industrial Revolution artisan weavers were swept aside by the mechanical loom. Over the past 30 years the digital revolution has displaced many of the mid-skill jobs that underpinned 20th-century middle-class life. Typists, ticket agents, bank tellers and many production-line jobs have been dispensed with, just as the weavers were.

For those, including this newspaper, who believe that technological progress has made the world a better place, such churn is a natural part of rising prosperity. Although innovation kills some jobs, it creates new and better ones, as a more productive society becomes richer and its wealthier inhabitants demand more goods and services. A hundred years ago one in three American workers was employed on a farm. Today less than 2% of them produce far more food. The millions freed from the land were not consigned to joblessness, but found better-paid work as the economy grew more sophisticated. Today the pool of secretaries has shrunk, but there are ever more computer programmers and web designers.

Remember Ironbridge

Optimism remains the right starting-point, but for workers the dislocating effects of technology may make themselves evident faster than its benefits (see article). Even if new jobs and wonderful products emerge, in the short term income gaps will widen, causing huge social dislocation and perhaps even changing politics. Technology’s impact will feel like a tornado, hitting the rich world first, but eventually sweeping through poorer countries too. No government is prepared for it.

Why be worried? It is partly just a matter of history repeating itself. In the early part of the Industrial Revolution the rewards of increasing productivity went disproportionately to capital; later on, labour reaped most of the benefits. The pattern today is similar. The prosperity unleashed by the digital revolution has gone overwhelmingly to the owners of capital and the highest-skilled workers. Over the past three decades, labour’s share of output has shrunk globally from 64% to 59%. Meanwhile, the share of income going to the top 1% in America has risen from around 9% in the 1970s to 22% today. Unemployment is at alarming levels in much of the rich world, and not just for cyclical reasons. In 2000, 65% of working-age Americans were in work; since then the proportion has fallen, during good years as well as bad, to the current level of 59%.

Worse, it seems likely that this wave of technological disruption to the job market has only just started. From driverless cars to clever household gadgets (see article), innovations that already exist could destroy swathes of jobs that have hitherto been untouched. The public sector is one obvious target: it has proved singularly resistant to tech-driven reinvention. But the step change in what computers can do will have a powerful effect on middle-class jobs in the private sector too.

Until now the jobs most vulnerable to machines were those that involved routine, repetitive tasks. But thanks to the exponential rise in processing power and the ubiquity of digitised information (“big data”), computers are increasingly able to perform complicated tasks more cheaply and effectively than people. Clever industrial robots can quickly “learn” a set of human actions. Services may be even more vulnerable. Computers can already detect intruders in a closed-circuit camera picture more reliably than a human can. By comparing reams of financial or biometric data, they can often diagnose fraud or illness more accurately than any number of accountants or doctors. One recent study by academics at Oxford University suggests that 47% of today’s jobs could be automated in the next two decades.

At the same time, the digital revolution is transforming the process of innovation itself, as our special report explains. Thanks to off-the-shelf code from the internet and platforms that host services (such as Amazon’s cloud computing), provide distribution (Apple’s app store) and offer marketing (Facebook), the number of digital startups has exploded. Just as computer-games designers invented a product that humanity never knew it needed but now cannot do without, so these firms will no doubt dream up new goods and services to employ millions. But for now they are singularly light on workers. When Instagram, a popular photo-sharing site, was sold to Facebook for about $1 billion in 2012, it had 30m customers and employed 13 people. Kodak, which filed for bankruptcy a few months earlier, employed 145,000 people in its heyday.

The problem is one of timing as much as anything. Google now employs 46,000 people. But it takes years for new industries to grow, whereas the disruption a startup causes to incumbents is felt sooner. Airbnb may turn homeowners with spare rooms into entrepreneurs, but it poses a direct threat to the lower end of the hotel business—a massive employer.

No time to be timid

If this analysis is halfway correct, the social effects will be huge. Many of the jobs most at risk are lower down the ladder (logistics, haulage), whereas the skills that are least vulnerable to automation (creativity, managerial expertise) tend to be higher up, so median wages are likely to remain stagnant for some time and income gaps are likely to widen.

Anger about rising inequality is bound to grow, but politicians will find it hard to address the problem. Shunning progress would be as futile now as the Luddites’ protests against mechanised looms were in the 1810s, because any country that tried to stop would be left behind by competitors eager to embrace new technology. The freedom to raise taxes on the rich to punitive levels will be similarly constrained by the mobility of capital and highly skilled labour.

The main way in which governments can help their people through this dislocation is through education systems. One of the reasons for the improvement in workers’ fortunes in the latter part of the Industrial Revolution was because schools were built to educate them—a dramatic change at the time. Now those schools themselves need to be changed, to foster the creativity that humans will need to set them apart from computers. There should be less rote-learning and more critical thinking. Technology itself will help, whether through MOOCs (massive open online courses) or even video games that simulate the skills needed for work.

The definition of “a state education” may also change. Far more money should be spent on pre-schooling, since the cognitive abilities and social skills that children learn in their first few years define much of their future potential. And adults will need continuous education. State education may well involve a year of study to be taken later in life, perhaps in stages.

Yet however well people are taught, their abilities will remain unequal, and in a world which is increasingly polarised economically, many will find their job prospects dimmed and wages squeezed. The best way of helping them is not, as many on the left seem to think, to push up minimum wages. Jacking up the floor too far would accelerate the shift from human workers to computers. Better to top up low wages with public money so that anyone who works has a reasonable income, through a bold expansion of the tax credits that countries such as America and Britain use.

Innovation has brought great benefits to humanity. Nobody in their right mind would want to return to the world of handloom weavers. But the benefits of technological progress are unevenly distributed, especially in the early stages of each new wave, and it is up to governments to spread them. In the 19th century it took the threat of revolution to bring about progressive reforms. Today’s governments would do well to start making the changes needed before their people get angry.

Why I think real estate tech is one of the most attractive spaces:

1. We have EASIER problems to solve.

People are still doing things with pen and paper or impossible to manage excel solutions. online and mobile is a huge win for operators and they have mostly the same needs. there are very few TECHNICAL challenges in this space — development is essentially applying a known solution to a new problem space.

2. The bar for excellence is very low.

Just google for the real estate solution to any problem. The highest hits are just old companies that move very slowly. If any of their websites showed up on Hacker News, people would shred them for design and “looking sooooo web 1.0″. But they’re killing it because there isn’t an alternative that customers know about.

Consider this: the iPhone has only been around since 2007 in ANY capacity, and in the last 3 years, consumer facing apps have completely changed. These companies haven’t and are unlikely to. User interface and usability are still new ideas outside of Silicon Valley.

Beating the incumbents at product is surprisingly easy.

3. The market is huge and terribly underserved by tech.

Each of:

• apartment discovery (like craigslist and other listing sites)
• rental applications and tenant screening
• rent payments
• rental management software
• commercial
• residential sales process management

is worth on the order of a billion dollars a year in revenue.

Traction in one vertical facilitates traction in adjacent verticals. the prize is huge. The failure case is a lifestyle business.  There is a known, straightforward path to linear growth with very low risk of failure.

4. The prospective customers already all agree that they need better tech solutions.

Every landlord in america knows that in the coming years they’ll be switching to online applications and online rent payment. there’s no question of IF. Only WHEN. The challenge is that its hard to convince people to move TODAY.  The market is slowly shifting now, but there will be a cusp where the tides turn and people start switching en masse.

5. It’s relatively easy to reach players in the space.

I at least have the *option* of looking them up in the phone book. This is not true for a lot of other software products. “All hobbyist photographers” for example, is not an easy group to find.

*     *     *

Contrast these features to industries where there are relatively FEW dollars, customers need to be convinced that the product is needed at all, there are tons of really smart people working on it.

Instagram and Snapchat:

• arguably have a market that spends zero dollars (claiming total US adspend as their market size is a joke),
• are in a space with WAY more talented peers (sorry vaultware.com, I’m going to have to say I’d rather have an engineer from the photo team at Facebook),
• have problems that are on the bleeding edge of tech so that they have to INVENT new solutions (I will never have to invent a database for my real estate problems, and realtime async stuff isn’t important for me), and
• don’t have an obvious need or solve a clear business problem (how many people are *still* saying “I don’t get the point of Twitter”?)
• it’s not possible to look up their prospective customers in a list (get me an email list of all 13-16 year old teenagers with a Nexus 4).

Real estate has an easier path to positive EV outcomes with a massive upside tail. That’s my flavor.

»

Problems with donating to OpenBSD

(1) The donations are being requested after the end of the tax year

Most charitable donations occur in October/November/December for tax reasons. This is true of both deductible and non-deductible donations.

(2) Donations are not tax deductible

This isn't a huge problem, if the OpenBSD Foundation were willing to invoice the company for the amount; then it could still be deducted as a business expense, but then the OpenBSD Foundation would have to claim it as income and pay tax on it. This isn't terrifically onerous for them in any case, as they are not a charity, and thus have to pay tax anyway, unless they can just get someone to pay their power bill directly instead (something they've requested).

Another option would be to have a U.S. OpenBSD non-profit that could then support work by OpenBSD under contract, even if that work were something like "provide nightly builds of OpenBSD binaries in exchange for grant funds". They don't seem interested in/able to utilize, this approach.

(3) Invoicing would not exactly require some measure of editorial control, but...

There would be at least an implied expectation of quid-pro-quo, even if none exactly existed, since an audit of the company that was invoiced could require at least a paper justification for the value obtained in exchange for the invoiced amount. It doesn't have to be a great deal for the company, and it could actually be a completely lopsided deal, but there would need to be a token exchange of goods and/or services for the invoiced amount.

(4) If someone is willing to pay their power, they demand they be a Canadian company

I can understand the ramifications for this coming from a non-Canadian company; OpenBSD needs to understand the ramifications of "any port in a storm". There really aren't that many Canadian technology companies in this sector, compared to the U.S.; the highest percentage of OpenBSD-based products are in fact German.

(5) There are not a large number products based directly on OpenBSD

The companies that do have products based on it are generally not hugely profitable, and the small number that there are are listed here: http://www.openbsd.org/products.html [openbsd.org] which gives you some indication of their market penetration.

(6) The OpenBSD folks don't have the most stellar relationship with the rest of the Open Source community

Without assigning specific blame, this should probably be addressed sooner, rather than later.

--

All in all, it's rather difficult to set up a legal fiction that would let it be advantageous to a business to donate.

It's not that they do not provide valuable software, it's just that most of the value they provide is not in the OpenBSD OS itself, it's in the ancillary projects that are associated with the same people.

In an article recently linked from reddit entitled Tour de Babel you can read (among lots of other nonsense):Heck, people still use Tcl as an embedded interpreter, even though Python is far superior to Tcl in every conceivable way -- except, that is, for the frost thing.

Ok, the whole article is well.. not very valid, but unfortunately while many misconceptions are promptly recognized by the informed reader, this one against Tcl is generally believed at face value. I hope this article will convince people that Tcl is not that bad.

Prologue

In my programming life I have used a lot of languages to write different kind of applications: many free/paywork programs in C, a web CMS in Scheme, a number of networking/web applications in Tcl, a shop management system in Python, and so on. I used to play with a number of other programming languages like Smalltalk, Self, FORTH, Ruby, Joy,... And yet, I have no doubt, that there is no language that is as misunderstood in the programming community as Tcl is.

Tcl is not without faults, but most of its limitations are not hard coded in the language design, they are just the result of the fact that Tcl lost its "father" (John Ousterhout) a number of years ago, and together with him any kind of single-minded strong leadership that was able to take strong decisions. With the right changes it is possible to overcome most of the limitations of Tcl, and at the same time preserve the power of the language. If you don't trust Tcl is remarkably powerful please take the time to read this article first. Maybe you still won't like it afterwards, but hopefully you will respect it, and you will certainly have strong arguments against the Tcl is a toy language misconception that's even more petty thanLisp has too many parenthesis.

Before we begin, I'll spend some time explaining how Tcl works. Like the best languages in the world, Tcl has a few concepts that, combined together, allow for programming freedom and expressiveness.

After this short introduction to Tcl, you'll see how in Tcl things very similar to Lisp macros just happen using normal procedures (in a much more powerful way than Ruby blocks), how it's possible to redefine almost every part of the language itself, and how it is possible to mostly ignore types when programming. The Tcl community developed a number of OOP systems, radical language modifications, macro systems, and many other interesting things, just writing Tcl programs. If you like programmable programming languages I bet you'll at least look on it with interest.

Tcl in five minutes

Concept 1: Programs are composed of commands

The first idea of the Tcl language is: commands. Programs are commands, one after the other. For example to set the variable 'a' to 5 and print its value you write two commands:

set a 5
puts $a

Commands are space separated words. A command ends with a newline or with a ; character.Everything is a command in Tcl - as you can see there is no assignment operator. To set a variable you need a command, the set command, that sets the variable specified as the first argument to the value specified as the second argument.

Almost every Tcl command returns a value, For example the set command returns the value assigned to the variable. If theset command is called with just one argument (the variable name), the current value of the variable is returned.

Concept 2: Command substitution

The second idea is command substitution. In a command some arguments may appear between [ and ] braces. If so the argument is substituted with the return value of the code included inside the braces. For example:

set a 5
puts [set a]

The first argument of the second command, [set a], will be substituted with the return value of "set a" (that's 5). After the substitution step the command will be converted from:

puts [set a]

to

puts 5

And, at that point, it will be executed.

Concept 3: Variable substitution

Always using the set command for variable substitution would be too verbose, so even if not strictly needed, variable substitution was introduced at some time during the early development of Tcl. If a variable name is preceded by the $ character it is substituted with its value. So instead of

puts [set a]

it's possible to write

puts $a

Concept 4: Grouping

If commands are space separated words, how to deal with the need for arguments that may contain spaces? For example:

puts Hello World

is an incorrect program as Hello and World are two different arguments. This problem is solved by grouping. Text inside "" is considered a single argument, so the right program is:

puts "Hello World"

Commands and variables substitution work inside this kind of grouping, For example I can write:

set a 5
set b foobar
puts "Hello $a World [string length $b]"

And the result will be "Hello 5 World 6". Also, escapes like \t, \n will do what you think. There is, however, another kind of grouping where every kind of special character is just considered verbatim without any kind of substitution step. Everything between { and } is seen by Tcl as a unique argument where no substitutions are performed. So:

set a 5
puts {Hello $a World}

Will print Hello $a World.

Concept 1 again: Everything is a command

Concept 1 was: programs are composed of commands. Actually it is much more true than you may think. For example in the program:

set a 5
if $a {
 puts Hello!
}

if is a command, with two arguments. The first is the value of the variable a substituted, the second is the string { ... puts Hello! ... }. The if command uses a special version of Eval that we'll see in a moment to run the script passed as the second argument, and returns the result. Of course, you can write your version of if or any other control structure if you want. You may even redefine if itself and add some feature to it!

Concept 5: Everything is a string - no types

The following program works and does what you think:

set a pu
set b ts
$a$b "Hello World"

Yes, in Tcl everything happens at runtime and is dynamic: it's the ultimate late binding programming language, and there are no types. The command name is not a special type but just a string. Numbers are also just strings, so is Tcl code, a string (remember we passed a string to the if command as second argument?). In Tcl what a string represents is up to the command that's manipulating it. the string "5" will be seen as a string of characters by the "string length 5" command, and as a boolean value by "if $a ..." command. Of course commands check that values have a suitable form, If I try to add "foo" to "bar" Tcl will produce an exception because it can't parse "foo" nor "bar" as numbers. This kind of checks in Tcl are very strict, so you'll not get the PHP-alike effect of silent absurd type conversions. The type conversion only happens if the string makes sense interpreted as the thing the command needs as arguments.

So Tcl is so dynamic, but guess what? It is more or less as fast as current Ruby implementations. There is a trick in the implementation of Tcl: objects (not in the OOP sense, but C structs representing Tcl values) cache the native value of the last use of a given string. If a Tcl value is always used as a number the C struct representing it will contain an integer inside, and as long as the next commands continue to use it as an integer, the string representation of the object is not touched at all. It's a bit more complex than this, but the result is that the programmer doesn't need to think about types, and programs still work as fast as other dynamic programming languages where types are more explicit.

Concept 6: Tcl lists

One of the more interesting types (or better.. string formats) Tcl uses is lists. Lists are mostly the central structure of a Tcl program: a Tcl list is always a valid Tcl command! (and both are just strings, in the end). In the simplest form lists are like commands: space separated words. For example the string "a b foo bar" is a list with four elements. There are commands to take a range of elements from a list, to add elements, and so on. Of course, lists may have elements containing spaces, so in order to create well formatted lists the list command is used. Example:

set l [list a b foo "hello world"]
puts [llength $l]

llength returns the length of the list, so the above program will print 4 as output. lindex will instead return the element at the specified position, so "lindex $l 2" will return "foo", and so on. Like in Lisp, in Tcl most programmers use the list type to model as many concepts as possible in programs.

Concept 7: Math in Tcl

I bet most Lisp hackers already noted how Tcl is a prefix-notation language, so you may think like in Lisp, math in Tcl is performed using math operators as commands, like: puts [+ 1 2]. Instead, things work in a different way: in order to make Tcl more friendly there is a command taking infix math expressions as argument and evaluating them. This command is called expr, and math in Tcl works like this:

set a 10
set b 20
puts [expr $a+$b]

Commands like if and while use expr internally in order to evaluate expressions, for instance:

while {$a < $b} {
 puts Hello
}

where the while command takes two arguments - the first string being evaluated as an expression to check if it's true at every iteration, and the second evaluated itself each time. I think it's a design error that math commands are not builtins, I see expr like a cool tool to have where there is complex math to do, but to just add two numbers [+ $a $b] is more convenient. It's worth noting that this has been formally proposed as a change to the language.

Concept 8: Procedures

Naturally, nothing stops a Tcl programmer from writing a procedure (that's a user defined command) in order to use math operators as commands. Like this:

proc + {a b} {
 expr {$a+$b}
}

The proc command is used to create a procedure: its first argument is the procedure name, the second is the list of arguments the procedure takes as input, and finally the last argument is the body of the procedure. Note that the second argument, the arguments list, is a Tcl list. As you can see the return value of the last command in a procedure is used as return value of the procedure (unless the return command is used explicitly). But wait... Everything is a command in Tcl right? So we can create the procedures for +, -, *, ... in a simpler way instead of writing four different procedures:

set operators [list + - * /]
foreach o $operators {
 proc $o {a b} [list expr "\$a $o \$b"]
}

After this we can use [+ 1 2], [/ 10 2] and so on. Of course it's smarter to create these procedures as varargs like Scheme's procedures. In Tcl procedures can have the same names as built in commands, so you can redefine Tcl itself. For example, in order to write a macro system for Tcl I redefined proc. Redefining proc is also useful for writing profilers (Tcl profilers are developed in Tcl itself usually). After a built in command is redefined you can still call it if yourenamed it to some other name prior to overwriting it with proc.

Concept 9: Eval and Uplevel

If you are reading this article you already know what Eval is. The command eval {puts hello} will of course evaluate the code passed as argument, as happens in many other programming languages. In Tcl there is another beast, a command called uplevel that can evaluate code in the context of the calling procedure, or for what it's worth, in the context of the caller of the caller (or directly at the top level). What this means is that what in Lisp are macros, in Tcl are just simple procedures. Example: in Tcl there is no "built-in" for a command repeat to be used like this:

repeat 5 {
 puts "Hello five times"
}

But to write it is trivial.

proc repeat {n body} {
 set res ""
 while {$n} {
 incr n -1
 set res [uplevel $body]
 }
 return $res
}

Note that we take care to save the result of the last evaluation, so our repeat will (like most Tcl commands) return the last evaluated result. An example of usage:

set a 10
repeat 5 {incr a} ;# Repeat will return 15

As you can guess, the incr command is used to increment an integer var by one (if you omit its second argument). "incr a" is executed in the context of the calling procedure, (i.e. the previous stack frame).

Congratulations, you know more than 90% of Tcl concepts!

Why is Tcl powerful?

I am not going to show you every single Tcl feature, but I want to give an idea of advanced programming tasks that are solved in a very nice way with Tcl. I want to stress that I think Tcl has a number of faults, but most of them are not in the main ideas of the language itself. I think there is room for a Tcl-derived language that can compete with Ruby, Lisp and Python today in interesting domains like web programming, network programming, GUI development, DSL and as scripting language.

Simple syntax that scales

Tcl syntax is so simple that you can write a parser for Tcl in few lines of code in Tcl itself. I wrotea macro system for Tcl in Tcl as I already mentioned, which is able to do source level transformations complex enough to allow tail call optimization. At the same time, Tcl syntax is able to scale to appear more algol-like, it depends on your programming style.

No types, but strict format checks

There are no types, and you don't need to perform conversions, however, you aren't likely to introduce bugs because the checks on the format of the strings are very strict. Even better, you don't need serialization. Have a big complex Tcl list and want to send it via a TCP socket? Just write: puts $socket $mylist. On the other side of the socket read it as set mylist [read $socket]. and you are done.

Powerful, event driven I/O model

Tcl has built-in event-driven programming, integrated with the I/O library. To write complex networking programs with just what is provided in the core language is so simple it's funny. An example: the following program is a concurrent (internally select(2) based) TCP server that outputs the current time to every client.

socket -server handler 9999
proc handler {fd clientaddr clientport} {
 set t [clock format [clock seconds]]
 puts $fd "Hello $clientaddr:$clientport, current date is $t"
 close $fd
}
vwait forever

Non-blocking I/O and events are handled so well that you can even write to a socket where there is no longer output buffer and Tcl will automatically buffer it in userland and send it in background to the socket when there is again space on the socket's output buffer.

Python users know a good idea when they see it - Python's "Twisted" framework makes use of the same select-driven IO concepts that Tcl has had natively for years.

Multiple paradigms

In Tcl you can write object oriented code, functional style code, and imperative code in a mix, like it happens in Common Lisp more or less. A number of OOP systems and Functional Programming primitives where implemented in the past. There are everything from prototype-based OOP systems to SmallTalk-like ones, and many are implemented in Tcl itself (or were initially, as a proof-of-concept). Furthermore, because code in Tcl is first class, it is very simple to write functional language primitives that play well with the logic of the language. An example is lmap:

lmap i {1 2 3 4 5} {
 expr $i*$i
}

which will return a list of squares, 1 4 9 12 25. You can write a map-like function based on a version of lamba (also developed in Tcl itself), but Tcl has already what you need to allow for a more natural functional programming than the Lisp way (which works well for Lisp but maybe not for everything else). Note what happens when you try to add functional programming to a language that's too rigid: Python and the endless debate of its functional primitives.

Central data structure: the list

If you are a Lisp programmer you know how beautiful is to have a flexible data structure like the list everywhere in your programs, especially when the literal is as simple as "foo bar 3 4 5 6" in most cases.

Programmable programming language via uplevel

Via eval, uplevel, upvar and the very powerful introspection capabilities of Tcl you can redefine the language and invent new ways of solving problems. For example, the following interesting command if called as first command in a function will automagically make it a memoizing version of the function:

proc memoize {} {
 set cmd [info level -1]
 if {[info level] > 2 && [lindex [info level -2] 0] eq "memoize"} return
 if {![info exists ::Memo($cmd)]} {set ::Memo($cmd) [eval $cmd]}
 return -code return $::Memo($cmd)
}

Then, when you write a procedure just write something like:

proc myMemoizingProcedure { ... } {
 memoize
 ... the rest of the code ...
} 

i18n just happens

Tcl is probably the language with the best internationalization support. Every string is internally encoded in utf-8, all the string operations are Unicode-safe, including the regular expression engine. Basically, in Tcl programs, encodings are not a problem - they just work.

Radical language modifications = DSL

If you define a procedure called unknown it is called with a Tcl list representing arguments of every command Tcl tried to execute, but failed because the command name was not defined. You can do what you like with it, and return a value, or raise an error. If you just return a value, the command will appear to work even if unknown to Tcl, and the return value returned by unknown will be used as return value of the not defined command. Add this to uplevel and upvar, and the language itself that's almost syntax free, and what you get is an impressive environment for Domain Specific Languages development. Tcl has almost no syntax, like Lisp and FORTH, but there are different ways to have no syntax. Tcl looks like a configuration file by default:

disable ssl
validUsers jim barbara carmelo
hostname foobar {
 allow from 2:00 to 8:00
}

The above is a valid Tcl program, once you define the commands used, disable, validUsers and hostname.

Much more

Unfortunately there isn't room to show a lot of interesting features: most Tcl commands just do one single thing well with easy to remember names. Strings operations, introspection and other features are implemented as single commands with subcommands, for examplestring length, string range and so on. Every part of the language that gets indexes as argument support an end-num notation, so for example to take all the elements of a list but not the first nor the last you just write:

lrange $mylist 1 end-1

And in general there is a lot of good design and optimization for the common case inside. Moreover the Tcl source code is one of the best written C programs you'll find, and the quality of the interpreter is amazing: commercial grade in the best sense of the word. Another interesting thing about the implementation is that it works exactly the same in different environments, from Windows to Unix, to Mac OS X. No quality difference among different operating systems (yes, including Tk, the main GUI library of Tcl).

Conclusion

I don't claim everybody should like Tcl. What I claim is that Tcl is a powerful language and not a Toy, and it's possible to create a new Tcl-alike language without most of the limitations of Tcl but with all of its power. I tried this myself, and the Jim interpreter is the result: the code is there and working and can run most Tcl programs, but then I had no longer time to work for free to language development, so the project is now more or less abandoned. Another attempt to develop a Tcl-alike language,Hecl, is currently in progress, as a scripting language for Java applications, where the author (David Welton) exploits the fact that the Tcl core implementation is small, and the command based design simple to use as a glue between the two languages (This is not typical with modern dynamic languages, but both the ideas apply to Scheme too). I'll be very glad if, after reading this article, you no longer think of Tcl as a Toy. Thank you. Salvatore.

Vote on Reddit.com

p.s. want to learn more about Tcl? Visit theTclers Wiki.

Samuel Medina

Empty: Bell Labs in Holmdel, New Jersey, as it awaits redevelopment.

Photography by Rob Dobi

At its peak, thousands passed through its massive, light-filled atrium. Today, Bell Labs Holmdel stands empty, all of its 1.9-million-square-feet utterly without life. An iconic example of the now-disparaged office park, the campus in central Jersey, was shuttered in 2007 and vacated soon after. Years later, it remains in an abandoned, if not unkept state. The grounds are cared for, the floors swept clean, and the interior plantings trimmed, however haphazardly. (That's saying something; in the laboratory's heyday, plastic shrubbery filled its glorious central hall.)

For zombie fans, it isn't much of a stretch to imagine the luckless protagonists of the Walking Dead holed up here, fenced off from the rest of the world by six-story high glass walls. (Alternatively, it would make a great lair for the Governor.) Of course, in such a scenario, it's plausible that the virus capable of raising the dead would have originated inside the lab itself. As is often noted, the building is as highly prized by scientists as it is by architects. It was here, in Saarninen's quarter-mile fortress, that has housed some of the last century's most significant scientific discoveries. 

And it's here that the building's new owner, Somerset Development, imagines a new urbanist temple to commerce. Plans are in place to revitalize the site as a town center for Holmdel, complete with urban ammenities like shops and a coffee shop. But as Fred Bernstein wrote in last month's cover story, the building's uncompromising layout complicates Bell Lab's adaptive reuse. New York architect Alexander Gorlin is currently exploring strategies that will bring life back to the historic complex, while still preserving Saarinen's graceful design. It will be interesting to see how he navigates that process.

In the meantime, take a tour of the building through Rob Dobi's striking photography of the building in its current state. It might be your last chance before the place is overrun with mocha-wielding teens.