Skip to content

Instantly share code, notes, and snippets.


Phil Hagelberg technomancy

View GitHub Profile
View gist:e1a347f91abe11e440b7ba5c33f991c7
[ 50%] Building C object CMakeFiles/tic80core.dir/src/core/sound.c.o
[ 50%] Building C object CMakeFiles/tic80core.dir/src/api/js.c.o
[ 50%] Building C object CMakeFiles/tic80core.dir/src/api/lua.c.o
[ 50%] Building C object CMakeFiles/tic80core.dir/src/api/wren.c.o
[ 50%] Building C object CMakeFiles/tic80core.dir/src/api/squirrel.c.o
[ 52%] Building C object CMakeFiles/tic80core.dir/src/ext/gif.c.o
[ 52%] Building C object CMakeFiles/tic80core.dir/src/tic.c.o
[ 52%] Building C object CMakeFiles/tic80core.dir/src/cart.c.o
[ 52%] Building C object CMakeFiles/tic80core.dir/src/tools.c.o
[ 52%] Building C object CMakeFiles/tic80core.dir/src/tilesheet.c.o
View gist:efe7b120abe93d56984474e6c8473233
phil@localhost:~/lunatest$ ~/.luarocks/bin/luacheck lunatest.lua | grep -v unused | grep -v whitespace
Checking lunatest.lua 40 warnings
lunatest.lua:46:29: variable setmetatable was previously defined on line 42
lunatest.lua:64:7: variable debug was previously defined on line 38
lunatest.lua:489:1: setting non-standard global variable default_hooks
lunatest.lua:512:1: setting non-standard global variable verbose_hooks
lunatest.lua:540:14: accessing undefined variable verbose_hooks
lunatest.lua:540:40: accessing undefined variable default_hooks
lunatest.lua:656:10: variable arg was previously defined as an argument on line 655
View logging-is-weird.clj
;; works
(let [factory*logger-factory*]
(alter-var-root #'*logger-factory*
(is (thrown-with-msg? Exception #"Message not processed"
(test-utils/process-message! msg 2)))
(alter-var-root #'*logger-factory* factory))))
technomancy / crash.log
Created Dec 26, 2017
urn crash in luaj
View crash.log
~/src/urn $ make test LUA=luaj
luaj bin/urn.lua tests/compiler/codegen/precedence --run -o /tmp/tmp.9mEtsMxCet -fstrict-structs --
org.luaj.vm2.LuaError: bin/urn.lua:2034 vm error: java.lang.ArrayIndexOutOfBoundsException: -1
stack traceback:
bin/urn.lua:2034: in function 'parseDocstring1'
bin/urn.lua:10481: in function 'validate'
bin/urn.lua:10501: in function 'run'
bin/urn.lua:2858: in function 'runPass1'
bin/urn.lua:10583: in function '?'
bin/urn.lua:11332: in main chunk
technomancy / gist:cc0e7800878c39e4c245fc041c11df4b
Last active Sep 10, 2021
Clojure namespaces, spec, and why they're confusing
View gist:cc0e7800878c39e4c245fc041c11df4b

To me, "require-and-automatically-visible" is violating the beauty of namespace. But, maybe I felt this way because I don't understand Clojure's registry or how require works.

I thought about this more, and I think I have a better understanding of why this feels strange. Clojure has one thing called "namespaces" which are clojure.lang.Namespace objects created by the ns macro. Functionally speaking they are a storage location which mostly just contain vars and references to vars in other namespaces. They are used for code organization: specifically for organizing vars and occasionally Java classes and interfaces.

Clojure also has a completely different thing called "namespaces" which are prefixes that get attached to keywords and symbols. These can interact with ns namespaces thru the reader in a handful of ways (for instance, ::double-colon keywords and symbols inside backtick forms are resolved according to the current clojure.lang.Namespace) but for the most part should be considered a di

View planet_noise.lua
local lg =
local lm = love.math
local pmethods={}
local function earth(u)
local cr,cb,cg
if u < 0.5 then
cb = u + 0.5

Leiningen Plugins

Leiningen tasks are simply functions named $TASK in a leiningen.$TASK namespace. So writing a Leiningen plugin is just a matter of creating a project that contains such a function, but much of this documentation applies equally to the tasks that ship with Leiningen itself.

Using the plugin is a matter of declaring it in the :plugins entry of the project map. If a plugin is a matter of user convenience rather

View gist:310638ce84d94131c56351cc67322ec4
~/src/slamhound $ head -n 1 project.clj
(defproject slamhound (or (System/getenv "CIRCLE_BUILD_NUM") "0.0.0-SNAPSHOT")
~/src/slamhound $ CIRCLE_BUILD_NUM=751 lein pprint :version
~/src/slamhound $ lein pprint :version
View test.el
(defvar clj-last-test "user")
(defun clj-run-tests (run-last)
(interactive "P")
(format "%s" `(circleci.test/run-tests
(quote ,(if run-last
(setq clj-last-test (clojure-find-ns))))))
technomancy /
Last active Jul 4, 2017
Clojure Conj talk proposal

Clojure Conj 2017 Talk: Dev Tools as Data

Abstract (5 sentences max)

In the Clojure community we love to say "it's just data", and this enables us to compose things in unique and often-unexpected ways.

One place where that maxim hasn't been thoroughly applied is developer tooling. Representing things like tracers, test runners, and refactoring tools with a unified declarative model allows us to construct powerful meta-tools for various development environments and avoid reinventing the wheel for building interfaces for each editor one at a time.

Let's do some cross-runtime metaprogramming for greater Clojure/editor symbiosis!