This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (42)
- # alda (1)
- # beginners (11)
- # boot (24)
- # boulder-clojurians (2)
- # cider (10)
- # cljs-dev (23)
- # clojure (63)
- # clojure-czech (4)
- # clojure-japan (2)
- # clojure-russia (44)
- # clojure-sg (2)
- # clojure-switzerland (2)
- # clojurescript (135)
- # community-development (5)
- # css (4)
- # cursive (19)
- # datomic (34)
- # emacs (2)
- # events (5)
- # funcool (13)
- # hoplon (3)
- # ldnclj (43)
- # ldnproclodo (1)
- # lein-figwheel (7)
- # luminus (7)
- # off-topic (54)
- # om (115)
- # onyx (82)
- # overtone (3)
- # re-frame (6)
- # reagent (15)
- # yada (5)
there’s a proposal for dynamic extend by cemerick a while ago but don’t know if it concretized
is it possible to define a protocol in one project, have it compiled down to js and then refer to that protocol in another project and extend it there?
is it possible to have the project in your project.clj file and extend it from there and then load the two js files one after another?
ie. project 1 has the protocol. i compile the js file. project 2 has project 1 as a dependancy, extends the protocol in there, compiles to another js file
well not for advanced compilation but for the cljs compiler to emit the correct code for the procotol
@emil0r: it is possible to use
^:export on protocol methods, FWIW. I've used this to call upon protocol implementations from Objective-C with
:advanced. (`TableViewDelegate` in Goby, for example.)
@richiardiandrea: there are no Namespace objects in ClojureScript. The ClojureScript wiki is pretty good about covering the language differences between Clojure & ClojureScript.
Sorry for repeating questions, but I think they get lost because of unlucky timing. I will be grateful for responses. * Why Atom doesn't implement ISwap and IReset, but there are special cases in swap! and reset! functions? For performance reasons? * Do watches prevent atom GCing (I guess not, but want to check)?
if someone wants to submit a patch that implements
specify!, that would be welcome
(:refer-clojure :exclude [get set!]) but still get a compile-time exception wrong
set! usage. Any ideas?
@thheller: I get the exception on the line set! is invoked, not where it’s defined, have you tested invocation too?
I assume there’s nothing that can be done about this right? (i.e. file under “known limitation”)
(def set! set!*) it is then. using
set!* in the impl namespace and using set! when used in other namespaces
cljs.reader/read-string is closer to
clojure.edn/read-string than it is to
clojure.core/read-string — is that correct?
Would you take a patch updating the docstrings for read & read-string indicating they’re safe in contrast to clojure.core/read-string? Found this pretty confusing and the only answer I could find was in this lenghty SO answer: http://stackoverflow.com/questions/24661655/clojure-clojurescript-clojure-core-read-string-clojure-edn-read-string-and-c
can I see from outside an API that tells me if a symbol is a special function? kind of like Mike's:
But without the need of copy and pasting the map
(defn repl-special? [form] (and (seq? form) (repl/repl-special-doc-map (first form))))
but it is in a .cljc...maybe we could refactor and expose
how can I print doc of a symbol? I saw that in repl.cljc there is a doc macro, but still, in planck Mike copied over the special-doc-map and repl-special-doc-map
cljs.js is a new thing that very few people actively use & making Clojure like runtime stuff work in it is non-goal
so issuing warnings on
def for a set of reserved words, namespaces and the such could be useful to prevent unexpected behavior for people who misuse
@dnolan, can I ask you a question... I see the -evalute protocol fn is called on each evalution...but in case of a browser, just send-for-eval to it
ah ok I found
I don’t have time to give detailed explanation about how the REPL stuff and cljs.js bits work, sorry
[ClojureScript React Native] I took a stab at enumerating a roadmap with potential avenues of pursuit. Feedback welcome: http://cljsrn.org/roadmap.html
cljs-devtools 0.4.0 is out: https://github.com/binaryage/cljs-devtools/releases/tag/v0.4.0, someone posted it on HN a few days ago https://news.ycombinator.com/item?id=10400800, and it got 100+ upvotes, so I decided to do a new release
@martinklepsch: I’m thinking about packaging it as pre-compiled js extern dependency, something you would put into index.html before you include your app entry point, current devtools/install! way of installing it can be too late, the order of requires is not guaranteed and some code might run when requiring other dependencies. Would that work for you?
much smoother than when we tried with Light Table (though to be expected for the obvious reasons, IntelliJ is mature commercial product)
@darwin: I think it used to not be guarannteed, but I thought there was a fix for that recently
@cfleming: yeah we had to save all the IDE settings so that people got REPLs w/o config, that was kind of annoying
At least I remember this being reported here and I think a fix was also done, but that's probably way behind the search fold
@jaen: typically you call
devtools/install! somewhere in your main entry file (main.cljs) and there are some dependencies, all top-level code from those deps will run before top-level code in main.cljs. That’s something which is not obvious. And trying to put
devtools/install! into first dependency which has no other dependencies didn’t work reliably. Order of deps wasn’t guaranteed as appears in the source file.
I have a feeling that pre-compiled js file with devtools included before your
:main js file would work. I’m just afraid of differences between cljs versions. Imagine someone includes old pre-compiled clsj-devtools with latest app code or vice versa.
@darwin: boot-cljs allows you to inject require’s and init functions to the development shim which is a very useful approach, keeping the complexity of managing development stuff out of your actual application. This won’t fix any inherent loading issues of course. Just thought might be interesting for you
@martinklepsch: just reading it, you mean
:init-fns here https://github.com/adzerk-oss/boot-cljs#options, right? this will be pretty elegant solution, but as you wrote, it won’t solve guaranteed require order in the main file (if the issue is still there)
I would need some magic, which would tell cljs-compiler to add particular require to all files, that would guarentee my code runs first, then all else
:requires are part of build specifications and can be modified by tasks in the build pipeline
yeah so this problem already exists for the constants table (under advanced) and the bootstrapped macros
I can imagine it could bring more problems like 'if you have multiple things which need to run first, how do you specify their order'
it is not that big problem for cljs-devtools, in the bad case, user does not see formatted values but just plain js output the old-way
FWIW I already do this in shadow-build. Add a require to all files, that file does "runtime-setup" (eg. call
(enable-console-print!)) so you don't have to do it in any of your namespaces
it is just annoyance, and puzzling if you don’t exactly understand that your code ran before cljs-devtools install!
actually in plastic I solved it by using goog.require directly. My
:main namespace contains only dependency to
cljs-devtools and a call to
devtools/install! and in index.html after including the main
:main js file I call something like
but it relies on the fact that cljs compiler compiles all namespaces in :optimizations :none mode, not only those required from :main entry point
hmm I just inject another
:main for dev builds, but I think CLJS only allows one
wait, good point, if cljs compiler supported ordered list of :main entry points and did goog.require on them in order, that would solve it
I volunteer to implement it on compiler side, if there was an agreement and no major obstacles
basically nothing I recommended went in ... but I blame only me for not communicating clearly 😞
@thheller: just finished reading the thread, you made really good points there, now I understand a bit more, having collection support for :main would be great, but I can help myself knowing this: In dev mode I might not use :main at all and just goog.require stuff in order I want.