Fork me on GitHub
#cljs-dev
<
2016-06-05
>
anmonteiro11:06:56

alter-meta!’s docstring says: Atomically sets the metadata for a namespace/var/ref/agent/atom

anmonteiro11:06:04

it doesn’t seem to work for Vars, though

anmonteiro11:06:55

because it call this: (set! (.-meta iref) (apply f (.-meta iref) args)) and the Var deftype doesn’t have a meta field, but _meta instead

anmonteiro11:06:02

is this known/expected or should I file a JIRA ticket?

anmonteiro11:06:15

the same for reset-meta!

bronsa11:06:17

it seems that the bigger issue is that they're not backed by a protocol

bronsa11:06:59

in clj alterMeta and resetMeta are found in the IReference interface

bronsa11:06:36

cljs does have IWithMeta which is essentially clj's IObj but it seems to be missing the abstraction for objects with mutable metadata, IReference

anmonteiro11:06:03

@bronsa: so in a perfect world alter-meta! and reset-meta! would just defer to alterMeta and resetMeta or whatever we’d end up calling it in the IReference protocol?

anmonteiro11:06:12

seems cleaner

anmonteiro11:06:25

my guess is these functions predate the Var implementation and they worked fine just for atoms

dnolen18:06:23

@mfikes: re 1668, we actually need to be able to write two specs, one for the runtime and one for the macro syntax checking

dnolen18:06:46

so what I’m suggesting is to just have fdef be macro ns aware so we can define the spec twice

mfikes18:06:49

@dnolen: Yes… I realized that what I proposed isn’t consistent with JVM ClojureScript

mfikes18:06:11

So, macro specs with JVM ClojureScript are likely to be placed in the macro namespace itself

dnolen18:06:30

and by doing it this way we have portable specs for both runtime and macros

dnolen18:06:44

even if they share the same name

mfikes18:06:57

Let me try an experiment with the 2nd patch. I bet that if I put a spec in a macro namespace (say, at the bottom of the file), where that spec uses an unqualified symbol, it will automatically resolve by adding $macros suffix without the developer being aware.

dnolen18:06:21

@mfikes: heh even better if this just works 🙂

anmonteiro18:06:26

@dnolen: any thoughts on the alter-meta! stuff for vars I mentioned earlier?

mfikes18:06:31

(Starting to better understand the corner cases that need to be handled 🙂 )

dnolen18:06:03

@anmonteiro: it’s harder than it seems

dnolen18:06:11

vars are emitted at compile time

dnolen18:06:40

that is two var expressions aren’t the same object

dnolen18:06:25

so would need to consider this aspect of the problem - perhaps vars could share their state through an atom or something?

anmonteiro18:06:06

@dnolen: I wasn’t aware of that

anmonteiro18:06:20

what about the IReference protocol?

anmonteiro18:06:28

should we copy Clojure there?

dnolen18:06:09

it doesn’t seem particularly useful to me

dnolen18:06:24

at least not without considering how keeping vars in sync will actually work first

anmonteiro18:06:30

it would really only apply to vars and atoms, I believe

anmonteiro18:06:58

@dnolen: OK thanks for the input. where in the codebase is the var emission code?

dnolen18:06:01

yeah this is uglier than it seems

dnolen18:06:11

for example you emit a var in a bunch of places then redef at the REPL

dnolen18:06:53

I suspect that just works in Clojure

dnolen18:06:59

unclear how to make that work in ClojureScript

dnolen18:06:28

so would want to think through this first before considering IReference

anmonteiro18:06:29

makes sense. I was just wondering where vars are emitted so I could go through that code path

dnolen18:06:03

line ~979 in analyzer.cljc for the analysis bit

dnolen18:06:24

~327 in compiler.cljc for the emission

mfikes19:06:24

Yes… one pair of specs works uniformly in both JVM and bootstrap ClojureScript. Writing up example in the ticket for reference. 🙂

dnolen19:06:52

@mfikes: excellent, better when there’s nothing to do 🙂

mfikes19:06:40

@dnolen: Yes, it is challenging enough to write code satisfying the constraints of all of these platforms. The less done by devs (in terms of mucking with qualifying names) the better. Perhaps letting thing implicitly qualify is simplest.

dnolen19:06:29

@mfikes patch 2 applied

mfikes19:06:51

Cool. Crossing my fingers that it covers all the cases we need it to for now 🙂

darwin23:06:54

Need to pick up your brains. I have made quite nice progress on code completions in Dirac 0.6.0 thanks to your suggestions: https://github.com/binaryage/dirac/releases/tag/v0.6.0 I’m parsing all ns-forms using cljs.analyzer[1], it was much easier than expected 🙂 Motivated with this quick win I would like to go further. The idea: thanks to source maps, I have full cljs source code snapshots at the point it was loaded in the browser. On client-side I could run analyzer pass not only on ns-forms like I do now, but in theory on the whole file. This could give me some contextual info for subsequent REPL eval requests. This way I could get rid of warnings[2] which are generated because after in-ns people don’t run (require 'my-namespace) prior executing their commands in the REPL. In theory I could be able to “setup” eval environment according to "browser state" before each eval request. Partially I already do something like that by providing :locals when paused on a breakpoint. I would be just able to provide more contextual info from browser side (existing vars, current ns-form info, etc.). Do you think something like could fly? Is it even possible? Ideas? [1] https://github.com/binaryage/dirac/blob/master/src/implant/dirac/implant/analyzer.cljs#L7 [2] https://github.com/binaryage/dirac/blob/master/src/runtime/dirac/runtime/prefs.cljs#L25-L26

danielcompton23:06:28

I don’t know too much about the fine details, but this sounds similar in behaviour to what Figwheel does, where you can in-ns anywhere and eval without requiring