how to import custom closure javascript code into clojure?

there seem to be some subtleties to require order — if I order things one way, I get “undefined” for imported identifiers. Does anyone know of a good wiki page or walk-through on this?

@jaredly: Hmm… perhaps something you are requiring itself doesn’t properly require its own deps.

ahhh yeah it looks like I had the wrong ns declaration

@jaredly: Ahh cool. (As an aside, I don’t believe there is a guarantee of ordering.)

I’ve definitely had an ordering error (a couple of days ago), where reordering imports fixed it 😞

@jaredly: Perhaps you simply caused a new hash ordering in the deps hash https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L1903

hmm maybe

@jaredly: require order does not matter, if it does it is most likely due to some undeclared deps in your files.

@mfikes: I actually thought require ordering was changed to keep the ordering you used in the ns form, because someone reported a bug that manifested due to them not being order, but I couldn't find the commit afterwards, so I might have imagined that '

candidate #1 for broken ordering are multi-methods since you can call the defmulti without having to require the namespace that contains the defmethod

for most other things the compiler should complain

although cljs.closure still has the issue that warning are only emitted once

and incremental compilation hides them after 😞

so they are hard to track down sometimes

http://dev.clojure.org/jira/browse/CLJS-1159 if someone wants to get busy 😉

or use shadow-build 😎

@thheller @jaen @jaredly I created a sample repo that shows that ClojureScript does not preserve order. Interestingly, the repo does not show that this is the case for Clojure.

https://github.com/mfikes/ns-ordering

Then I must have been imagining things, I was almost sure someone brought it up before and a fix was made for that. This has also bit me once or twice in the past.

@jaen: Hmm. Maybe you are recalling something from the Clojure side. Maybe it came up as an issue in Clojure and was addressed there.

Could be, though I was pretty sure it was Cljs. But well, memory likes playing tricks : V

@jaen: I’ve also seen something in the ClojureScript AST that appears to be keeping track of the order that symbols have been seen.

Oh, so maybe there was a fix, solved some surface issue, but not the root of it. But no matter, it's irrelevant whether I was imagining things or not in the end ; d

Nicola Mometto confirmed that Clojure does preserve order, but that this is only an implementation detail.

That's... peculiar. I imagined it would be a conscious choice since require order might matter.

That raises an interesting question: Are there cases where you need order but can’t establish it by saying ns a depends on ns b via a :require spec in a?

I don't remember what I was doing that I would have needed deterministic ordering, but in general - that's a good question.

Just to make sure - we're talking about ordering of clauses within a single ns declaration, yes? As in

(ns something
  (:require cljs.react my.namespace))

Yes, the question has to do with trying to establish order via the textual order in an ns form. Which is the bit that is not guaranteed.

So, with the example above, if my.namespace uses stuff from cljs.react, the textual order in something is insufficient. (Instead my.namespace needs to have a :require for cljs.react in its own ns form.)

Then I can think up of a simple example. Not sure if that is a kosher way to structure an application, but nonetheless. Imagine there's some namespace called dispatcher and you can register your function with it using (dispatcher/register path handler). The way dispatcher resolves the handlers to call when you do (dispatcher/call path & arguments) depends on the insertion order. There's no other way to guarantee this will work reliably unless :require is ordered.

Otherwise the alternative is to not split up handlers across namespaces (like handlers.common, handlers.authorisation handlers.users-page and so on), but keep them in a single file, but that doesn't sound like a good solution to me.

Ahh, interesting. So this is a runtime execution order dependency.

The problem goes away if you structure your application using components for example, but I don't think it's as common in the Clojurescript land as it is in Clojure.

And again, this might not be a structure to enourage, but nonetheless a valid one.

hey all. I'm using reagent + core.async to make some slider widgets...

If I want react mouse events to work well with async channels I need to call .persist on the events before shoving them down them don't I?

Is there another approach?

Having mutable events in React kind of makes core.async interaction a touch awkward doesn't it?

Why not extract what you need and shove that over the channel only?

Has anyone used Mori w/ CLJS? I use CLJS for my data layer w/ vanilla JS/React. I would love to have my CLJS export functions return a Mori wrapped EDN objects. I could do clj->js then mori.toClj. I couldn’t find anything better in the docs.

I might be wrong, but aren't mori's datastructures just Clojurescript structures, so no translation is necessary?

it’s a javascript-like interface on top of cljs data structures.

i can’t call .get() on a pure EDN object that I return to Javascript land.

