Fork me on GitHub
#lein-figwheel
<
2015-10-23
>
dvcrn05:10:46

hey guys!

dvcrn05:10:57

I have a little problem with figwheel and was wondering if anyone can help out

dvcrn05:10:07

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

dvcrn05:10:35

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
                                   }}
                       ]}

dvcrn05:10:03

I can work fine with lein cljsbuild auto but of course I'd rather have figwheel šŸ˜›

darwin11:10:43

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

darwin11:10:07

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

darwin11:10:29

but then it encounters request-url 'string/stringformat.jsā€™ and fails

darwin11:10:47

cache-path in exception is reported as '/Users/darwin/pws/plastic/lib/_build/main/goog/string/stringformat.js'

darwin11:10:05

which seems to be correct, I double-checked that the file exists in the filesystem

darwin12:10:44

the problem is with all goog.* namespaces

darwin12:10:56

if I understand it well, goog.* namespaces are not present in cljs_deps.js, they are somehow implicit

darwin12:10:37

so requiring them using url path does not work in my case, they need to be required using namespace name

darwin12:10:38

ah, this is nodeā€™s js/require, it is not goog.require, forgot about my previous comment

darwin12:10:18

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])))

darwin12:10:26

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

bhauman12:10:36

you are using 0.4.1

darwin12:10:00

yes, current HEAD, had the same issue with published 0.4.1 from clojars

darwin12:10:28

it worked for me in previous version

darwin12:10:38

decided to upgrade today

darwin12:10:22

unfortunately I cannot step into js/require in my setup, so I can tell what is causing it inside

darwin12:10:26

I canā€™t tell

darwin12:10:49

also requiring cache-path works

bhauman12:10:50

but you were using 0.4.0 and it worked correct

darwin12:10:40

it makes little sense, because ["." ".." request-url] and ["." ".." ".." "goog" request-url] should be equivalent from filesystem perspective

darwin12:10:34

let me revert the changes and try it again with original unmodified code, just to be sure

bhauman12:10:00

yeah that is weird

darwin12:10:13

yep, does not work

darwin12:10:49

but (js/require cache-path) works in all cases

darwin12:10:26

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

bhauman12:10:28

which appears to work

darwin12:10:56

maybe they never ran into goog. ns includes?

bhauman12:10:16

not very likely

darwin12:10:45

that looks similar to my hack

bhauman12:10:19

its basically the same as calculating the cache-path

bhauman12:10:52

problem with cache-path is that I don't think it will work on windows

darwin12:10:28

what about trying first your original code, if it fails trying either cache-path or my hack, raise error after both fail

darwin12:10:38

feels hacky

darwin12:10:48

but it would work without testing for dots

bhauman12:10:19

so a minimal case would be for me to require stringformat?

bhauman12:10:00

your code suggestion seems promising but I have no idea why its working

darwin12:10:22

I have just checked my deps_cljs and there are plenty of goog. deps

bhauman12:10:35

are you on el capitain?

darwin12:10:39

in my case the problem affects only goog.math.Long and goog.string.format

darwin12:10:24

and now I recall I had problems with goog.string.format before, because it does not follow naming convention

darwin12:10:30

dots do not replace with slashes

darwin12:10:56

file path is goog/string/stringformat.js

bhauman12:10:56

yeah but the request url is still correct

darwin12:10:55

yes, it is\

darwin12:10:36

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

darwin12:10:51

so this may not be goog.* related

darwin12:10:25

Iā€™m not sure if those are failures caused by previous failings

bhauman12:10:44

so an error is being throw because it can't find the file

bhauman12:10:56

just making sure

darwin12:10:09

js/require throws and your catch block reports

darwin12:10:18

(utils/log :error (str "Figwheel: Error loading file " cache-path))

bhauman12:10:45

if you use the cache-path do reloads work?

darwin12:10:03

btw using cache-path there is maybe not the best thing, I would mention what was exactly passed into js/require

darwin12:10:14

yes, cache-path works without problems

bhauman12:10:17

like you can change the code and the new behavior shows

darwin12:10:50

what do you mean?

darwin13:10:03

by new-behavior?

bhauman13:10:39

just because you didn't error out doesn't mean you are actually getting new code

bhauman13:10:49

require pulls from the cache

darwin13:10:15

ah, let me test that, this is the initial reload thing, when I fully reload

darwin13:10:27

interesting, live reloading works, but it executes twice for some reason

darwin13:10:43

this might be unrelated and some other issue

