timcameronryan

A high-priority housing program is how you implement a human right for shelter.

This isn't some paperclip maximalization requirement you adhere to the social contract, and under the wrong conditions will force people into house-building labor camps. Human rights are how you reason about resource allocation. You have a right to a trial by a jury of your peers, but that obviously doesn't mean a judge must preside over your case that same day by threat of force. We can recognize physical realities, while still understanding that if we wanted to, we could provide a social safety net that includes a place to sleep.

> If your country ran out of money, if the builders all started working for foreign companies

If your country runs out of money, many human rights are probably in danger.

There's no shortage of builders. You can just compensate those workers with taxes. If you think taxes are also a form of slavery, that's a different discussion.

Perhaps it's usage by time? i.e. Pandora left on in the background.

I recall a lot of renewed energy a year ago into improving OpenSSL, including funding and support. Has that panned out as I would have hoped? LibreSSL improvements are highly visible (and exciting) but I expect I would have overlooked any OpenSSL improvements.

I can't wait for a JSX crate on Cargo.

I was impressed too. I think the key is that it injects all of the HTML at once. Compare that to e.g. the Backbone.js implementation which uses progressive enhancement: http://todomvc.com/examples/backbone/

The code can be optimized further with Closure Compiler, but I wonder if that decreases startup speed.

I'd love to refactor this to not need RC's for DOM nodes. I'm new to Rust, but I expect there's a ton of room for refactoring.

This uses a deeply hacked Rust stack. Take a look at this: https://github.com/tcr/rust-webplatform/blob/master/setup.sh It's also using a version of Rust that's pre-1.0.0.

Progress is being made on making this first class though: https://github.com/rust-lang/rfcs/issues/604

It is nasty code! I started refactoring before I hit some struct-alignment bugs (fixed on later Rust versions): https://github.com/tcr/rust-todomvc/blob/tcr-wip/src/main.rs

The parent navigation needs to be replaced by a jQuery-like .ancestors() macro.

This was an MVP so I wasn't focused on code quality over features; but I'm also learning Rust for the first time, so it came out less than impressive :)

The Octocat used here and in the API control panel[1] reminds me of robot anime (Gundam Wing, etc.) or perhaps Speed Racer. I don't think it's meant to be warrior-like, but futuristic.

[1] https://a248.e.akamai.net/assets.github.com/images/modules/b...

Programming for the Atari was one of my favorite coding challenges. I think the web offered a lot of similarities in the past decade (trying to make an unsuitable platform perform magic) and somehow jumping into 6502 assembly and trying to trick beautiful graphics out of the pithy TIA felt extremely satisfying.

Forked and made to support OS X: https://github.com/tcr/_why-spool-osx

Makes me excited for a forthcoming Emscripten => Brainfuck compiler.

I experimented with a CoffeeScript-like Lisp in JavaScript once. It's pretty opinionated, but provides interesting syntax possibilities (infix notation, non-significant parentheses and commas for clarity, JSON-compatible syntax): https://github.com/tcr/syrup

    range = fn: [i]
      loop: [i, r = []]
        if: (i == 0) r
          continue: (i - 1), concat: (i - 1), r
    
    print: range: 5                # [0, 1, 2, 3, 4]

For specific audiences, using Gists as data storage is really useful. I did the same for my "reverse StackOverflow": http://askedtheinter.net/

Users own all their data, they can revise their answers, and other users can fork them; just like small Git repositories, and just the use-case that gists generally solve. Compare: http://timcameronryan.askedtheinter.net/q/1318314 with https://gist.github.com/1318314

Hey all, I'm posting this to HN to see if there's any interest in a full-fledged JavaScript port to Lua. Colony right now is a proof-of-concept, but there might be a real use case out there for embeddable JavaScript where solutions like V8 would simply be too large.

Since it's a source-to-source compiler, you can use Colony generally wherever Lua source is required. For example, I was able to follow the beginners tutorials of the Corona SDK (http://www.anscamobile.com/corona/, a cross-platform mobile SDK that uses Lua) by programming CoffeeScript instead, which was surprisingly fun.

This is reworked from my other project, IERange (https://github.com/timcameronryan/IERange).

Rather than include a full duplication of DOM Ranges for old IE browsers, this API normalizes the most important capabilities of DOM Ranges and TextRanges (getting/setting anchors, and directionality). This can be included in a JavaScript library without much overhead, and any other essential DOM Range capability (deleteContents(), setStartBefore(), etc.), can be duplicated as needed by working with the DOM itself.

Much of the runtime has been developing by trying out existing code, then adding support gradually. Of course most of the code I tried out was ECMA3 compliant.

I expect to add in support for ECMAScript 5's Object extensions API (defineProperty, getters/setters) as Mug supports them internally, just as Mug already has a global JSON object. The features which could cause incompatibility with existing code is something I'd have to consider separately, so it depends when a majority of authors start writing ECMA5-compliant code (no function.callee, implicit this object bound to global, etc.)

Sometimes. The primitive types Mug can work with are `double`, `boolean`, `String`, and `JSObject`. This allows arithmetic operations and conditionals to be compiled without wrapping objects, and actual object invocations to be autoboxed as they are in JavaScript (like "a = 10" vs "a = new Number(10)")

The gaudy part is that there is only one type of function signature, basically "invoke(Object, Object, Object...)" which means Mug has to convert doubles to Doubles and booleans to Booleans across function calls... so it's somewhat of a tradeoff.

As al_james metioned, in order to emulate a dynamic language, you have to take a lowest-common-denominator approach. Thus all objects are of the type JSObject, which has functions for get() set() invoke() etc.-- basically a glorified HashMap+Runnable.

However, you don't need to wrap objects for arithmetic operations. At the moment Mug can determine the result of some types of expressions. If you're adding two doubles, it doesn't wrap the numbers before adding them. If you're calling (10).toString(), then it will autobox the number just as defined in the ECMAScript spec (the [[ToObject]] operation).

Deterction currently only works where types are explicit (a number literal will always be a number, etc.) The next step is to do type analysis on local variables, which will allow loops like for (var i = 0; i < 10; i++) { ... } to be compiled without wrapping primitives at all, greatly improving speed.

Right. Technically Mug will conform to the ECMAScript 3 Compact Profile: http://www.ecma-international.org/publications/files/ECMA-ST... Which doesn't include eval() or the with(){} statement (both used infrequently enough that it's not worth the overhead).

A REPL would still be possible, however, it would require some work to maintain the current scope between input.