| ;; based on http://talks.golang.org/2012/concurrency.slide#50 | |
| (ns robpike | |
| (:require [cljs.core.async :as async :refer [<! >! chan close!]]) | |
| (:require-macros [cljs.core.async.macros :as m :refer [go alt!]])) | |
| (defn timeout [ms] | |
| (let [c (chan)] | |
| (js/setTimeout (fn [] (close! c)) ms) | |
| c)) |
| (ns async-test.throttle.core | |
| (:require [cljs.core.async :refer [chan close!o sliding-buffer]] | |
| [clojure.string :as string]) | |
| (:require-macros | |
| [cljs.core.async.macros :as m :refer [go alts!]])) | |
| (def c (chan (sliding-buffer 1))) | |
| (def loc-div (.getElementById js/document "location")) | |
| (.addEventListener js/window "mousemove" |
| (ns async-test.timeout.core | |
| (:require [cljs.core.async :refer [chan close!]]) | |
| (:require-macros | |
| [cljs.core.async.macros :as m :refer [go]])) | |
| (defn timeout [ms] | |
| (let [c (chan)] | |
| (js/setTimeout (fn [] (close! c)) ms) | |
| c)) | |
| (ns async-test.core | |
| (:require [cljs.core.async :refer [chan]] | |
| [clojure.string :as string]) | |
| (:require-macros | |
| [cljs.core.async.macros :as m :refer [go alt! alts!]])) | |
| (def c (chan)) | |
| (def loc-div (.getElementById js/document "location")) | |
| (.addEventListener js/window "mousemove" |
| (ns n01se.externs-for-cljs | |
| (:require [clojure.java.io :as io] | |
| [cljs.compiler :as comp] | |
| [cljs.analyzer :as ana])) | |
| (defn read-file [file] | |
| (let [eof (Object.)] | |
| (with-open [stream (clojure.lang.LineNumberingPushbackReader. (io/reader file))] | |
| (vec (take-while #(not= % eof) | |
| (repeatedly #(read stream false eof))))))) |
Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.
Tested against the WebKit git repo by entering the repo with 1 file dirty.
git diff --quiet --ignore-submodules HEAD # Will tell if there are any uncomitted changes, staged or not.
0.6 sec
git diff-index --quiet HEAD # Only tracked
2 sec
| (defmacro test-> | |
| "Takes an expression and a set of test/form pairs. Threads expr (via ->) | |
| through each form for which the corresponding test expression (not threaded) is true." | |
| [expr | |
| & clauses] | |
| (assert (even? (count clauses))) | |
| (let [g (gensym) | |
| pstep (fn [[test step]] `(if ~test (-> ~g ~step) ~g))] | |
| `(let [~g ~expr | |
| ~@(interleave (repeat g) (map pstep (partition 2 clauses)))] |
This gist is a collection of my rough notes from Strange Loop 2012.
Too much for teh twitterz :)
JVM + invokedynamic is in a completely different class than CLR + DLR, for the same reasons that JVM is in a different class than CLR to begin with.
CLR can only do its optimization up-front, before executing code. This is a large part of the reason why C# is designed the way it is: methods are non-virtual by default so they can be statically inlined, types can be specified as value-based so their allocation can be elided, and so on. But even with those language features CLR simply cannot optimize code to the level of a good, warmed-up JVM.
The JVM, on the other hand, optimizes and reoptimizes code while it runs. Regardless of whether methods are virtual/interface-dispatched, whether objects are transient, whether exception-handling is used heavily...the JVM sees through the surface and optimizes code appropriate for how it actually runs. This gives it optimization opportunities that CLR will never have without adding a comparable profiling JIT.
So how does this affect dynamic