Fork me on GitHub
#clojurescript
<
2015-08-30
>
estsauver06:08:38

While using figwheel, I’m seeing this error with piggieback dependencies. Does anyone have a set of exclusions that work with figwheel?

estsauver06:08:48

'clojure.tools.nrepl.middleware.interruptible-eval/queue-eval is not public

plexus10:08:13

I'm writing a clojurescript lib, and I'm trying to figure out what the current state of testing cljs is

plexus10:08:39

cljs.test has been around for a while now, but it seems cemerick/clojurescript.test is still very popular

jonas10:08:38

that covers cljs.test

plexus10:08:01

yeah but it doesn't cover how to set up headless testing for instance

plexus10:08:39

I would love to see a working setup with phantomjs or slimerjs, been looking at repos but haven't seen good examples

plexus10:08:56

alright, that looks interesting!

plexus10:08:37

might also reconsider the testing setup for chestnut. Right now it generates a .html and .js file just to have a "runner" for phantomjs. I was never really happy about that

jrychter12:08:37

Into my second hour of fighting library dependency hell. Weird error messages, missing classes in libraries I didn't even know I was using… This is something that is becoming more and more of a problem as the number of libraries grows and as we use more and more of them in our projects.

jrychter12:08:58

And the breakage is completely unexpected. As in "upgrade ClojureScript to a newer version" -> "observe how timbre (used by sente) breaks with "Could not initialize class clojure.tools.reader.edn__init", but only if you run in dev env. Remove leiningen from dependencies and this particular breakage goes away.

jrychter12:08:23

@plexus: I think including leiningen as a project dependency in chestnut is a risky idea. I can trace most of my problems to leiningen and its deps.

plexus15:08:35

@jrychter leiningen hasn't been a project dependency for quite some time now

escherize15:08:00

I am failing to compile clojurescript and i'm getting at cljs.util$topo_sort.invoke(util.cljc:168) repeated a lot of times in my stack trace. Should I look for a cyclic dependency? Are there known causes of this?

dnolen15:08:21

@escherize: cyclic dependencies aren’t supported, it should be able to catch cases like that but there may be edge cases stilll

escherize15:08:18

Thanks @dnolen: do you have a suspicion about what I should start looking for?

dnolen15:08:52

I would just git bisect a problem like this

martinklepsch16:08:15

how do you properly use a static method like this one: http://google.github.io/closure-library/api/source/closure/goog/date/date.js.src.html#l1315 — I got it working with (:import [goog.date Date]) and (Date/compare …) but this still causes warnings

dnolen17:08:42

@martinklepsch: there’s no such thing as static fields in JS so it just isn’t supported

dnolen17:08:47

(Date.compare …)

martinklepsch17:08:07

ah yeah, static as in Closure’s “static”. that . makes sense, thanks!

martinklepsch17:08:53

@dnolen: err, actually that Date.compare call isn’t working. That was meant to be used with :import [goog.date Date] right?

jrychter18:08:41

@plexus: Hmm. I wouldn't know, because leiningen templates aren't updateable… I guess I'll check the source, then (even lein new stopped working for me recently). But I'm glad to hear that — leiningen has a ton of dependencies, often using older versions.

dominicm19:08:01

@jrychter: What do you mean they aren't updateable? You once the template has been used? Because you can just push up a new version of the template.

martinklepsch19:08:22

@dominicm: I think he’s referring to the fact that once you created your project with lein new you cannot easily upgrade to upstream improvements

dominicm19:08:11

@martinklepsch: Ah right. Yeah, that's true, nothing stops you from doing a new project, and migrating your changes.

dominicm19:08:20

I wonder how replaying the git history to the new template would go...

martinklepsch19:08:05

Well once your project has reached some size its definitely not straightforward anymore

dominicm19:08:48

No, not at all. Depending on the template size you could just manually apply the changes to the template.

dominicm19:08:57

It's a hard problem to solve, one that likely won't be.

jrychter20:08:06