no i think maybe your right. It seems like all the functions to interact with EDN is calling mori.get instead of myEdnObject.get

I'd imagine basing on what I understand mori is for mori.first(your_cljs_function_returning_a_collection()) to work

But I might be wrong

thanks jaen. I guess that'll do it... in this instance it kind of feels like I'm splitting the slider logic between the callback and the async stuff.

@triss: some of that is inevitable, if you have some logic on the other side of the channel, I guess.

@jaen now that I look at it closer I think you’re right. thanks.

[Random] A quick way to see if you’re in a bootstrapped REPL: Evaluate #{1 2 3} and see if it prints the same back (bootstrapped) or #{1 3 2} (not).

@mfikes I doubt that is documented official behavior

since nothing works if you just (require 'dep.z)

might be worth to add a warning if a namespace tries to use a fully qualified name without a :require for it

@thheller: Please expand on what you are saying. I’m not understanding.

your example repo, in both cases it assumes that (require 'top) is called first

that makes it look like unordered works

although it doesnt have requires for b -> a etc

so if you do not (require 'top) first and just require (require 'dep.z)

unordered does not compile

well actually it compiles

Ahh… perhaps this helps clarify: In the unordered repo, I expect the call to evaluate dep.z/z to fail.

yes

(If that’s causing the issue I’ll revise the readme.)

the issue is that (require 'top) sort of makes it look like it should work

while it shouldn't

In fact, I should say that (require ‘dep.top) will fail in the unordered repo.

hmm it is hard to make it fail, but yes

Right? I think this is just poor wording on my part in the readme, unless there is something more subtle you are saying.

no it appears as though the ordering matters

since the topo sort cannot work when b doesn't declare the require on a

c -> b, etc

since they don't have any deps the compiler thinks it is fair game to sort them in any way it likes

so even though the unordered stuff might work in clojure

I doubt that this is official dependable behavior

ie. if you just (require 'dep.z) in unordered it won't work

while it will work in ordered

But isn't that's what the issue is about (if I understand it right)? That is whether the topological sort should only take namespace requirements into consideration or the order the namespaces appear in in the require clause as well.

I'm saying that the order should not matter .. ever ... period.

The unordered tree is an example of an incorrect setup. It is there to illustrate how things fail.

if it matters it is due do undeclared dependencies

Why? If loading namespaces can be sideffectful, reordering can cause a working program to stop working.

no it cannot

The fundamental issue is that you cannot use the textual order in an ns form to control the order.

Why? Would you then care to scroll up to my example and point out where my assumptions are wrong?

only in case of undeclared dependencies

(ns something
  (:require cljs.react my.namespace))

this one?

That one - https://clojurians.slack.com/archives/clojurescript/p1450019394006488

Right, @jaen you cannot use the textual order in :require to make that situation work.

ah well if you care about insertion order

you should make that explicit in the code

and not work with global variables 😉

This is a point, like I said I used it to illustrate what I understand the problem is, not said it's a kosher way to structure a Clojurescript application, but that's sort of a thing allowing side effects in top level forms lets you do nonetheless.

This is semantically the same as

(ns something
  (:require my.namespace cljs.react))

If that's a bad thing to do, then there should probably be a warning for that at the very least.

@mfikes: well yes, but I understood that the issue is about whether the textual order in the ns form should matter or not. Or did I misunderstand something?

you are relying on the hash ordering of a set in this case

Just to be clear, the textual order in the ns form does not guarantee anything.

so yes it is not something you should ever rely on

@mfikes: in Clojure as well?

@jaen: In Clojure it is evidently not guaranteed either. But it does occur by accident of an implementation detail.

So it's not meant to work, but just so it happens it does?

Right.

It could change in the future, and break code that relies on it.

(I think one thing that may have spawned this conversation is that there perhaps additional subtle issues surrounding this subject that come to play if you turn on the new parallel compilation feature. In other words, code that is skating on thin ice breaks when you turn on this feature.)

It may be a failing on my part, but I've never read that ordering in the :require clause doesn't guarantee anything. Moreover it's a vector not a hash map (by which I mean the surface syntax), which implies that ordering is significant.

@jaen I’ll show you the line of code… just a sec.

:requires are kept in a map

Here is the set https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L1903

Yeah, I've seen that earlier in a thread somewhere.

But what I mean is - that is an implementation detail that's not evident from the outside.

Right. So, the ns docs say nothing on the subject.

given the dynamic nature of clojure and the REPL

and the presence of (require 'something :reload)

I think relying on ordering would only be harmful to your program

Well, in Clojure I wouldn't, I use component which makes that irrelevent, since ordering is implicit from the system map shape.

A couple of other things that exacerbate things, IMHO, is that you can require a and then gain access to the things that a itself requires. And (for some of us at least), Cursive will resolve a symbol even though you haven’t properly :required it.

But this approach is not as popular in the Clojurescript world

well it should be, the same rules apply

Maybe, but observe for example this re-frame sample - https://github.com/madvas/fractalify/blob/master/src/cljs/fractalify/users/handlers.cljs

Sideffects at top-level.

Perhaps two solutions in ClojureScript are (1) Explicitly do the registering in code that registers things in the required order. (2) Make one of the namespaces artificially depend on the other, to force the order.

And it seems it's a more popular style in Clojurescript than in Clojure.

@jaen yeah that is bad, globals for everyone

@mfikes I think we should emit a warning if a namespaces requires a fully qualified var without having a :require for it (or :use)

I'm not saying it's good, but nonetheless it's popular, especially with libraries like Reagent making it simple to write that way.

If the ordering of requires is not guaranteed

@thheller: Yeah, something like that would probably be very useful.

Then shouldn't side-effecting in a top level form warn then?

So people don't learn wrong habits?

well side effects at the top level aren't all bad

Well, Clojure is imperative in that sense. defn makes a def, etc.

but far from best practice

You can intern vars, register handlers, it is all side effects in a sense.

Yeah, but then no ordering makes it implicitly non-deterministic.

Across namespaces that is.

how do you even handle reloads in that setup?

ah I guess :logout and stuff are the names of things

The way I look at it, any namespace can declare a dependency on another. Thus you have a partial order.

I guess, but that makes you have to do artificial requires to ensure that order.

Not sure if that's ideal.

If fractalify.users.handlers expects other things to be registered prior to it, it can (artificially) require the namespace that registers those things. (But this seems less than ideal and perhaps an abuse of :require)

Yeah, eaxctly.

Hah!

That's non-essential to what the file needs or does.

Sort of an incidental complexity caused by how require works.

> If fractalify.users.handlers expects other things to be registered prior to it

you expect something, so declare it

Yeah, I think this is just a code smell associated with global initialization order.

Now, I'm not saying requires should be changed to have the order of clauses in it be significant, but if that's bad then I think user should be made aware of that by the compiler if possible.

Put all of those top level forms into a side-effecting function, and then call that function from some other namespace at the right time during inti.

agreed, a warning would probably be best

but not sure how that would be possible since the compiler is not that smart 😉

warnings for fully-qualified vars without require should be pretty straightforward though

might just make the compiler slower though

> you expect something, so declare it But I'd agree that's abuse of require, it's there for you to require code you need, not sequence sideffects in top level forms. The init function for namespace sounds sensible, but it's a cultural thing. C++ is a great language if you have the right culture, experience and discipline. Enforcing things is better, I think.

@thheller: Perhaps it is even legal for code in ns a to make use of transitive deps of a ns it explicitly requires. But this seems fragile.

> If fractalify.users.handlers expects other things to be registered prior to it

@mfikes: If I understand what you are saying then I'm pretty sure it works like that in Clojurescript. When I require a namespaces in the browser REPL, I can then use things it required with fully qualified symbols no problem.

@mfikes not sure what you mean?

@thheller: yep, what @jaen said. Let’s say (ns a.core (:require b.core)) then the code in a.core can reliably use things that b.core requires. But, this seems fragile to rely on transitivity. I’m arguing it is better for a.core to actually :require the things it uses.

well yes you can do that but not something you should ever rely on

again .. if you want to use something :require it.

@thheller: I like your idea of having the compiler emit a warning in that case.

Hmm

I'm just wondering how feasible would it be for compiler to warn on any top-level function call that reaches outside the current namespace?

(ns a.core
  (:require b.core))

(c.core/foo 1)  ;; This should cause a warning to be emitted

Since if that's not what people should be doing

A warning would be prudent.

I guess the same arguments and concerns apply to Clojure.

Yeah, though it's a bit different for Clojure

I don't think anything should be done in that regard

since some things are just global and must be global

ie. schema.core/defn

But that's a macro, not a function call.

@jaen that’s already done

it emits a defn and something global

if you reach to a namespace the analyzer hasn’t seen - warning

So it's entirely not the issue.

@dnolen: maybe I'm not clear enough - I'm not talking about using undefined symbols, I'm talking about calling sideffecting functions from other namespaces at the top level.

@mfikes: but Cljs being different I mean you can't eval in Clojurescript so you can guarantee that during compilation. Not so in Clojure.

@thheller: I'm not saying there should be a warning about using symbols from other namespaces at the top level for any and all cases. Macros emitting code into current namespace are totally okay, since this does not depend on require ordering at all.

@jaen: Hah. I’ve been living in bootstrapped world too long

On the other hand if that macro emits a function that sideffects it should be a warning.

But then again

It may be impossible to implement for all I know

@mfikes: right. It's a different world that side of eval ; d

Hah, I noticed over at the dev channel, that I didn't make up the issue being reported at the very least. Just the fix part.

@jaen: You have been redeemed. Your memory is accurate.

Half-accurate, but that's still better than not at all ; d

Don't want to barge in #C07UQ678E so I'll leave this here: The way I look at this the options are either to: a) have the ordering of require/use/etc. clauses in the ns macro be a part of the language semantics, which makes sense since loading a namespace is an imperative process of creating vars and calling functions at the top level, where inter-namespace ordering can be significant, b) have no ordering of require/use/etc. clauses in the ns macro be a part of the language semantics, which in turn should make doing cross-namespace sideffects either outright forbidden or at the very least - warn. Doing anything else would be inconsistent IMO. One behaviour would be declarative while the other - imperative, which would result in not-so-obvious behaviours when namespace require order gets well... reordered.

I know that explicit is better than implicit, but... Do anybody know robust way to pass some value inside lexical scope? Like binding, but working with lazy sequences?

@ul: FWIW, that reminds me of this thread where Brandon Bloom ends up creating bound-fn for ClojureScript. https://groups.google.com/forum/#!topic/clojure/6cmnkHmHBNw

very interesting thread, thank you!

@mfikes: so the branch patch in the thread is not in ClojureScript yet I assume?

@richiardiandrea: Please define “branch patch"

this -> https://github.com/brandonbloom/clojurescript/compare/8ba4849e60e5957cdac36ef6946c647e824ca3c8...vars

Right, ClojureScript doesn’t have bound-fn, for example.

ok thanks, just because the thread is so old I thought of asking 😄

@richiardiandrea: No problem. I should have said Bloom ended up creating a proposed bound-fn for ClojureScript.

I might actually add some tests on binding to replumb as it can be useful as reference...

That doesn't answer your question, but why not cljs-time?

I was wondering about the cost of var indirection. For me, this takes about 6.1 seconds

(time (let [a (atom 0)] (doseq [x (range 10000000)] (swap! a inc))))

(time (let [local-swap! swap! local-inc inc a (atom 0)] (doseq [x (range 10000000)] (local-swap! a local-inc))))

@jaen in fact I used cljs-time but removed it to keep the example minimal

So I imagine you were using those - https://github.com/andrewmcveigh/cljs-time/blob/master/src/cljs_time/extend.cljs - and they didn't work?

oh, haven't seen those

thanks, I'll try that

BTW what are the sets in each case?

you mean the type of the sets?

@gerrit: Implement IHash

Even this is sufficient to make the test work: (extend-type js/goog.date.Date IHash (-hash [o] 1))

I've meant what the sets look, ie. what items they have.

cljs-time.extend doesn't change the behavior. @mfikes: nice, thanks!

@mfikes: w8, with a constant hash?

Without that, you get funny answers. (hash (js/goog.date.Date. 2015 11 3)) changes each time you do it.

Ah, I guess it then falls back to equality and uses chaining?

@mfikes: any guess why it works with 9 items or less? is that just a coincidence?

@jaen: Yes. (= a b) implies (= (hash a) (hash b))

@gerrit: Good question. I don’t know.

@jaen: If (= 1 (hash x)) for all x, then you’ve satisfied the contract

What I mean is, then why the set doesn't have just one item then.

@jaen: I didn’t want to work out a good hash code.

@jaen: Because if the hashes collide then the hash-map and hash-set algorithms typically fall back to a linked list based on =

@jaen: I don’t know how the HAMT actually does it. But colliding hashes is fine.

Yeah, that's what I've meant by "falls back to equality and uses chaining".

You generally need to make sure you satisfy the implication

It makes sense to have it work that way, just wanted to be sure.

(though probably persistent data structures don't use linked list chaining, but still)

In @gerrit ’s original (not= (hash (Date. blah)) (hash (Date. blah)) given whatever funky thing was going on. (Perhaps it was giving the hash of the object address.)

(-hash [o] (hash (.getTime o))) this should probably suffice as proper hash implementation?

If the time is in milliseconds, that’s probably cool

it is

I guess it makes sense to PR that to cljs-time

If IEquiv could be expressed as (= (.getTime a) (.getTime b))

yeah kind of. this is what cljs-time.extend does:

(-equiv [o other]
    (and (instance? goog.date.Date other)
         (identical? (.getTime o) (.getTime other))
         (identical? (.getTimezoneOffset o) (.getTimezoneOffset other))))

so I'll add the timezone to the hash

somehow

str it maybe?

unless hash needs to be a number?

Duh, of course it needs.

But then you can get the hash of the resulting string, I suppose.

I guess doing it the java way should work. as timezoneoffset seems to be a number as well

I suppose as long as all datetimes are in the same timeones you shouldn't have too much collisions.

for reference: I hope this does the trick (-hash [o] (+ (.getTime o) (* 37 (.getTimezoneOffset o))))

@gerrit: whether the TZ is included in the hash could be driven by perf. (Either choice should function correctly.)

Yeah, it's quite interesting how much the conflict resolution strategy affects the performance.

I am running a core.js that was generated by ClojureScript as part of a system running on node and the "system" can't find "goog" goog.provide('pow.core'); ^ ReferenceError: goog is not defined at Object.<anonymous> (/home/mstang/Desktop/projects/codetest-1/out/server/pow/core.js:2:1) at Module._compile (module.js:456:26) at Object.Module._extensions..js (module.js:474:10) at Module.load (module.js:356:32)

I tried to use "require" thinking that nodes require would load it, but no luck. Has anyone else run into this issue?

What I tried was: var goog = require('../out/server/goog/base.js'); var code = require('../out/server/pow/core.js');

Also, I was building with an older version of cljs, I switched to the latest and now I am getting :

Compiling "out/server/pow.js" failed. Exception in thread "main" java.lang.AbstractMethodError: Method cljsbuild/compiler/SourcePaths.findsources(Ljava/lang/Object;)Ljava/lang/Object; is abstract, compiling:(/tmp/form-init6738966304942402426.clj:1:73)

Thoughts?

@markstang: all I can say is Closure and CommonJS / Node are two different module systems, with two different require constructs.

@mfikes Yeah, I read that somewhere someone had written a "require" for google to work within node

The QuickStart has a bit covering Node

@markstang the second error most likely requires a newer version of lein-cljsbuild

1.1.1 I believe

> var goog = require('../out/server/goog/base.js');

wont work since goog is a required global object, but it should be managed by the build and included in core.js

ah, not seeing it in the core.js

not sure what magic to use for it to be included

did you set :target :nodejs in your build config?

yes

maybe I need the :require for node.js...

sorry that is pretty much all I know about the cljsbuild world, not sure how things are done over there these days

but one thing as well would be that the output of a node.js build

is not really meant as something you can require in node

more like a script you execute

no but maybe in clojurescript

since your example had

>var code = require('../out/server/pow/core.js');

more like node out/server/pow/core.js

it might work then, I do not know

yeah, which works fine, but I can specify the command-line

sigh

?

I don't specify the command-line, I am "requiring" my module in another module

you are not building a module, at least as far as I can tell cljsbuild does not support that

(set! (.-exports js/module) #js {:helloWorld hello-world})

yeah that is broken ... don't do that

clojurescript creates the right output

ok, well back to the drawing board, I am trying to replace an existing source file with a clojurescript generated one

I have done some work on this stuff recently if you are interested

basically a way to create UMD module compatible output

UMD?

https://github.com/shaunlebron/parinfer/blob/master/lib/dev/build.clj#L15-L18

looks somewhat like this (eg. a map for {exported-name fully-qualified-cljs-name})

Universal Module Definition basically a way to combine the various module systems the js world has

ie. what node likes

ah

I will take a look at it

but the solution is far from ideal, still working on some rough edges

Well if I take the generated javascript and rip out the "goog" and the namespaces, it runs and works...

node is just messy in that regard 😞

or our integration with node really, since we are happily abusing the global object

ah

https://github.com/dvcrn/proton/blob/master/src/dev/build.clj

would be another example of a build that generates a node compliant module

I'll take a look at that one next

Tnx