This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-10-23
Channels
- # announcements (1)
- # aws (11)
- # beginners (28)
- # boot (235)
- # business (1)
- # cider (19)
- # clojure (34)
- # clojure-china (1)
- # clojure-czech (10)
- # clojure-japan (7)
- # clojure-poland (3)
- # clojure-russia (84)
- # clojure-sg (4)
- # clojure-uk (3)
- # clojurescript (114)
- # community-development (4)
- # core-async (15)
- # cursive (8)
- # datascript (5)
- # datomic (6)
- # editors-rus (27)
- # events (2)
- # hoplon (61)
- # jobs (2)
- # ldnclj (56)
- # ldnproclodo (5)
- # lein-figwheel (232)
- # luminus (1)
- # off-topic (5)
- # om (215)
- # onyx (436)
- # overtone (8)
- # re-frame (3)
- # reagent (3)
So, I am currently refactoring my code to compile into 1 file instead of having to manually require goog
and what not. But since the change I am getting WARNING: Required namespace not provided for dmedit_om.core
even though cljsbuild once / auto
works completely fine. Just figwheel can't find that namespace
cljsbuild looks like this:
{:id "frontend:dev"
:figwheel true
:source-paths ["src_front" "src_dev"]
:incremental true
:jar true
:assert true
:compiler {:main "dmedit_om.core"
:output-to "app/js/front.js"
:externs ["app/externs.js"]
:warnings true
:elide-asserts true
:output-dir "app/js/out-frontend"
:asset-path "js/out-frontend"
:optimizations :none
:pretty-print true
:output-wrapper true
}}
]}
tried to upgrade figwheel to latest version, now running from master branch to troubleshoot my problem: figwheel is unable to reload some namespaces right after first load, it chokes on this line: https://github.com/bhauman/lein-figwheel/blob/master/support/src/figwheel/client/file_reloading.cljs#L229
that require call works for most files, request-url is this: file_reloading.cljs?rel=1445600395142:229 ! ../plastic/util/dom/shim.js file_reloading.cljs?rel=1445600395142:229 ! ../plastic/main/editor/toolkit/id.js file_reloading.cljs?rel=1445600395142:229 ! ../plastic/onion/api.js file_reloading.cljs?rel=1445600395142:229 ! ../re_frame/logging.js file_reloading.cljs?rel=1445600395142:229 ! ../re_frame/utils.js file_reloading.cljs?rel=1445600395142:229 ! ../re_frame/frame.js
cache-path in exception is reported as '/Users/darwin/pws/plastic/lib/_build/main/goog/string/stringformat.js'
if I understand it well, goog.* namespaces are not present in cljs_deps.js, they are somehow implicit
so requiring them using url path does not work in my case, they need to be required using namespace name
ah, this is node’s js/require, it is not goog.require, forgot about my previous comment
I was able to fix my problem with this code snippet: (if (= (first request-url) ".") (js/require (string/join "/" ["." ".." request-url])) (js/require (string/join "/" ["." ".." ".." "goog" request-url])))
it looks like normal namespaces have requires-url in the form ../<library>/path
, but goog namespaces are just in the form path
, it looks like js/require is picky about that form and works only when I convert them to ../goog/path
<< @bhauman
unfortunately I cannot step into js/require in my setup, so I can tell what is causing it inside
it makes little sense, because ["." ".." request-url] and ["." ".." ".." "goog" request-url] should be equivalent from filesystem perspective
let me revert the changes and try it again with original unmodified code, just to be sure
this is strange as I was copying this line right here https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/bootstrap_node.js#L75
I was about to give up but tried the cache-path (it holds full absolute path) and it worked, that lead me to ["." ".." ".." "goog" request-url] discovery
what is this? https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/bootstrap_node.js#L65-L69
what about trying first your original code, if it fails trying either cache-path or my hack, raise error after both fail
and now I recall I had problems with goog.string.format before, because it does not follow naming convention
there are other non-goog namespaces which failed on me, /Users/darwin/pws/plastic/lib/_build/main/cognitect/transit.js /Users/darwin/pws/plastic/lib/_build/main/com/cognitect/transit/types.js /Users/darwin/pws/plastic/lib/_build/main/plastic/main/servant.js
btw using cache-path there is maybe not the best thing, I would mention what was exactly passed into js/require
thanks for helping out, I’m good now, I can live with that double reload, and keep my hack someone discovers a solution
@nowprovision: because I suspect that you need to add the :source-paths from your build to the the :source-paths in your project.clj
you know you can use a :main config and that gets handled for you automatically with :figwheel true
I just know there is some leiningen magic, last time I put the key on wrong level of my project.clj and was wondering why it does not work as expected, some samaritan helped me on this channel
@dvcrn: that underscore is your problem more than likely dmedit_om.core
should be dmedit-om.core
@bhauman: btw. once upon a time, I had a working setup where typing commands in figwheel repl would echo javascript results in devtools console, this is handy when using cljs-devtools, then you can inspect complex results in devtools console, and not rely on pr-str to be sent back to server
I had implemented it as a repl-plugin: https://github.com/darwin/plastic/blob/master/src/dev/plastic/dev/figwheel.cljs#L31-L32
maybe it is time to revisit this with new figwheel, if there could be more elegant implemetation, as you can see, I ended up copy&pasting a bunch of code
the problem was that javascript sent to be eval’d on client side already contains wrapping in pr-str and this differs between REPL implementations
https://github.com/bhauman/lein-figwheel/blob/master/support/src/figwheel/client.cljs#L43
I would welcome some work on the REPL/printing loop. I know there is a kludge in there
but still the problem of wrapping the code with pr-str is there, I would like to have a hook which would pre-process code just before it is passed to utils/eval-helper
so I have to do something like this: https://github.com/darwin/plastic/blob/master/src/dev/plastic/dev/figwheel.cljs#L14-L24
ah, now I see that the print-fn binding was there before, I just copied it in my version of eval-javascript**
server-side repl code prepares javascript which has to be executed on client-side and result sent back, but it pro-actively wraps that code with some flavor of converting it into string, so it gets back plain string
but that is bad for me on client side, when I want to log result of eval into devtools console
ok, maybe sidecard is using standard clojurescript repl code which does that, I’m not familiar with REPL stuff
but now when I read the code again, I see utils/eval-helper, so I can just monkey-patch that fn and do my rewriting there
I would replace that function with my version, which rewrites incoming code to be evaluated, evals my version, logs result and then calls pr-str or what was needed by original code and returns it back
got it working again: https://dl.dropboxusercontent.com/u/559047/repl-echoing-in-devtools-console.png and the implementation is not that hacky anymore: https://github.com/darwin/plastic/blob/master/src/dev/plastic/dev/figwheel.cljs I should probably describe this technique on cljs-devtools wiki
@frankhale: can you verify something for me?
iTerm2+ hotkey window + rlwrap + lein fighweel is pretty usable repl for me most of the time, I don’t have to go to IntelliJ
are you familiar with TotalTerminal’s Visor feature? iTerm2 has that, but it is somewhat hidden
that .runInThisContext branch is there because of Atom, normally we should call standard eval-helper code
you can eval and print anything and it does not have to call any printing at all, but you still want to see the result in devtools
btw. I noticed call to str here: https://github.com/bhauman/lein-figwheel/blob/master/support/src/figwheel/client.cljs#L148, it is probably wrong
I know you want to be on safe side, but from what I saw it is (n)REPL’s job to prepare value it wants back
so far all repls I saw called pr-str, but some might want to return some structured data for example, for whatever reason
the call you are overwritting is a call to pr-str which in turn call cljs.core/*print-fn*
but still the code inside can do some printing and we want to rewrite only the outer-most pr-str, hacking print-fn would require some ugly logic
np, I think this is design decision in REPL “standard” that repl will prepare code on server side and wants client to execute it as-is and return the result
so most repls wrapped that with pr-str, because that was safe and what they want, "give me string back"
so we cannot fix it easily for all repls, but covering some most popular cases can be good enough solution
maybe warning in case of unrecognised code snippet pattern, and letting people provide their own rewriting function in case of troubles
right now if my rewriting does not rewrite the code it is not big deal, it will start silently printing strings instead of rich js-objects
not end of the world, but maybe issuing a warning about unsupported repl would be much better