@martinklepsch, @dominicm: that is exactly what I meant. I have a fairly large project, and the template has been heavily modified (to start with, I don't use Om, but Rum). There is no way to keep in sync, and starting with a fresh project is not an option.

jrychter20:08:44

What I'm doing now is looking at what newer versions of chestnut do (specifically the way figwheel is started) and porting the changes back into my application.

dominicm20:08:50

@jrychter: Yeah, best option really.

jrychter20:08:48

A general observation: I came back to a project after 3 weeks and tried to update some dependencies. It broke in so many ways I can't even count. I'm spending hours bisecting dependency versions, adding :exclusions and staring at dependency trees. And most of the breakage is not even in the app itself, it's in the build system. It's worrying how brittle it is.

jrychter20:08:40

I guess this shouldn't be in the ClojureScript channel, as it isn't something ClojureScript-specific. But ClojureScript makes building significantly more complex, especially with figwheel.

bhauman20:08:59

@jrychter: I understand your frustration but you aren't using figwheel as prescribed in the readme or quick start

rauh20:08:25

@jrychter: Last week I got rid of leiningen cljsbuild and am just calling clojurescript's API + fighweel in a .clj script file. I can highly recommend it. You'll understand what's going on and see a ton more output which helps if something goes wrong.

jrychter20:08:29

@bhauman: oh, certainly not. And my frustration isn't directed at any single thing — I mentioned figwheel as a complicating factor, because your app needs to start something in addition to lein-cljsbuild, but I didn't mean to blame it.

rauh20:08:36

I still use leinigen for getting dependencies and setting the classpath properly. So still have all the convenience of that.

jrychter20:08:42

BTW, the main culprit in my case was that leiningen was included as a dependency (older chestnut templates used to do that, in order to be able to launch figwheel). Removing that solves most of the weird problems.

bhauman20:08:36

Gotcha chestnut has a lot of moving pieces

bhauman20:08:55

The next release of figwheel won't even depend on cljsbuild, so one less dep.

jrychter20:08:24

Well, that was my observation: a larger ClojureScript+Clojure application will have a lot of moving pieces, and our build systems are becoming complex and brittle.

jrychter20:08:52

As another example, I still haven't managed to figure out why adding refactor-nrepl to :plugins causes problems in Transit (https://github.com/clojure-emacs/refactor-nrepl/issues/93) — it's weird, unexpected, and really difficult to nail down. The issue has been closed, but it isn't really fixed, I just haven't had time to dig into it yet.

bhauman20:08:55

@jrychter: yep that stuff is real and complicated. Nrepl scares the crap out of me. I don't use it and I stick with inf-clojure and keep the moving parts small. Keeping the moving pieces small has been a big help and David keeps saying so. This doesn't help your immediate needs but ...

bhauman20:08:18

Sorry that you've had such a frustrating time. I hate spending time on that stuff

jrychter20:08:24

@bhauman: well, it certainly isn't your fault simple_smile (you should be thanked for the excellent piece of software that figwheel is!). But it worries me actually that some of the main developers use hand-crafted build systems. This means that popular solutions (like lein-cljsbuild) do not get the attention they deserve. It's also kind of a vote of no confidence.

jrychter20:08:14

What's really frustrating is that we would all like to spend zero time on build systems, but we sometimes have to. Even worse, if a problem happens, it gets in the way badly (your app doesn't build anymore). And since things like leiningen are so complex, it's very difficult to even report problems properly.

dominicm20:08:35

^^ Even in Clojure, this stuff is complex.

dominicm20:08:04

Then again, I've seen plenty of issues regarding the jvm params passed by leiningen. So maybe we should just blame the jvm! 😛

bhauman20:08:51

This is why in the meantime the way forward is probably custom build scripts where you understand every line. Because in reality we are not doing anything that complex. Starting a server, Building on change, staring a repl, etc. writing a script for this is about as much code as the project.clj

dominicm20:08:04

@bhauman: Does this apply to basic clojure too?

dominicm20:08:21

Because I don't even know how to run clojure code without leiningen.

bhauman21:08:07

@dominicm: not very empowering

bhauman21:08:35

Look up "how clojure babies are made"

dominicm21:08:54

That's a real thing, totally expected a troll

bhauman21:08:04

To be clear I'm talking about scripts that we launch with lein for convenience

bhauman21:08:25

But could be launched with Java as well

dominicm21:08:57

As opposed to things like lein uberjar ?

dominicm21:08:10

or the aot settings.

donmullen21:08:17

@jrychter: boot worth checking out — especially for clojurescript work — if you haven’t already. There is a #C053K90BR channel with quick responses to questions and issues.

dominicm21:08:53

@donmullen: I've been meaning to check out & try boot, is it significantly better than leiningen? Or just a different approach?

donmullen21:08:10

@dominicm: A very different approach.

donmullen21:08:29

@bhauman: They are working on this as we speak 😄

dominicm21:08:03

@donmullen: I'll make sure to check it out after this project is done.

dnolen21:08:47

@bhauman @jrychter: fwiw I really the think the value of Leiningen primarily the development of libraries. It simplifies contribution and distribution. It’s also good for newbies.

