curveship

The CPU loaded a bytecode program into the PRU's memory and told it to run.

The PRU ran a bytecode execution engine that was handcoded in assembly. The core of the engine was a loop:

- perform the routine for the current bytecode

- when the routine finished, spin on the PRU's embedded timer (the IEP) until 256 ticks (1.28us) had passed since the start of the cycle

- advanced to the next bytecode and repeated

External devices were connected either via I2C (those that didn't need super-tight timing) or to the pins controlled by the PRU. Some of the bytecodes controlled execution flow like loops while others were specific to the application, things like turn light on, move lens, trigger camera, etc.

There were a few more bells and whistles, like memory locations where flags were set by the engine to let the CPU know how progress was going.

It was a fun project. Unfortunately, the manufacturer of one of the core devices decided to stop making it, so that start-up had to go in a different direction.

The PRU is the unsung gem of the BeagleBone. I used it to prototype an optical control system that needed sub-100ns timing. As the article hints, it's not an easy beast to get started with, but it offers crazy realtime abilities.

wow, thanks for the vid! can anyone explain why this happens?

It sounds like you're parsing the JSON straight into your business objects, which is the source of the problem. You need an intermediate class which represents a strongly-typed version of the JSON message. So JSON.net goes from a JSON string into this message object, then you write your own code (or, if it works for you, use a tool like automapper), to go from that into your business classes.

It's because Eich was told to make JS C-like. In C, an empty array, an empty string, 0, false and null are all the same value: a word with all bits 0. So in JS, those are all are falsy and == to each other.

(x=0)=>()=>++x

For the first 5, I've got 2,3,8,14,7. Anybody got tighter solutions?

I think you may have misunderstood the article.

There were two tests, one to distinguish strad from modern, one to score which instrument musicians liked best. In the first, they didn't get 31 of 33 wrong, they got 33 wrong and 31 right, virtually a 50/50 split. In the preference test, modern violins placed first and second, with the top place substantially above the others, though the article doesn't give the full score breakdown.

Gotta love footnote 1, about the ordering of author names :)

> 1. In keeping with our argument, and following in an extensive tradition of subverting traditional scarce markers of prestige, the authors have adopted a redistributive approach to the order of their names in the byline. As an international collaboration of uniformly nice people (cf. Moran, Hoover, and Bestiale 2016; Hoover, Posch, and Bestiale 1987; Hoover et al. 1988; see Tartamelia 2014 for an explanation), lacking access to a croquet field (cf. Hassell and May 1974), and not identifying any excellent pun to be made from ordering our names (cf. Alpher, Bethe, and Gamow 1948; Lord, de Vader, and Alliger 1986), we elected to assign index numbers based on alphabetical ordering by surname and to randomise these using an online tool. For the avoidance of doubt, while several of the authors have pets none of them are included as authors (cf. Matzinger and Mirkwood 1978). None of us are approaching a tenure decision (cf. Roderick and Gillespie 1998). And none of us are fictional entities who generate their papers algorithmically using SciGen (see Labbé 2010 for the contrasting case of Ike Antkare nevertheless greatly outranked all of the authors on several formal measures of excellence before he [it?] was outed).

Shouldn't that be `if p % x == 0:`, not `if p % 2 == 0:`?

No. That's the whole point of using JSON.parse() instead of eval(). JSON is defined as a non-executing subset of JavaScipt syntax, one that contains only literal expressions. JSON.parse() will only parse valid JSON.

This is why, for instance, there's no native Date format in JSON. Dates in JavaScript require running a constructor -- new Date() -- so they aren't in JSON.

Sure. This is actually a pretty standard summary of the shift away from structuralist social theories.

Social structures tend to be pretty stable: the same people and forces stay in power for a while. How should we think about that stability?

One way is to imagine that society is like a building: a solid structure that preserves those people and forces in power. It's stable because it's rigid, and time doesn't affect it much.

But there's a second option. Think of a standing wave in a river, like the kind that whitewater kayakers like to surf on: it's not rigid at all, but it's still "stable," welling up continually at the same spot.

So is our society structured like a building, or like a standing wave?

If we go with the standing wave idea, that brings up a lot of new questions. We start wondering about dynamics, flow and motion. We also start wondering about the river bottom: is there a big rock under there causing the wave, or does it just happen to emerge from the otherwise random arrangement of smaller rocks?

