Fork me on GitHub

So, is &env supposed to be available in CLJC files in macros that are being expanded for both sides? E.g. if I call a macro without a reader conditional, I’m seeing nil for &env (which makes sense to me for clj, but I thought it having :ns in env was how we detect if we’re in a cljs compilation context).


(there are no bindings, which is why I expect nil for the regular clj context)


Weird…nevermind. I restarted everything and now it is there. So, that answers that.


So, I have been trying to figure out how to accomplish the “function + macro” with the same name in Clojurescript, but also need the function version to exist in CLJ (in the same ns). I thought I could duplicate this macro magic from Om:, but looking at the generated code I don’t think it actually works, and I think it was broken when CLJ support was added (and no one noticed because the function versions work fine, they’re just not inlined by the macro). So, just checking my understanding after beating my head on the wall trying to do something I’d thought I’d seen done in Om: It seems to me that having macros + functions with the same names in the same namespace will never work in a CLJC file. There is no way to prevent the CLJ code from seeing the macro (which circumvents the function in CLJ). I need higher-order function support in both cljs and clj…so, the only way I see to accomplish this is to put the CLJ stuff in an alternate ns, and have users use a condition reader to require the two different nses but alias them to the same alias…e.g.: foo/server_version.clj

(defn f [] ...)
(defmacro f [] ...) ; faster inlined version
(defn f [] ...) ; slower, but for HO use
(ns app
   (:require #?(:clj [foo.server-version :as foo] :cljs [foo.client-version :as foo])))

(foo/f) ; uses fn in clj, and macro in cljs
(something f) ; uses fn in clj and cljs
That sound right, or am I missing something?


Thanks David


shadow-cljs question - how can I get a REPL connection to a running watcher with cider? I have a very minimal project.clj, which should be enough according to the documentation:

:dependencies [[org.clojure/clojure "1.9.0"]
               [org.clojure/clojurescript "1.10.145"]
               [thheller/shadow-cljs "2.2.8"]]

:profiles {:dev {:dependencies [[cider/cider-nrepl "0.16.0"]]
                   :repl-options {:init-ns ^:skip-aot user
                                  :nrepl-middleware [shadow.cljs.devtools.server.nrepl/cljs-load-file
Say I start the shadow-cljs server (in terminal window):
yarn shadow-cljs watch dev
now (in emacs) I start the clj REPL
M+x cider-jack-in
and to get the cljs REPL I try
(use' shadow.cljs.devtools.api)
(shadow.cljs.devtools.api/nrepl-select :dev)
But it's as if the watcher is not found:
Unhandled clojure.lang.ExceptionInfo missing instance
                  core.clj: 4739  clojure.core/ex-info
               runtime.clj:   11  shadow.cljs.devtools.server.runtime/get-instance!


@fbielejec lets take this to #shadow-cljs


@mfikes trying to run Ambly locally (macOS 10.12.6) I'm getting CFSocketSetAddress bind failure: 48. I am assuming there is some kind of port conflict at work here although if i understand the Ambly source at all it seems to be capable of scanning for an unused port.


I can’t recall if it logs that and then tries another port.


Would have to look at the source


ah, you think that was just it grumbling that it couldn't get it's original port choice


I vaguely recall that behavior, but it has been a while since seeing it do that.


i couldn't see any logging in the code around there, maybe the CFSocket stuff is grumbling under the hood


also i assume the clj command from the instructions is related to clojure 1.9?


or i'm not following something


thanks. yeah i just brewed it up, hadn't gotten around to using 1.9 yet


that specifying git repo's in deps is some weird shit


@mfikes okay, success, it did work... but I'm looking at the Ambly side ( and wondering does this look normal to you? It was also pretty slow although maybe that's a one-off cost of firing stuff up?


Yea, that is normal.


just to be sure, is the repl i get on the clj side from that point being handled by Ambly? Or only the what gets executed by the -e on the comamnd line?


just kill ambly and it stops


Ambly is a Clojure REPL with special code to talk via TCP to the Objective C code.


(sorry, i am recovering from flu so a little slower than normal… well i hope)


right, i was just making sure that i wasn't accidentally talking to the clojure repl


by misunderstanding the example


okay this works really nice once you're up and running Mike, thank you!


good lord you're actually writing the view controllers in cljs 🙂


okay that's a bit more ambitious than my plans


By "Clojure REPL", I mean a regular ClojureScript REPL written in Clojure.


Oh, Ambly has nothing to do with View Controllers @sandbags . That's Goby.


right, a little non-sequiteur as i was just looking at Goby following the instructions for integrating Ambly


For example, there is a Ambly-based project that allows you to use React Native (named natal)


my use case is that I am building a Mac Obj-C app which supports scripting of behaviours, I am looking at Ambly to allow me to use ClojureScript instead of JavaScript for the scripting language


so a property of an Obj-C object would be a script text chunk that gets run on certain events


In that case @sandbags you might need self-hosted ClojureScript


(Assuming you want the scripts to be written in ClojureScript, within that app.)


Oh, yes I wanted to be able to use CLJS instead of JS to write the scripts. I have an aversion to plain JS. You don't think Ambly is the right tool?


possibly i am yak shaving here and should suck it up and plain JS.


@sandbags Right. So Ambly can be used during development if you want to produce an app driven by ClojureScript, where all of the ClojureScript is AOT-compiled to JavaScript that is bundled / shipped with the app. If you want an app that can instead compile and run arbitrary ClojureScript, then self-hosted ClojureScript is good. There is actually an older idea (I think suggested by Nolen) to take the guts of Planck and turn it into a native library that is embeddable into native apps that want this capability.


Something similar could probably also be done with Lumo (which would result in a V8 engine instead of JavaScriptCore)


FWIW, you can also just use self-hosted ClojureScript in a native app. Replete is an example of this. (It is an iOS app that can run arbitrary self-hosted ClojureScript code.)


No problem. Feel free to ping me if you have further questions @sandbags


anyone know of a library that will take a map or a list of maps and lowercase dash the keys? so my api does stuff like { EditListItem: 1, UserName: 'me'} and I'd like it in {:edit-list-item: 1, user-name: "me"} keywordize for clojurescript just does a strait : addition


seems prettys imple to do yourself


just do a map replacing lowercase with lowercase, replacing uppercase with - before uppercase, and remove the first - or skip the first capital


💥 thanks


That’s a great little piece of code golf. I had to stare at it for a minute or so to figure out how that could possibly work.


I’ve never heard it called “selector case” hah


I got the impression that the EDN reader had been superseded by the reader, so I included org.clojure/tools.reader as a dependency, and disabled the js reader. This creates a 900K file after advanced compilation. I didn’t look at transit because the format of EDN is easily human-readable and human-writable. My EDN is coming from DNS TXT records. Two questions. Is there an EDN-only reader that produces more compact code? Should I just use transit?


@pbw it is unlikely that tools.reader is the cause of this size. it is fine to use tools.reader otherwise. transit is a bit faster but that might not matter.


Thanks Thomas. Here are my dependencies.


:dependencies [[binaryage/devtools “0.9.9”] [cljs-ajax “0.7.3"] [org.clojure/tools.reader “1.2.1”] [prismatic/dommy “1.1.0"]]


See anything?


are the devtools included in the advanced build? they shouldn't be.


Of course! Pardon my ignorance, but how can I specify a dependency under :buildname :target :dev?


…but can I…


its not the dependency, its your require for it. you should only be using the devtools.preload via :preloads I think


preloads are not included in advanced builds