Show HN: Ghostwheel – easy spec, side effect detection and tracing for Clojure
1–10 of 20 posts
Re: Show HN: Ghostwheel – easy spec, side effect detection and tracing for Clojure
#2Fellow Clojurians, I present to you, Ghostwheel.
It makes the writing, reading, refactoring, testing, instrumentation and stubbing of function specs easy; introduces a concise syntax for inline fspec definitions; helps keep track of side effects; and makes general debugging almost fun, with full evaluation tracing of function I/O, local bindings and all threading macros.
It's Alpha software and the Clojure port, while essentially functional, still needs some love to achieve full feature parity with ClojureScript – most prominently missing at the moment is the tracing functionality.
To steal a quote from Nathan Marz' Specter in a blatant attempt at a so far likely undeserved comparison to its indispensability, I like to think of Ghostwheel as clojure.spec's missing piece. It has become quite essential to me and I hope that you will find it useful too.
Feedback, PRs, and issue reports are welcome and much appreciated.
Do your thing, HN.
Re: Show HN: Ghostwheel – easy spec, side effect detection and tracing for Clojure
#3This looks promising, can you expand on how this differs from clojure.spec and core.typed?
Re: Show HN: Ghostwheel – easy spec, side effect detection and tracing for Clojure
#4This looks promising, can you expand on how this differs from clojure.spec and core.typed?
This is basically generative testing using clojure.spec in a nice package with a cherry on top and a few extras.
core.typed still seems to be quite experimental and not yet production-ready, but it certainly looks very promising and I'm keeping an eye on it. It currently also doesn't work on ClojureScript, which has been the primary platform for Ghostwheel so far.
Re: Show HN: Ghostwheel – easy spec, side effect detection and tracing for Clojure
#5Cool, will try it out!
Re: Show HN: Ghostwheel – easy spec, side effect detection and tracing for Clojure
#6Fellow Clojurians, I present to you, Ghostwheel. It makes the writing, reading, refactoring, testing, instrumentation and stubbing of function specs easy; introduces a concise syntax for inline fspec definitions; helps keep track of side effects; and makes general debugging almost fun, with full evaluation tracing of function I/O, local bindings and all threading macros. It's Alpha software and the Clojure port, whil…
This looks great!
Is there a way to make it work with existing specced code? I already have a large codebase with lots of fdefs.
Can Ghostweel work with them without modification?
Thanks!
Re: Show HN: Ghostwheel – easy spec, side effect detection and tracing for Clojure
#7Fellow Clojurians, I present to you, Ghostwheel. It makes the writing, reading, refactoring, testing, instrumentation and stubbing of function specs easy; introduces a concise syntax for inline fspec definitions; helps keep track of side effects; and makes general debugging almost fun, with full evaluation tracing of function I/O, local bindings and all threading macros. It's Alpha software and the Clojure port, whil…
This looks great! Is there a way to make it work with existing specced code? I already have a large codebase with lots of fdefs. Can Ghostweel work with them without modification? Thanks!
At the moment you can set the gspec to nil, but that would simply disable s/fdef generation and all of the spec-related magic. I'm planning to introduce a configuration option with the next release to force Ghostwheel to trust that there's an external s/fdef for that function and still do all the spec stuff.
There may be some limitations on this compared to using inline gspecs – I have to play around with it a bit, but I think it should work fine. Until then, you can still use Ghostwheel for tracing and side effect detection though.
Re: Show HN: Ghostwheel – easy spec, side effect detection and tracing for Clojure
#8Fellow Clojurians, I present to you, Ghostwheel. It makes the writing, reading, refactoring, testing, instrumentation and stubbing of function specs easy; introduces a concise syntax for inline fspec definitions; helps keep track of side effects; and makes general debugging almost fun, with full evaluation tracing of function I/O, local bindings and all threading macros. It's Alpha software and the Clojure port, whil…
I am not sure about the Quick Fix thing in Cursive. Care to elaborate?
Re: Show HN: Ghostwheel – easy spec, side effect detection and tracing for Clojure
#9Fellow Clojurians, I present to you, Ghostwheel. It makes the writing, reading, refactoring, testing, instrumentation and stubbing of function specs easy; introduces a concise syntax for inline fspec definitions; helps keep track of side effects; and makes general debugging almost fun, with full evaluation tracing of function I/O, local bindings and all threading macros. It's Alpha software and the Clojure port, whil…
I am not sure about the Quick Fix thing in Cursive. Care to elaborate?
When you place the cursor on >fdef or >defn – which Cursive doesn't know what to do with out of the box – a light bulb appears right next to it. This is IntelliJ's quickfix feature for errors it can easily correct. You click it, select 'Resolve as...' and then 'defn'. I think the default shortcut ist Alt+Enter.
EDIT: I'll update the docs to make this clearer.
Re: Show HN: Ghostwheel – easy spec, side effect detection and tracing for Clojure
#10Fellow Clojurians, I present to you, Ghostwheel. It makes the writing, reading, refactoring, testing, instrumentation and stubbing of function specs easy; introduces a concise syntax for inline fspec definitions; helps keep track of side effects; and makes general debugging almost fun, with full evaluation tracing of function I/O, local bindings and all threading macros. It's Alpha software and the Clojure port, whil…
This looks great! Is there a way to make it work with existing specced code? I already have a large codebase with lots of fdefs. Can Ghostweel work with them without modification? Thanks!
The short answer is "more or less", the longer answer is the second one in the FAQ: