This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-09-21
Channels
- # admin-announcements (17)
- # aws (19)
- # beginners (28)
- # boot (103)
- # cider (5)
- # clojure (183)
- # clojure-art (46)
- # clojure-russia (25)
- # clojure-sg (2)
- # clojure-uk (1)
- # clojurescript (342)
- # clojurex (3)
- # core-matrix (1)
- # cursive (1)
- # datascript (2)
- # devcards (77)
- # devops (15)
- # emacs (4)
- # funcool (8)
- # hoplon (15)
- # immutant (47)
- # jobs (1)
- # ldnclj (10)
- # lein-figwheel (4)
- # off-topic (2)
- # om (23)
- # onyx (10)
- # re-frame (1)
- # reagent (23)
- # yada (7)
(defn dragon-sequence
"Returns a lazy sequence of vectors."
[]
(let [axiom [:F :x]
rules {:x [:x :+ :y :F :+]
:y [:- :F :x :- :y]}]
(basic-system axiom rules)))
(def dragon-render-rules {:F [:fwd 20]
:+ [:right 90]
:- [:left 90]
\[ [:save]
\] [:restore]
:x []
:y []})
(defn show-x4! []
(let [canvas (goog.dom/getElement "canvas-x4")
context (.getContext canvas "2d")
dragon (concat [:save] (nth (get-in @app-state [:dragon]) 10) [:restore])
x4 (concat [:color-index 0]
dragon
[:right 90 :color-index 1]
dragon
[:right 90 :color-index 2]
dragon
[:right 90 :color-index 5]
dragon
)]
(turtle/draw! (trc/->canvas context) x4 [900 900])))
just got rendering of graphs in my devcards: https://www.dropbox.com/s/7pgn93fy4jr58z2/Screenshot%202015-09-21%2015.50.37.png?dl=0
@meow: thanks, canvas should be pretty straightforward, I think, I use reagent, it gives me access to react lifecycle functions, so I can render graphs using some non-react js-library (d3)
also working on this: https://www.dropbox.com/s/0mte4cfz9d6p0lc/Screenshot%202015-09-21%2016.10.01.png?dl=0, to visualize how tools.reader with postprocessing parsed given source file
@darwin: Wow. Great stuff. Makes it so much easier when you can visualize stuff in living color, right? Very nice.
@meow: and I have also tooltips and can encode some stuff into DOM, so I can easily inspect my nested data structures using devtools via “inspect element”
@darwin: no matter what becomes of plastic, it seems like you are developing some awesome capabilities with the work you are doing.
@meow: that last devcard with parsed data is quite handy, it is not obvious from the screenshot, but it is an overlay on top of original plain source code with some opacity, so I can immediately spot inconsistencies: https://www.dropbox.com/s/wjrqg4e9acc9rjd/Screenshot%202015-09-21%2016.34.54.png?dl=0
@meow: FYI, just hit https://github.com/bhauman/devcards/issues/35, relevant to your recent PR
@bhauman: I've got on my todo list to set up my github so that I can "publish" my devcards - not sure how much time/effort that represents
I'm assuming that part of your project.clj file for devcards does this already for the cards you have at http://rigsomelight.com/devcards/#!/
I created a separate build that writes to a directory that I share with the gh-pages branch
I actually have plans to create an entire site primarily using devcards so I could really use a feature like that.
by site I just mean I have a github org that I plan to use as a sort of gallery/tutorial site: https://github.com/algorithmic-beauty
If this was built into devcards then more of us might publish our cards, which would help spread the word about devcards... 😉
I will also soon want to build gh-pages branch for plastic where I will show some devcards and editor states
The idea is you can call the mount namespace call from js at the bottom of your HTML file
This is one of those cases where I just want something easy. I don't really care how it works.
@bhauman: I hope that at some point in future I will be able to present whole plastic editor instance as a devcard, so I will be able to show/test different editor states
@darwin did you look at the iDevcardOptions protocol? It allows you to intercept the devcard options and manipulate them.
@bhauman: no, didn’t know about it, how it could help? btw. I solved my edn/code problem by building markdown code block and passing in a string
https://github.com/darwin/plastic/blob/master/cljs/src/devcards/plastic/devcards/util.cljs#L62
@darwin: it would let you implement your functionality without going so low level with register-card because you can intercept the options and change them as you will. for your case you could write a function that reifys a IDevcardOptions and just return the options as you need them, that way you don't have to mess with the path stuff etc.
@bhauman: thanks, good to know, actually I started messing with macros and then switched to this low level solution, because top-level macro defcard didn’t work well for me, I needed to define documentation as string concatenation and the macro parameter detection logic worked against me, will look into IDevcardOptions
well this protocol would allow you to specify any parameters you want to the defcard macro (defcard name (mything options))
why path isn’t part of the options? I like that I can simplify it, my namespaces are too long for display
@bhauman: I'll see if I can come up with a screenshot. Would really love to just be able to publish the darn page.
I'm really happy with my L-system code. Finally. Took a while to get it to where I wanted it to be. Can't wait to max it out and do really crazy things with it.
I need to do them, just because I can. But I really want to push beyond what's already been done.
Funny, the next thing I'm working on is supporting CA in L-systems. It can be done, but I want to make it even easier.
I'm really leveraging transducers, which worked out really well. I absolutely love those things. Transducers, for me, are one of the most foundational things that Clojure has brought to the table. I think transducers will be implemented in all sorts of languages and ultimately taken for granted.
And then working on support for parametric L-systems drove me to finally learn deftype, defrecord and protocol. And that worked out really well.
transducers are cool, but for most common cases laziness is enough when working with sequences, that is why I don’t think many people will learn transducers and will be using them on day-to-day basis
I like that they allow me to think about a problem like these L-systems from a process point-of-view and that I can comp
a bunch of xfs together and they will efficiently perform those operations on that data stream.
I'm still tickled that after having a number of variations of processes to support every variety of L-system that I can find documentation about that I've managed to boil it down to such a small amount of code, including recently getting it down to just one process function:
(defn produce
"Returns a lazy sequence of words from a recursive, axiomatic, transducible
process."
[get-xf]
(letfn [(process [w]
(lazy-seq
(when (seq w)
(let [v (vec w)
word (into [] (get-xf v) v)]
(cons word (process word))))))]
(process jumpstart)))
And the most sophisticated L-system is built out of parts with just this little bit of code:
(defn parametric-context-sensitive-system
"Returns a lazy sequence of words from a context-sensitive rewriting
process. Allows a rewrite successor to (optionally) be a function that will
get called with the current context as arguments."
[axiom rules]
(produce (gen (fn [g w]
(comp (modulating)
(rewriting axiom rules g)
(calling g w)
cat)))))