Wouldn't it discourage long-time owners from selling, thereby limiting supply and raising prices?

I'm betting this isn't a bug but isn't malicious either. Possible scenario:

Product: So Sue, how's the restore-session-after-crash feature going?

Dev: Great, just about done.

Product: So it's working for all sessions now? Fantastic!

Dev: Yep! Well, all sessions except private ones of course.

Product: ... so you haven't finished private sessions yet?

Dev: No, it's just that we don't store anything on disk for them, so there's nothing to restore.

Product: ...

Dev: ...

Product: Users don't know what "stored on disk" even means. They're going to be very upset if we lose their work after a crash, just because the session happened to be private. Maybe even more so.

Dev: But with nothing on disk, that would be impossible.

Product: You devs have such a fixed mindset. If I had a penny for every time I'd heard one tell me something was "impossible." So store what you need on disk, and ...

Dev: But history ...

Product ... and flag it so it doesn't show up in history or as a visited link. Wouldn't that work?

Dev: Well, kind of, but ...

Product: Great! So we have a solution. How long to get that coded up?

[Later] Product: "Impossible" laugh Hah!

It looks like react-cursor is 1300 loc [1], mobservable is 1900 [2]. How is that "vastly less code"?

1 - https://github.com/dustingetz/react-cursor/blob/master/dist/... 2 - https://github.com/mweststrate/mobservable/blob/master/dist/...

Thesis: http://mviering.de/reactiveruby.pdf

This is some interesting research, but for those hoping to code actual Ruby applications in a reactive style, I don't think this will give you all that you need. The main contribution here is to use a JIT with inline caches (Truffle VM) to optimize change propagation. That's some cool work, but it comes at a cost in flexibility and power, at least with the current state of the project. The framework supports only static graphs that only grow (no removing nodes), and changes must be single source (no "transactions" that handle several changes simultaneously). Those limitations are enough to make this probably not useful in "the real world." As a research project, though, using JIT w/ ICs to optimize propagation seems really promising.

Also worth noting is that Flow is Mac and Linux only, no Windows support. We're a mixed platform shop, so that excludes Flow.

Also, if you're paused at a wait point, the console has access to local scope, so you often don't even need to create a global variable, just start using the local ones directly.

Holy cow:

    "After my surgery [for cancer], while I was still on
     maternity leave, I received a form letter saying 
     that the health insurance provided by my employer 
     had been terminated. Dozens of panicked emails 
     and phone calls later, the whole thing was, I was
     told, a glitch in the system. After a week of back 
     and forth, I was offered COBRA coverage, by which 
     point I had already switched to my husband’s 
     insurance, where I remained for the duration of my 
     care."

That's a pretty GIGANTIC "glitch," one that turned out hugely in Amazon's favor. Cheiffetz claims she accepts that it was an "administrative error," but you have to wonder. By getting her to switch to her husband's plan, Amazon may have saved themselves hundreds of thousands of dollars.

> can't tell if it's actual speed or "cheating"

I just commented below after looking over their benchmark. In it, the Imba implementation, and it alone, is caching and reusing the rendered todo views (globally, forever -- hello memory leak). Without that, they're only 2x faster than React and Mithril, not 60x.

rAF batching isn't an issue. They perform a render(true) after each change, effectively making all frameworks work synchronously.

Other than that, it is an interesting framework, and I wish them well.

I just spent an hour looking at the Imba benchmark. Yep, it's cheating. Which is a shame, because I really like the framework as a whole.

The vast majority of the speedup comes from a single sneaky line of code. The majority of their "Everything" benchmark's time is spent in the reorder step. They've implemented this as "remove a random todo, render, push the removed todo back onto the end, render." The Imba implementation, and it alone, caches the rendered todo view, so that they can re-use it once the todo is reinserted.

This single optimization is responsible for the vast bulk of their claimed speed. Removing it puts Imba only 2x faster than React, not 60x.

If you want to try it yourself, look at line 55 of app.js. Change:

    res.push((this['_' + todo.id] = this['_' + todo.id] || t$('todo')).setObject(todo).end());

... to:

    res.push(t$('todo').setObject(todo).end());