bhauman13:10:50

well I'm going to have a look at this this morning

darwin13:10:11

let me restart my whole figwheel and rebuild everything from scratch

darwin13:10:32

maybe it was caused by my experiments

bhauman13:10:27

actually it may be reloading twice

bhauman13:10:48

do you have figwheel-always on your namespace?

darwin13:10:01

no, I donā€™t use figwheel-always

bhauman13:10:01

and you are chaning your namespace?

bhauman13:10:13

you shouldn't

darwin13:10:24

Iā€™m changing some root namespace, which is not a dependency of anything else

darwin13:10:30

so it reloads just this one file

bhauman13:10:43

alrighty well this is fun

darwin13:10:46

and yes, cache-path version of js/require executes new code

bhauman13:10:25

well that may be the way to go

darwin13:10:42

when I revert the code to unmodified HEAD, the reloading twice is still present

darwin13:10:47

so it wasnā€™t caused by that change

darwin13:10:38

thanks for helping out, Iā€™m good now, I can live with that double reload, and keep my hack someone discovers a solution

darwin13:10:48

I can imagine not that many people use nodejs setups

bhauman13:10:02

cool thanks for exploring this

darwin13:10:02

Iā€™m inside Atom, so it is even more edge case

bhauman13:10:24

could have mentioned that šŸ˜‰

bhauman13:10:27

no biggie. but its good to know just in case I can't reproduce

bhauman13:10:42

@nowprovision: because I suspect that you need to add the :source-paths from your build to the the :source-paths in your project.clj

darwin13:10:44

@bhauman: found the cause of double-reload, Iā€™m focusing on two builds

darwin13:10:23

this worked previously, now it seems the file reporting gets registered twice

darwin13:10:02

it prints Figwheel: notified of file changes + bunch of other info twice

bhauman13:10:08

that could happen if the two builds are overlapping their watches

bhauman13:10:50

their source-paths and you are editing something that affects both builds

darwin13:10:59

they do indeed

darwin13:10:15

it is the same sources once build for dev and once for devcards

darwin13:10:32

so I have to specify which build Iā€™m insterested in on client side?

bhauman13:10:16

are you calling fw/start manually

bhauman13:10:30

if so then yes you need to supply a build-id

darwin13:10:39

ok, good, thanks

bhauman13:10:36

you know you can use a :main config and that gets handled for you automatically with :figwheel true

darwin13:10:51

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 simple_smile

darwin13:10:32

I needed my own hacks of figwheel, particulary specify :eval-fn

darwin13:10:36

so I have to call it myself

bhauman13:10:59

oh yeah thats right simple_smile

bhauman13:10:36

@dvcrn: that underscore is your problem more than likely dmedit_om.core should be dmedit-om.core

darwin13:10:03

@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

darwin13:10:42

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

darwin13:10:18

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

darwin13:10:39

I had to strip that

bhauman13:10:43

did you try enable-repl-print! ?

darwin13:10:59

no, Iā€™m not aware of this one

darwin13:10:05

is it something new?

bhauman13:10:13

I would welcome some work on the REPL/printing loop. I know there is a kludge in there

bhauman13:10:25

I haven't had time to work through it

darwin13:10:30

reading the code of eval-javascript**, looks promising

darwin13:10:52

print-fn binding wasnā€™t there last time I looked

darwin13:10:14

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

darwin13:10:28

something like :eval-fn, in figwheelā€™s client config

bhauman13:10:30

by the way the code of 0.5.0-SNAPSHOT maximises extention and hackability

bhauman13:10:49

in sidecar

darwin13:10:19

fixing sidecar is not enough, nREPL from IntelliJ does its own thing

bhauman13:10:18

you mean for printing? there is some middleware thing

darwin13:10:02

ah, now I see that the print-fn binding was there before, I just copied it in my version of eval-javascript**

bhauman13:10:35

so where is that call to pr-str?

darwin13:10:50

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

darwin13:10:14

but that is bad for me on client side, when I want to log result of eval into devtools console

darwin13:10:24

because I log string value, not the real value

bhauman13:10:38

but that is in ClojureScript right not in figwheel?

darwin13:10:22

ok, maybe sidecard is using standard clojurescript repl code which does that, Iā€™m not familiar with REPL stuff

darwin13:10:42

but it differes between sidecarā€™s REPL and IntelliJ REPL slightly

darwin13:10:59

and I can imagine other nREPL implementations can do their own thing

darwin13:10:33

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

