Fork me on GitHub
#cljs-dev
<
2016-08-08
>
dnolen12:08:05

@viebel that’s not a bug, expecting things that restore bindings to work in go blocks is not a reasonable expectation neither in Clojure or ClojureScript

anmonteiro12:08:44

I’ve posted here a few days ago but the messages are gone due to the free Slack limit. I’d appreciate feedback on the patch for this one: http://dev.clojure.org/jira/browse/CLJS-1508 (add :rename option to the NS form). The approach used in the patch was to add the rename map for a form under the uses and use-macros entries in the env map. so instead of, say an entry like {intersection clojure.set} it becomes {foo {intersection clojure.set}} This is working quite nicely but one disadvantage I see a priori is tooling that might expect those maps to be strictly from symbol to symbol, when now in some cases it is from symbol to a map of symbol->symbol

anmonteiro12:08:52

I wonder if there’s a better way to implement that, or if it is OK to break some tooling downstream that works under such assumption

dnolen12:08:19

@anmonteiro: adding a new conditional check is usually a sign of things getting more complicated

dnolen12:08:47

what’s the thinking here? why is ns conditionally encoded as a map?

dnolen12:08:05

ok I see you covered that, yeah my first reaction is this changing a lot of expectations

dnolen12:08:30

but it also makes it more complicated to understand what’s going on (in a place that’s already really complicated ;)

dnolen12:08:51

@anmonteiro: I’m also a bit confused why this path needed to be taken? :rename should work just like :use, symbol -> qualified symbol

anmonteiro13:08:47

@dnolen: I can agree that it does complicate things a bit. Are you saying that putting the renamed symbol in the key and the fully qualified (original) symbol in the value would work?

anmonteiro13:08:02

I think at the moment values are supposed to be the NS

anmonteiro13:08:09

or at least that was the impression I had

dnolen13:08:31

oh hrm, you might be right ...

anmonteiro13:08:53

that’s why I took that approach

anmonteiro13:08:08

but I can definitely see why it might not be the best way to do things

anmonteiro13:08:27

I kinda hate the conditional check for map vs symbol

dnolen13:08:21

@anmonteiro: hrm but this expectation of symbol -> ns is really specific to a construct like :use

anmonteiro13:08:30

However, from where I see it, the renamed symbol needs to be in the :uses/`:use-macros` key

dnolen13:08:32

so the :rename map can just be different

dnolen13:08:52

symbol -> fully-qualified symbol

anmonteiro13:08:12

@dnolen: so the idea would be to create a new :renames entry in the env map?

dnolen13:08:37

yes might be a bit of work but I think allows us to not muck around with existing stuff

anmonteiro13:08:08

gotcha, let me play around with that

anmonteiro13:08:33

@dnolen: I’m foreseeing that resolve-var would probably need to be tweaked in that case

dnolen13:08:37

that’s right

anmonteiro13:08:55

cool, I think I have the big picture

anmonteiro13:08:08

I’ll report back when I have something

anmonteiro13:08:14

thanks for the feedback

Yehonathan Sharvit18:08:51

@dnolen: regarding with-redefs and core.async - any chance to go for one of the solutions suggested here http://dev.clojure.org/jira/browse/CLJS-1634 ?

dnolen19:08:24

@viebel maybe but it’s just a not a priority

dnolen19:08:01

I haven’t had any time to look at the suggested solution and there are just too many other pressing things in the queue

Yehonathan Sharvit19:08:57

I understand. Maybe you have a workaround/suggestion for my use case in Klipse. In the latest version, I have redirected all the calls to print to the bottom right text area. I’ve done that by setting *print-fn* before calling eval using with-redefs

Yehonathan Sharvit19:08:52

Is there a good way to redirect the calls to print when using self-hosted eval-str?

Yehonathan Sharvit19:08:30

@dnolen: is there a better way than with-redefs?

dnolen19:08:51

@viebel sorry I can’t help you further with your problem right now

dnolen19:08:08

I would ask the question in #C03S1L9DN, people must have workarounds for similar cases

darwin19:08:02

@viebel: I had a possible performant solution for async-aware binding in my head for quite some time, we can talk, if you have time

darwin22:08:51

dumped the idea here (for anyone interested): https://github.com/binaryage/cljs-zones