Clojurians Log v2

@kwcharllie379 has joined the channel

@bhauman as I can see the figwheel-main doesn't have that issue

I will check what is comming to the read fn

@pauld has joined the channel

@bhauman I think that this is because in figwheel main you are using cljs data readers in figwheel-main/src/figwheel/main/evalback.cljc

that's not on the path

the link I gave you previously is

It's a problem with my understanding then

I will try to investigate it further then

this is where it comes in https://github.com/bhauman/figwheel-repl/blob/master/src/figwheel/repl.cljc#L693

all messages from the client flow through there

and its in figwheel-repl which is maybe why you didn't see it

figwheel repl has all the communication code in it

both the client side and server side

@kwcharllie379 thanks for taking the time to try and understand this

I hope I'm giving you helpful info

Yes you do

But the problem is that I'm just the noob. Trying to wrap my head around all that code.

I think I will do this and I really appreciate your help

Trying to search through the regular figwheel to see where the figwheel-repl is

Ok may I ask some questions please?

sure

OK so the client is emacs or browser which sends the form to the figwheel-repl which responds with the result of the evaluation back to the client. Do I understand that correctly?

As I can see the regular figwheel does not depend on figwheel-repl or I cannot see that ;( Therefore communication is slithly different there

the client is the host javascript environment

the server is the Clojure jvm environment

lein-figwheel does not depend on figwheel-repl

figwheel-main does

figwheel-main only uses the REPL channel for communication

Yes but as I said the problem only occurs in regular figwheel. Figwheel-main can get some different form then regular figwheel. Therefore the figwheel-main is able to parse it.

yes,

Maybe I will just compare the two forms

but if the problem is on the client side where the data is sent then maybe we can fix it most easiliy there?

at the root

oh wait,

OR maybe there is just better error handling in figwheel-main

which I bet may be the case

XD

I really like you 😛

This is the second time we have a conversation

and in this one I also felt like I was a little kid 😛

but it's good

I especially like that you help me understand all the magic in Clj world.

you'd be surprised how straight forward it is once you take the dive, but its really hard/impossible to learning everything at once especially from the CLJS side

I am thinking whether we should just fix the problem by slicing the string or we should take care to provide the same user experience as in figwheel-main.

definitely not just slicing the string

(binding [*default-data-reader-fn* identity]
            (edn/read-string data))

you should experiment with that in the REPL

not in figwheel

until you get a result that works for you

work in the REPL because it will be quicker

than restarting everything and setting it all up

Ok so the strategy is to: 1. Rebind the default-data-reader-fn to handle #js parts. 2. Then use it in the read-msg. 3. Ask you whether it's looking good 😛 4. Do PR and merge

sounds good to me

ok looks like you have to use read-string not edn/read-string

which is too bad

Last question: As I can see https://github.com/bhauman/figwheel-repl/blob/master/src/figwheel/repl.cljc#L690 receives the message from the client (Node.js/Javascript/Cljs ecosystem). It could be already parsed by the client to regular map. But in regular figwheel I just receive the form which is not so easy to parse because I do not have the access to data-reader-fn from cljs?

they both receive raw strings that represent map messages

can't be parsed on the client side

its the same in both cases

;O

It must be different somewhere

Ok I think I will just focus on solving that issue.

Thank you @bhauman

it may not be

different it may be that the error handling is different

OK well I fixed it with this

(binding [*read-eval* false
                *default-data-reader-fn* (fn [tag res] res)]
            (read-string data))

the *read-eval* is required for safety

;(((((((

Very sad I'am 😄

it's not a straight forward problem

and I'd still like to know what's going on

May I please try to tell you how I understand that code?

sure

and remember I'd still like to know what's different in figwheel.main

oh my god I know what the problem is

geeeeez

oh yeah this is rich

So while reading the msg you take the tagged literal and throw it away. So you just receiving the safety string which might be then evaluated to the map.

close, the (fn [tag res] ) recieves a tag and already parsed data as res

and I just return the data

basically ignoring the tag altogether

ok so you got the map (data) and the tag 😛 and you ignore the tag

as you said

Ok so what was the difference in figwheel.main?

What was the problem?

I think it has the same problem, but it handles the error better

Looking into the code I can see it's just pprints therefore the error does not look like an error.

This is what you're talking about?

yep

😄

and it returns nil

which is works just fine

Maybe this is what should be applied to the regular figwheel as well

To ensure consistency between two

they are both so different in this regard

but I'm going to add patch to figwheel.main as well

as its the best solution

PS: In future I will figure the solution by myself so the contribution will be count to me 😛

if you really want to go down the rabbit hole

Yes I want 😛

this is only a problem with ns forms

you can see this if you eval (do #js {}) in your editor buffer cider

in lein-figwheel

it will effortlessly print out "#js {}"

but ns forms are handled differently

by the ClojureScript REPL

https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/repl.cljc#L648

Mein God. Does not understand that code but I will 😛 Need 10 minutes of rest

the clojurescript repl wraps all forms with pr-str except 'ns 'require 'require-macros etc

so its only in this case where an 'ns form returns javascript that this is a problem

thanks for taking the ride 🙂

I'm back

Ok I see 😛

That was pleasure for me to take the lesson from you

I'm still going to mess with it a bit more and try to use clojure.tools.reader.edn/read-string instead as its safer

it was fun for me as well

Last last question 🙂 Is it possible to somehow force the emacs to return to user.ns=> in figwheel-main after the code reloads? The problem is that the compilation succeeds but it does not return to user.ns=> and when I try to evaluate the (println "some-str") form then the result shows on the top of the repl while it should on the bottom.

I'd ask about that in #cider

Ok thanks 🙂 Of course I can switch to repl and just use enter but was looking for a moreprogrammatic way. Thank you one more time for the ride 😉 Have a nice day and see you around.