darwin13:10:49

would be nice to have an official hook for it, so it does not break

darwin13:10:08

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

darwin13:10:31

rewriting and applying pr-str back would be nREPL-specific

bhauman13:10:05

wait didn't you add :eval-fn config option??

darwin13:10:43

I did, but for some other reason simple_smile is eval-fn the thing which is called by eval-helper?

darwin13:10:51

if yes, problem solved, let me see

bhauman13:10:15

i think you added that code :

darwin13:10:58

simple_smile Iā€™m sorry, context flush happened šŸ˜‰

bhauman13:10:20

no big deal at all, heppens to me every minute

bhauman13:10:45

have to go eat simple_smile

darwin13:10:57

thanks, bye

darwin14:10:31

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

bhauman14:10:21

much nicer!

bhauman14:10:23

@frankhale: can you verify something for me?

darwin14:10:14

iTerm2+ hotkey window + rlwrap + lein fighweel is pretty usable repl for me most of the time, I donā€™t have to go to IntelliJ

darwin14:10:30

I mean to IntelliJ Cursive REPL

bhauman14:10:42

what's hotkey window?

darwin14:10:00

are you familiar with TotalTerminalā€™s Visor feature? iTerm2 has that, but it is somewhat hidden

darwin14:10:46

On my external keyboard I have it bound to CTRL+~, like in old good Quake days

bhauman14:10:00

but its like the tilde thing

bhauman14:10:16

it's hard to ship code from your editor though

bhauman14:10:43

if we could firgure that out it would pretty much rock

bhauman14:10:40

wouldn't it be great to ship editor commands out to iTerm?? a nice seperation

bhauman14:10:57

change ns. eval. et.c

darwin14:10:59

well, the code is not really plastic-specific, only eval function

darwin15:10:46

that .runInThisContext branch is there because of Atom, normally we should call standard eval-helper code

darwin15:10:01

other than that, this can be used by anyone

darwin15:10:38

I can imagine this could be optional part of figwheel, hidden behind some flag

bhauman15:10:14

it would be interesting to chase down the code that you are having to replace

bhauman15:10:09

and I would think that its calling print-fn right?

bhauman15:10:21

*print-fn*

darwin15:10:55

no, this is not related to print-fn

darwin15:10:23

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

bhauman15:10:03

I think you are right about that

darwin15:10:34

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

darwin15:10:11

so far all repls I saw called pr-str, but some might want to return some structured data for example, for whatever reason

bhauman15:10:18

the call you are overwritting is a call to pr-str which in turn call cljs.core/*print-fn*

darwin15:10:52

ok, didnā€™t know that

darwin15:10:27

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

darwin15:10:45

if you mean I could try override print-fn

bhauman15:10:08

well I think it may be possible for you in your case to do that

bhauman15:10:32

actually it doesn't call *print-fn* it just returns a string

bhauman15:10:59

sorry about that

bhauman15:10:50

this is kinda sticky, would be nice to provide the appropriate hooks

darwin15:10:58

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

darwin15:10:36

so most repls wrapped that with pr-str, because that was safe and what they want, "give me string back"

darwin15:10:32

so we cannot fix it easily for all repls, but covering some most popular cases can be good enough solution

darwin15:10:00

maybe warning in case of unrecognised code snippet pattern, and letting people provide their own rewriting function in case of troubles

darwin15:10:15

so they can help themselves without rewriting this again from scratch

darwin15:10:08

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

darwin15:10:49

not end of the world, but maybe issuing a warning about unsupported repl would be much better

frankhale15:10:04

@bhauman: sure, what's up?

bhauman15:10:08

I would really like to understand the whole situation

bhauman15:10:31

I was wondering if you could check a node reloading thing on windows

bhauman15:10:29

I just want to know if you use cache-path on that line if it still works

frankhale15:10:08

ok, I will check and report back

bhauman15:10:08

make sense (js/require cache-path)

bhauman15:10:19

thank you so much

frankhale15:10:12

reloading still works

bhauman15:10:57

@darwin we'll go with class-path

darwin15:10:45

great! ping me when you want me to test it, I would switch to your version

frankhale15:10:46

anytime šŸ˜ƒ

bhauman15:10:05

just pushed it to master

darwin15:10:45

@bhauman: works like a charm, in both of my builds, btw. the devcards build is a plain html app

bhauman15:10:50

that is cool

darwin15:10:25

with working figwheel Iā€™m back in action simple_smile going to get a coffeeā€¦