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.

Tail recursion elimination in python

Neopythonic: Tail Recursion Elimination

After doing a lot of reading and playing w/ lisp, scheme and clojure, I find it interesting that Guido has no interest in tail recursion optimization.  However, I must say that python, which is my day job, has certainly stood the test of time.  It is a surprisingly powerful language and has been in almost all cases "fast enough" for what we do.  It doesn't have a few of the lisp niceties such as macros, etc, but you can do a surprising number of lisp tricks with it.

Debugging a lisp machine

Abstract Heresies

Ran across this earlier today and thought I'd make a quick blog posting about it.  In some ways it must have been a lot of fun to be able to work on a machine that had code in the same language all the way down to the metal.  Especially when debugging hard to find problems.   Homogeneous systems will probably be something we will never see again as more and more code moves to virtual machine like environments.  The beauty of homogeneity is outweighed by the practicality of being able to use multiple languages to solve problems.  Even lisp does not do all things equally well even though some I'm sure would disagree.  And so, we live in the practical world of differing languages all running together on heterogeneous systems.

I have had a stray and odd thought.  Programmers are very biased to their language(s) of choice.  Most never really get beyond their one core language though they may dabble in others.  With the advent of Microsofts CLR and the fact that a lot of other languages seem to be moving to the JVM, it does make me wonder if someday we will be able to cross compile code from one language to another.  I'm sure those that work on compilers for a living will be quick to tell me it's not possible.  But I do wonder if being able to translate to a different language might not make certain types of bugs obvious and/or allow quicker code generation because you can switch to a language that excels at a particular task.

Regardless, something to think about.

Mini projector

AAXA P1 Pico Projector - LCoS Based Hand-held Micro Projector - LED Pocket Projector

At the risk of putting up an advert, I gotta say this mini projector looks really cool.  I wonder if we aren't a generation or two away from getting these in our laptops and phones.  Currently it only does 640x480 which is mostly useful for presentations and showing ad hoc pictures, etc.  But, I'm sure that will continue to improve each iteration.  Now, if only someone would be kind enough to send me one to play with...