I put together a small library make stateful setup and relative navigation with clj-http easier.

API Documentation

Fennel is a Lisp that transpiles to Lua and looks a lot like Clojure. Awesome-WM is the window manager I use daily - with a from-scratch configuration.

Fetch fennel.lua and what else you need (e.g. I use Lua Functional) into your ~/.config/awesome/ directory.

Next we need to ready Fennel in ~/.config/awesome/rc.lua and run the configuration written in Fennel:

local fennel = require("fennel")
fennel.path = fennel.path .. ";.config/awesome/?.fnl"
table.insert(package.loaders or package.searchers, fennel.searcher)
require("cfg")

My current config

Simply changing the Groovy version in a Springboot Gradle project won't cut it. Trying to force the version with

compile('org.codehaus.groovy:groovy-all:2.5.0')

will result in errors building the project:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileGroovy'.
> org/codehaus/groovy/ast/MethodCallTransformation

The problem there is, that Springboot manipulates the dependencies via the plugin after the fact. So we end up with mixed 2.4 (which is the default for Springboot 2 right now) and the desired 2.5.

To solve this, we need to change the Groovy version as described in Customizing managed versions .

Instead of changing the version at the dependency, add the following at the top level of the build.gradle:

ext['groovy.version'] = '2.5.0'

References:

• Issue

• Repo showing error and solution

When dealing with APIs we are often confronted with some sort of paging to access lists. Yet if we need to access all of the data, it would be nice to have them as a lazy sequence.

This can be done nicely with transducers:

(defn page-seq
  "Flat sequence of items loaded via the given page loading fn"
  [get-page-fn]
  (eduction
   (map get-page-fn)
   (take-while seq)
   cat
   (range)))

Add some tests:

(def pages
  (into [] (partition-all 20 (range 56))))

(defn get-page
  [page]
  (println "Loading page" page)
  (nth pages page ()))

(page-seq get-page)
;Loading page 0
;Loading page 1
;Loading page 2
;Loading page 3
; => (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ... 54 55)

Now see, if that is really lazy:

(take 10 (page-seq get-page))
;Loading page 0
;Loading page 1
; => (0 1 2 3 4 5 6 7 8 9)

Well, no. We should only see Loading page 0 and not the one for page 1. The reason for this is chunking. Clojure internally loads itself chunks of 32. So side effects will be problematic. But for just lazily loading the whole lot having some mismatch in the used paging and the chunking is good enough for now.