Compass a CSS framework

Home - compass - GitHub

Compass is a CSS framework that allows you to define and maintain complex CSS in a succinct manner.  There is a DSL which looks similar to CSS, but allows for some functional relationships to be defined.  One example in the screencast essentially allows the programmer to define that one class has a border that is half the size of another CSS class.  And the size of the original is defined with passing in a size as a parameter to the first class.  So a single change will change all related items when the CSS is next compiled.

The second thing that stood out to me was the ability to use compass as a "glue" layer between your CSS and your html markup.  In the example screen cast, the author used the ID tags on the divs and spans in the html and the appropriate CSS classes and defined those connections in the SAS DSL.  The beauty of this approach is removing all references to CSS in your generated html so there is only one place to maintain changes without having to go through all the html code and do a find/replace.

Functionally, as soon as changes are made to the associated SAS file (the compass DSL), when you are running the compass compiler, it will automatically regenerate the appropriate CSS.

SAS also allows for code sharing via imports.  So, it is easy to centralize CSS in such a way that it can easily be reused between various CSS files across your application.

I was skeptical about the usefulness of a CSS framework, but after watching the screencast, it makes a lot of sense as to why it could be very useful.  Like anything, if CSS is grown organically as often happens in larger projects, it can grow into a hairy mess over time.  I especially liked the idea of keeping the "glue" between your html and your CSS in a separate file.  But, it would seem that as an application's number of screens and IDs multiplies the CSS files would become voluminous unless the developer was very careful to reuse div and span ID's.  And that can be problematic as well.

Regardless, I think compass is worth looking at.  I expect as our websites become increasingly dependant on complex CSS layouts, programmers and designers will start to rely more and more on tools like compass to generate their CSS.

Clojure, parallel execution and closures

For completeness, here is code that should be pretty close to the threaded version of SBCL.  I decided to use the parallel map function instead of setting up explicit threads because of it's simplicity.  As expected, since we have to use a ref inside the closure which uses transactions to coordinate access, the result is always correct.

;; import random
(def random (java.util.Random.))

;; Closure containing state
(let [x (ref 0)]
  (defn incr1 [] (dosync (ref-set x (inc @x))))
  (defn show-incr1-val [] (print @x))
)

;; Threading function sleeping for random time
(defn my-thread [thread-name]
  (loop [i 0]
    (when (< i 10)
      (println (format "thread %s: %s" thread-name (incr1)))
      (. java.lang.Thread sleep (.nextInt random 3000))
      (recur (inc i))))
)

;; Use pmap to run the function 10 times in parallel
(doall (pmap my-thread (range 0 10)))

And here is the end of the run:

thread 8: 96
thread 7: 97
thread 8: 98
thread 7: 99
thread 7: 100
(nil nil nil nil nil nil nil nil nil nil)
user=>

SBCL, threads and closures

I was wrong it appears that a closure created before a thread is instantiated in SBCL is global and not thread safe without some sort of internal locking.  Here is an example that shows the thread safety issue.

(use-package :sb-thread)

;; Closure containing state
(let ((x 0))
  (defun incr1 () (setf x (1+ x)))
  (defun show-incr1-val () (print x))
  )

;; threading function sleeping for random time
(defun my-thread (thread-name)               
  (dotimes (i 10)  
    (format t "~a: ~a~%" thread-name (incr1))
    (sleep (random 2)))
  (format t "Thread ~a ending with value ~a" thread-name (show-incr1-val))
)

;; start up 10 threads
(dotimes (x 10)
  (make-thread (lambda () (
               my-thread (format nil "Thread ~a" x)
                     ))))


One particular run ended like so...

Thread 8: 95
Thread 1: 96
Thread 3: 97

97 Thread Thread 8 ending with value 97
97 Thread Thread 1 ending with value 97
(show-incr1-val)
97
97

So, somewhere along the way we lost some values.  10 threads counting to 10 should have ended with 100 in our closure. 

Next, I wanted to see if I could make my closure thread safe.  So, I added a mutex:

(use-package :sb-thread)
(use-package :sb-ext)

;; mutex to lock closure during update
(defvar *a-mutex* (make-mutex :name "closure lock"))

;; Closure containing state
(let ((x 0))
  (defun incr1 () (with-mutex (*a-mutex*)
            (setf x (1+ x))))
  (defun show-incr1-val () (print x))
  )

;; threading function sleeping for random time
(defun my-thread (thread-name)               
  (dotimes (i 10)  
    (format t "~a: ~a~%" thread-name (incr1))
    (sleep (random 2)))
  (format t "Thread ~a ending with value ~a" thread-name (show-incr1-val))
)

;; start up 10 threads
(dotimes (x 10)
  (make-thread (lambda () (
               my-thread (format nil "Thread ~a" x)
                     ))))

And low and behold, the next run ended correctly.

99 Thread Thread 4 ending with value 99Thread 2: 100

(SHOW-INCR1-VAL)
100 Thread Thread 2 ending with value 100
100
100

Closures in Clojure

closures in clojure « Musings of a would be lispnik

My good fiend Mr Lispnik contends that clojure has closures.  I believe he is right in part, but there are some kinds of closures that are difficult to do in clojure.  As I note below, this is mainly due to issues of thread safety.

Without further ado, here is a nifty little closure that keeps it's internal state in a closure.  The following is in common lisp (SBCL).

* (let ((x 0)) (defun incr1 () (setf x (1+ x))))
INCR1
* (incr1)
1
* (incr1)
2
* (incr1)
3
* (incr1)

But you cannot use closures in this way in clojure.  You can see an explanation here as to why this is.  But in short, it has to do with thread safety because that function may be called concurrently from multiple threads.  I am enough of a newbie in common lisp that I have no idea how and if this is handled in common lisp.  I have the feeling that in common lisp each function has to be instantiated in it's own thread and so the closure can't escape the thread.

So, the equivalent function in clojure has to use refs.

user=> (let [x (ref 0)] (defn incr1 [] (dosync (ref-set x (inc @x)))))
#'user/incr1
user=> (incr1)
1
user=> (incr1)
2
user=> (incr1)
3

So, yes, clojure has a form of closures, but you can't mutate state since you don't really have variables per se because of thread safety, you have to use a thread safe ref to accomplish the same thing.  On the other hand, it's pretty cool that you can still get the same effect.