This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-05
Channels
- # beginners (23)
- # boot (84)
- # braid-chat (2)
- # bristol-clojurians (1)
- # cider (53)
- # cljs-dev (34)
- # cljsrn (13)
- # clojure (138)
- # clojure-dusseldorf (5)
- # clojure-italy (1)
- # clojure-russia (164)
- # clojure-uk (41)
- # clojurescript (80)
- # clr (2)
- # core-async (6)
- # core-logic (25)
- # core-matrix (14)
- # cursive (10)
- # data-science (4)
- # datomic (4)
- # emacs (3)
- # funcool (6)
- # hoplon (127)
- # jobs-discuss (4)
- # keechma (36)
- # ldnclj (5)
- # lein-figwheel (5)
- # off-topic (5)
- # om (155)
- # onyx (72)
- # overtone (16)
- # parinfer (39)
- # planck (3)
- # protorepl (1)
- # re-frame (11)
- # reagent (5)
- # untangled (22)
is there a way to use macros to change the way syntax is parsed? let’s say i wanted to write css in clojure within a macro…
[.class-name { :padding 1em 2em 1.5em 2.5em }]
is it possible to write a macro that can actually handle 1em
without barfing? The easiest solution is just to wrap that in text: ”1em 2em 1.5em 2.5em”
, but I don’t want easy, I want convenient 😛.I can think of a lot of alternatives such as def
-ing each and every potential property .. (def flex “flex”)
for example, but that sounds like a maintainability nightmare
macros are given forms which have already been read. the reader will not read symbols starting with numbers
you could try to do something crazy with tagged literals, like #em 1
... but strings seem fine to me
Thanks @tomjack . I have read through a couple of macro tutorials but none of them touched on anything like changing the way tokens are parsed, so I wasn’t sure if that’s an impossibility or just rare.
@danielpcox Reagent patterns are described here: https://github.com/Day8/re-frame/wiki/Using-Stateful-JS-Components D3 links towards the end, under "Further Examples"
why is there the .- javascript property accessor in clojurescript when it breaks under advanced compilation?
it can, but html*
being a macro means that gensymmed prefix#
symbol is passed in, instead of its value
you have to generate the prefix
at compile time in order to make use of its value in a macro
I had it like that in the beginning but changed it to a macro for testing it using macroexpand
. If html*
is a function I can't test how it transforms its input because it'll evaluate it's body - and I need it unevaluated. All I want to achieve is annotate the data before I pass it down to sablono.
CLJS will evaluate the generated code (including for
loops etc.) and will pass the evaluated data to html*
. I need the unevaluated data.
@lwhorton: look for inspiration here[1], I’m using Garden[2] with some sugary macros[3] on top of it. Instead of 1em
I would write (em 1)
- brain can adapt easily
[1] https://github.com/darwin/faceboard/tree/master/frontend/styles/faceboard/css
[2] https://github.com/noprompt/garden
[3] https://github.com/darwin/faceboard/blob/master/frontend/styles/faceboard/lib/helpers.clj
@dm3: haven’t touched it for more than a year, so I don’t remember the details, here is the code: https://github.com/darwin/faceboard/blob/master/frontend/styles/faceboard/lib/helpers.clj#L30-L39
so it behaves like css, not randomly when you re-declare some property within one block
Anyone who uses planck? How do I do to preload it with all my libraries in .m2
? I tried planck -c ”~/.m2/repository”
and then (require …)
but it couldn’t find it.
@vikeri: Planck supports classpath semantics, so you'd have to provide a colon-delimited list of all jar files (same would be true for ClojureScript, I believe) http://planck-repl.org/dependencies.html
@mfikes: Alright, so when I go in to find the reagent jar and start it, I would also have to include every dep that reagent has?
Starting it with planck -c reagent-0.5.1.jar
works but gives me this error when trying to require reagent.core
:
No such namespace: cljsjs.react, could not locate cljsjs/react.cljs, cljsjs/react.cljc, or Closure namespace ”cljsjs.react"
@vikeri: Right. One approach is to use lein
to generate the classpath to feed to Planck. (Having said that, I'd be surprised if Reagent works in self-hosted ClojureScript).
Alright, well my use case that I want to go in and fiddle with functions in different libraries without starting a project with them. Maybe this is not intended use for planck?
Speaking of fiddling, I suppose that http://cljsfiddle.com works with Reagent with self-hosted ClojureScript so… with Planck the issue would be the lack of browser capabilities (perhaps top-level window object etc.)
@vikeri: Sure, you should be able to use Planck to explore functions in libraries—the trick would be loading them. Planck doesn’t attempt to solve the dependency problem and just supports classpath.
@mfikes: Hmm ok, if I get time I might look at doing something to more easily browse the libraries already loaded in ~/.m2
would be awesome to have something like planck —libraries=reagent:foo:bar:doo
where those libs have to be present in your ~/.m2
folder.
One could imagine using lein the first time just to download the deps and generate the classpath, and then apply magic to make subsequent planck startups quick
Right, you could use Planck itself to form the classpath via something like https://gist.github.com/mfikes/9503aa2555aac1cafaf4#file-cljs-cli-md
@vikeri: This might get you by for now, if you want to just fool around and not use lein
and project.clj
: https://gist.github.com/mfikes/39be3c7d966f6910bc72b1d0fc929ea7
I created a #C0Y3CSPHQ channel so chats like the above can occur in there for people who are interested in Planck.
thanks @darwin. I did write a 3-arity version of ems to support num, topbottom left right, and t r b l like normal css. those sugar macros look nice, though.
I have an om.next app using sablono that throws react key warnings only the first time a certain component is mounted and then never again regardless of how many times it’s mounted/unmounted. Any ideas?
Yesterday I was asking about reading a file in cljs ( https://clojurians.slack.com/archives/clojurescript/p1459785461002876 ), and I realize now that there was some confusion in my understanding of some of the help I was getting. I was asked if the value I was passing to a macro was known at compile time, and I said yes, but that was wrong. For testing purposes that value currently is hardcoded at compile time, but at some point I will be moving to building the filepath string at runtime, since it will always follow the same pattern and there will be a lot of them. Sorry about that misunderstanding :P So is there a way to pass variables at runtime to a macro from cljs?
@numberq: macro expands at compile time, it has no chance to know what value the symbol will have at runtime, so you cannot slurp file at compile time with a path taken from the runtime-value of passed-in symbol
Hmm I was afraid of that. So my only bet is to either hardcode every filepath or to use Node.js like you suggested yesterday?
you can still “compute” file paths, if that computation can be performed at compile time
so the question is, if you will be building file paths at runtime, does it really need to be at runtime? don’t you have all inputs known at compile time?
I have all inputs known at compile time, but I don't know when they'll be used. Essentially, when an event is triggered, a random map will be loaded. The filepath will look something like "/assets/maps/map#.txt", where # identifies which map it is.
So load-map could be called with whatever map is randomly chosen, and I was hoping to do that in one or two lines with something like (def map-file "whatever/map.txt") (load-map map-file)
Or rather I should say, I'd rather not have all inputs known at compile time. Unless I'm mistaken, wouldn't that mean having a separate call to (load-map)
for everything single map there is?
Let’s see if I understand your problem: You have quite small set of map files in some folder. And you want to use those files dynamically during runtime (in reaction to some events). You cannot access filesystem during runtime.
My solution would be:
1) write a macro load-maps
which lists all maps in the folder and slurps them into a clojure map key-ed by their filenames (when called this happens during compile-time executed by clojure)
2) in cljs (def maps-in-memory-cache (load-maps))
3) in cljs write a function, which can lookup a requested map in the cache, something like (defn load-map [name] (get maps-in-memory-cache name))
long-story-short: load-map is dynamic, load-maps is static macro which runs at compile-time and builds a static map of file contents for you
That sounds like a good idea. The number of maps will be a bit larger than "quite small" eventually, but I don't think it will get into performance or memory affecting numbers. Thanks!