Furthermore, this isn't a caching strategy you'd want to use in a real app. It holds onto all DOM nodes ever created, thereby leaking quite a lot of memory.

Again, I think Imba is cool, and fast, just not otherworldly fast. I hope this was just an "oops!" and not an intentional misrepresentation.

I can't speak to #1 and 2, but for #3, one of the criticisms of CoffeeScript has been that defining local variables and modifying variables from an outer scope have the same syntax. I.e., if I see `foo = 1` in a piece of code, I don't know if it's creating a local variable called foo or modifying a variable called foo from a containing scope -- the only way to tell is to scan all the containing scopes for a variable called foo. Even worse, let's say a piece of code had an inner function that declared a variable foo, but I then declare a variable called foo in an outer scope. That inner statement now silently switches from declaration to modification. I suspect this is why they force the use of `var` for declaration -- it disambiguates the two cases

With all respect, it doesn't sound like you've taken the time to understand LINQ:

- Single and SingleOrDefault crashing with >1 row is a feature, not a bug. It means that your expectation that your filter is unique was incorrect. In that scenario, a crash is what you want. It's like when we use asserts. Similarly ..

- First and FirstOrDefault are only really appropriate after an OrderBy, i.e. to get the top item of a particular ranking. Using them anywhere else is almost always incorrect, and in the very few cases where it isn't, needs a comment to explain why, or I'll bounce your code back to you in review :).

LINQ is very expressive (you can do a lot with a little bit of code), especially with the embedded (non-fluent) syntax. That means that, yes, you can write some non-optimal code without realizing it, because it's only a few lines. On the flip side, you can also refactor that code quickly into more optimal patterns. By comparison, old-school iterating through collections is often much more difficult to refactor.

Easy there. You've misunderstood the benchmark. It shows the time to add 100 images, given the existing number of images. So adding the 900th-1000th image was ~3x faster than adding the 100th-200th.

What you call JSON is what I've usually heard called a ViewModel: a logical representation of the state of your view. I've found it very useful as well.

I was curious about the claimed collection performance too, since this is an area that a lot of people have looked at, and a 5x improvement there would be pretty impressive.

Apparently, what makes jsblocks different is that it appears to be doing dynamic code generation. That's an interesting idea, though I'd have concerns about how it respects lexical scoping. There are a couple bumps apparent as well:

- the benchmark is only faster because it ends in a .reduce(). I suspect that code generation allows them to remove all collection generation here and just update the reduced value in a loop. If you remove the reduction at the end, then lodash is fastest, as expected.

- the jsblocks code in their own benchmark reports the wrong result. It appears there's either an off-by-one error or the generated code runs the filter step before the map. I'm not counting this against the method, as presumably it's fixable, but it might speak to the difficulty of code generation as a strategy.

Heh, this quote brought back memories:

> They use a hack to break the countdown timer just before it expires, creating an open-air LAN party.

I lived in Cuba from 2000-1, and back then the only way online was to buy cards granting a limited amount of dial-up access. I figured out that their accounting system restarted each day, and that if you stayed on over midnight, only the time in the second day was counted against you. So I was online every night from 8 to 12:01, losing only a minute of time. I also figured out the card didn't truly expired until the day after you used it up, so on your last day, you could be on and off as much as you wanted.

My honest guess is that these "hacks" are not only known by the workers but quite possibly created by them, so that they can get around the restrictions themselves. There's a tremendous amount of theft from workplaces in Cuba. How bored does an internet cafe worker have to get before they figure out a way to get online as much as they want. And if others figure it out, who cares?

This is happening all over the nation. Here in small Durham, NC, we've seen biking more than double over the last 6 years. Most of the increase is young creative workers who've come for Durham's growing tech and advertising scene. It's also causing some growing pains -- we had three cyclists killed last year by cars.

Issues logged for this, the multi-line comment termination issue, and for treating any line that ends with')' or '}' as javascript.

The compiler also fails if a multi-line comment doesn't end at the end of a line.

  <!-- a comment --> and more text

It outputs an empty compiled file.

My honest opinion is that you should consider rewriting the compiler in a classic tokenize-parse-compile style. Several projects (like mustache.js) have had to go through this evolution. Your current solution -- line-by-line with regexes and state flags -- will only get hairier and hairier.