fogus

; there are some obvious micro optimizations, I left them out for clarity
; the relative ordering of read and writes with volatile and plain array should be thread-safe (if not, point it out)

; @wagjo asked "Have you found use for such concept? Must be pretty slow compared to unchunked one"
; The idea came out of a discussion on transducers so not used for real, yet.
; Once you optimize it (remove the boxing induced by the volatile, switch to unchecked math) there should not be much
; of an overhead.
; When you have one big composed reducing fn (eg several mapping stages) then each item is going to be processed in 
; each stage, each stage of the mapping may evict from the data cache stuff used by previous stages. So you have cache
; misses for each item.

fogus

(comment ; Fun with transducers, v2

  ;; Still haven't found a brief + approachable overview of Clojure 1.7's new
  ;; transducers in the particular way I would have preferred myself - so here goes:

  ;;;; Definitions
  ;; Looking at the `reduce` docstring, we can define a 'reducing-fn' as[1]:
  (fn reducing-fn ([]) ([accumulation next-input])) -> new-accumulation

  ;; We choose to define a 'transducing-fn' as:

fogus

;; Still haven't found a brief + approachable overview of Clojure 1.7's new Transducers
;; in the particular way I would have preferred myself - so here goes:

;;; Transducers recap
;; * (fn reducer-fn [] [accumulation] [accumulation next-input]) -> val [1].
;; * (fn transducer-fn [reducer-fn]) -> new-reducer-fn.
;; * So a transducer-fn is a reducer-fn middleware[2], and composes like it.
;; * All (numerous!) benefits[4] fall out of this simple +
;;   not-particularly-impressive-looking[3] definition.
;;

fogus

import re

def markdown_to_bbcode(s):
    links = {}
    codes = []
    def gather_link(m):
        links[m.group(1)]=m.group(2); return ""
    def replace_link(m):
        return "[url=%s]%s[/url]" % (links[m.group(2) or m.group(1)], m.group(1))
    def gather_code(m):

fogus

(ns tumblrsearch.core
  (:require-macros [cljs.core.async.macros :refer [go]])
  (:require [clojure.browser.repl]
            [cljs.core.async :as async :refer  [put! chan <!]]
            [om.core :as om :include-macros true]
            [om.dom :as dom :include-macros true]
            [figwheel.client :as fw :include-macros true]
            )
  (:import [goog.net Jsonp]
           [goog Uri]

fogus

(ns schema->gen
  "Functions for generating test data from schemas."
  (:require [four.stateful :as four]
            [re-rand :refer [re-rand]]
            [schema.core :as sch]
            [simple-check.generators :as gen]))

(defn ^:private re-randify-regex
  "schema requires ^$ while re-rand forbids them"
  [re]

fogus

Links for essays ref'd in http://blog.fogus.me/2009/03/11/seven-books/

• On the Criteria to Be Used in Decomposing Systems Into Modules – David Parnas
• A Note On Distributed Computing – Jim Waldo, Geoff Wyant, Ann Wollrath, Sam Kendall
• The Next 700 Programming Languages – P. J. Landin
• Can Programming Be Liberated from the von Neumann Style? – John Backus
• Reflections on Trusting Trust – Ken Thompson
• Lisp: Good News, Bad News, How to Win Big – Richard Gabriel
• An Experimental Evaluation of the Assumption of Independence in Multiversion Programming – John Knight and Nancy Leveson
• [Arguments and Results –

fogus

;; Datomic example code
(use '[datomic.api :only (db q) :as d])

;; ?answer binds a scalar
(q '[:find ?answer :in ?answer]
   42)

;; of course you can bind more than one of anything
(q '[:find ?last ?first :in ?last ?first]
   "Doe" "John")

fogus

(import 'clojure.lang.ExceptionInfo)

(defn call-cc [f]
  (let [v (promise)
        e (ex-info "cc" {:v v})]
    (try (f #(do (deliver v %) (throw e)))
         (catch ExceptionInfo ex
           (if (identical? ex e)
             @(:v (ex-data ex))
             (throw ex))))))

fogus

Cole Brown

SPJ recently gave a fantastic talk on Edward Kmett's wildly useful lens library. Simon,a brilliant programmer and one of Haskell's designers, had little to no experience with lens prior to this talk and, resultingly, is able to offer a shockingly fresh perspective.

In his talk, he walks the audience through his deconstruction of the library — an illuminating journey. There is a lot of insight exposed, but there was one (perhaps unspoken) sentiment that struck me:

Functional programmers tend to prefer simple, versatile data structures like lists and trees. The reasoning is often times simple: simple data types yield powerful abstractions. One can implement a mind-boggling number of algorithms using maps and folds over lists (and associative lists).

While Haskell caters to this simplified model of programming, Haskell's type system and record syntax also encourage the use of abstract data ty