dnolen21:08:37

but for serious projects I just wouldn’t bother with anything other Maven (now very mature very well maintained) and some scripts - the pain of XML is nothing compared to pain of debugging an opaque build system.

bhauman21:08:26

@dnolen: God that tastes like castor oil

juhoteperi21:08:30

@bhauman: There should not be significant difference between boot-cljs and cljsbuild times. Thought there is one workaround which might cause long compiler times in one case...

dnolen21:08:10

@bhauman: ha, I think people want to believe all this stuff is going to help them build large applications. But large applications benefit most from something that's transparent and unsophisticated IMO.

zentrope21:08:05

So, maven to pull in dependencies, and simple scripts for the rest?

dnolen21:08:17

@zentrope: that’s what I would do and recommend. But I’m also pretty much all in with Cursive which automates a lot of stuff for me.

zentrope21:08:19

dnolen: I like the idea of simple scripts, but library deps starts to add back in complexity. Perhaps maven could just be a command invoked by scripts, eh?

dnolen21:08:41

@zentrope: deps don’t inherently create complexity

dnolen21:08:50

blindly adding deps w/o serious auditing does

zentrope21:08:29

I just mean if you wanted to pull in Om, say, what do you do if you don't want to just store the libs in your repo?

dnolen21:08:59

@zentrope not sure what you are suggesting. Lein just piggiebacks on Maven.

zentrope21:08:05

If I want to write a script to build a project (bash or even clojure), I still have to account for pulling in dependencies. So, there has to be a file to list them. Or I check them into ./lib.

zentrope21:08:27

Or something.

dnolen21:08:15

@zentrope: ok, yes, I said “Maven + scripts” is what I would do for applications above

dnolen21:08:40

but I would probably continue to write libraries with Lein

zentrope21:08:09

Making maven as just another "system utility" to be scripted is the innovation over using maven as the main scripting engine?

dnolen21:08:40

@zentrope: you seem to be misinterpreting what I’m saying.

dnolen21:08:55

nearly everybody already uses Maven via Lein or Boot

dnolen21:08:11

you eliminate the Lein and Boot part for less indirection.

zentrope21:08:55

Ah, so just go full maven.

dnolen21:08:54

right and the tradeoff is that building your thing is now less portable (Windows, shell differences)

dnolen21:08:09

for applications, so what, you should be in control of the machines you’re deploying to

dnolen21:08:19

for libraries that’s really a big tradeoff

dnolen21:08:27

now potential users can’t build / contribute

zentrope21:08:42

Library development seems well represented in Clojure* systems. Apps, not so much.

zentrope21:08:34

I tend to like separating "project management" and "building the source" into separate issues, but I suspect I'm a minority of 1 in that. I'd rather lein be good at building artifacts, and something else do deployment, etc.

rauh21:08:46

@zentrope: I'll gist my scripts/setup that I just did last week (nothing fancy) to move away from leiningen/cljsbuild and go with a script setup. It still uses leiningen to get dependencies.

rauh21:08:01

Give me a few minutes

zentrope21:08:27

rauh: That'll be nice to see. Yes, going "full script" is appealing to me, but snagging deps is the harder part.

zentrope21:08:56

I remember lein 1 used to actually pull deps locally so you could see them, which has its virtues, I suppose.

rauh21:08:08

The first file I touch in every project.

rauh21:08:09

@dnolen: :check-types :warn as a compile option with :optimizations :simple gives me a NPE. I'm not sure if it's Closure's fault

zentrope21:08:27

Heh. Hm. I've not had a problem with cljsbuild in a long time.

dnolen21:08:05

@rauh: the compile time checking stuff is under development. As usual patches welcome.

zentrope21:08:26

rauh: Thanks for those scripts. Nice!

rauh21:08:40

You're welcome

zentrope21:08:24

rauh: I wonder if it's possible to use the underlying pomegranate lib to avoid lein completely.

zentrope21:08:48

rauh: I like how you're pulling in the named compiler options. ;)

rauh21:08:25

Yeah a little scripting goes a long way.

martinklepsch22:08:58

Are there other large publicly available cljs projects besides circleci’s frontend?

zentrope22:08:32

So, clojure-1.8.0-alpha4 is a no go for cljsbuild and or cljs?

zentrope22:08:49

> (class: cljs/util$last_modified, method: invokeStatic signature: (Ljava/lang/Object;)Ljava/lang/Object;) Can only throw Throwable objects

bronsa22:08:53

@zentrope: how do you get that exception?