This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (34)
- # boot (5)
- # cider (3)
- # clara (19)
- # cljs-dev (188)
- # cljsrn (1)
- # clojure (107)
- # clojure-russia (5)
- # clojure-spec (1)
- # clojure-uk (3)
- # clojurescript (40)
- # core-async (1)
- # data-science (4)
- # datascript (1)
- # figwheel (6)
- # fulcro (19)
- # garden (4)
- # graphql (3)
- # jobs-discuss (2)
- # leiningen (9)
- # london-clojurians (1)
- # off-topic (5)
- # onyx (2)
- # portkey (9)
- # re-frame (9)
- # reagent (8)
- # reitit (1)
- # shadow-cljs (2)
- # specter (1)
- # uncomplicate (2)
Yeah, the middle number, for lack of a better way to describe it is after a
The actual numbers in the graph are 36.5 s, 20.8 s, 17.3 s (I had to graph them though to get a better feel)
@mfikes actually that graph is pretty nice, it shows that time on shared stuff is almost gone?
Yeah, one say to look at it is the the difference between using the local cache and needing to copy in from the global cache is only about 3 seconds
even if I sleep between compiled file write, before send the JS for the load - Safari errors out
(My numbers with
:parallel-build true look pretty much the same for this project—both of the bars on the right are a little taller, but nothing to glean from it.)
@mfikes no it’s just a race like before, if we compile something to out and we’re already connected Safari balks about the file not being there for some reason
ok I have a fix which is just add a random timestamp, it’ll open a new tab window but this doesn’t seem like a big deal - Chrome already works that way
but Safari doesn’t really seem to respect cache control headers - so there doesn’t seem to be anyway to force the issue
not too shabby given Clojure launch, ClojureScript load, browser launch, and REPL exec
@mfikes and I take it you didn’t see anything weird with AOT jar or global cache in your project?
No... I only tried compiling, I didn't go so far as to actually verify proper operation
I got what looks like a compiler trip-up when compiling Planck https://gist.github.com/mfikes/3ee861e6d558d0c6e3fd5d7d1a3f5bc5 Good thing is that it happened the first time so hopefully it is relatively reproducible.
ok that’s interesting, yeah will try to use this on a few things this weekend and try to iron out the obvious issues
The Planck build failure is fortunately easily reproducible, so I can see if I can find out what is going on
I must say, it’s quite cool that it’s so easy to start a ClojureScript REPL now, first time I feel like we have some competitive with my first experience with Clojure
When I first started coding in ClojureScript, I didn't even have a working REPL. Wow we've come a long way.
ok done for the evening, but I think we’re in a good spot to do a lot of testing and shoot for a release not next Monday but the following Monday
Unbeaten path, reported a problem with socket REPL: https://dev.clojure.org/jira/browse/CLJS-2598
The built ClojureScript JARs no longer embed a
so I’ve updated Canary to no longer manipulate that file. (It would add a distinguishing build hash to the end of the version number, like
1.10.102-a0b9521.) I suppose a consequence might be that subsequent nightly Canary builds of the same ClojureScript version might collide (maybe overwrite). I haven’t looked up the details of this, but sharing in case strangeness occurs. As an aside, Coal Mine fetches ClojureScript as a git dep (using
:sha, so it built without any changes.
@mfikes I think we will have to install the jar with first form of the command as described here: https://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html and not rely on pom.xml
or alternatively we could synthetise our own pom.xml at that point and use it instead of the original embedded one, not sure, I’m a maven/java noob
I’m not sure what pom.xml contains, I was under impression there could be also dependencies clojurescript itself needs
so installing it without proper pom.xml could give us broken clojurescript (without dependencies installed)
what about changing install-canary.sh to work similar way as your Coal Mine? I’m not sure about consequences tough, e.g. would it be slower because it would not use AOT-ed version?
Perhaps this was an unintended consequence of https://github.com/clojure/clojurescript/commit/8971829275b466280a0b8fc85886e3fa7d353a13
Coal Mine itself uses the
clojure tool and can thus use git deps easily. Other projects (based on
lein for example) really want a JAR to depend upon.
We might shortly see about broken dependencies with the latest job I submitted. (Hey, that’s the point of Canary, right?)
Thanks for trying it, but I’m afraid
-D won’t be enough. Looking at a
pom.xml from some previous ClojureScript jars and it contains quite some important deps: https://gist.github.com/darwin/6e41b44bc9f488c37fa2691c761e6e96#file-pom-xml-L24-L79
Yes, I agree. I think there will be a larger issue. The Canary builds will likely confirm that.
I noticed this when I modified the build and spent a bit of time trying to make Maven include it but did not succeed. If it becomes an issue, I’m happy to look at it again.
Thanks! I'll revert the last couple of commits I have in Canary after sorted so we can re-confirm things work end-to-end.
Maven typically stores the Pom alongside the jar in a maven repo and that’s what the maven api uses
I need to install custom-built clojurescript jar into local maven repo. Where should I get the pom.xml which maven requires?
so it should be sitting next to produced jar file, somewhere here, right? https://github.com/cljs-oss/canary/blob/master/runner/scripts/build_compiler.sh#L186
ok, great, then we are all set, we upload pom.xml alongside our jar to github releases and then let canary-install.sh download it, instead looking for it inside the jar
(As an aside, Canary has confirmed that our current setup is insufficient, the Planck build complains about
Yeah, seems like our "manual" Canary dep fetch just needs to be revised to deal with 2 files instead of 1 and when installing into maven use that
btw. embedding pom.xml into the jar still might be a good idea, if someone wanted to install it this way (method 3): https://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
We can also patch the
pom.xml directly and when installing use the 2nd step here https://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
@darwin If you wanted to make any of these Canary revisions, feel free. Otherwise I might have some time later on.
The other missing file is the build.properties which is probably less critical but is also available to include
sure, no problem, you decide what you want to do and we will adapt to your solution in canary, thanks for all the info
I think this is because the assembly part of the pom.xml doesn’t have an archive section? If this doesn’t work I’ll defer to @alexmiller
I think keeping META-INF with maven meta info (even if generated by other means) in the official jar is less disruptive and allows easier standalone jar installation via maven install plugin - and that also would mean zero work for us in canary .-)
@mfikes et al: fyi, new version of clj is out and it fixes the bug where it would swipe a single -h main arg and also enables use of the classpath cache with -Sdeps (which it turned off in the past). in case that effects any timing you’re reporting that include -Sdeps
Cool. Thanks I indeed noticed that
-Sdeps turned off caching. I thought it was intentional given that
-Sdeps might be thought of as "ephemeral", but caching is probably a good thing in that case as well.
OK @darwin given this I'll just revert my last two commits in Canary and give it a shot.
@mfikes it is still failing, I think due to https://github.com/cljs-oss/canary/commit/cbaf3bb30c9f6ea12324d09b740d06ede5674617
btw. you can test it with
job only=cljs-devtools to just exercise it and when it will work we can run full round
ok, no problem, I should add a comment explaining why we want to patch the version in the pom.xml
it is because we want to support forks and those can have same version numbers but different shas
@mfikes it failed again because the release jar is already present, so it was NOT re-uploaded
it should work next time when clojurescript repo gets new commits and canary will actually upload new jar
David thanks I see why you say they do not compose - at the moment no socket accept fn receives repl-env and opts. It is a killer feature though, now almost all editors need an additional command for bootstrapping the (socket) Repls after startup. We could get rid of that burden.
@dnolen just hit one weird corner case in the build script:
I had a pre-1.10 fork of clojurescript repo, I did a pull to get current latest from official clojurescript repo, and pushed to my fork to get it up-to-date, that didn’t push tags by default, and the build script started failing at this line: https://github.com/clojure/clojurescript/blob/master/script/build#L28
should we attempt to make it more robust? from the error message is it not obvious what is wrong - git complains
fatal: No names found, cannot describe anything.
I would add a simple bash test for failure and echo a possible explanation to instruct people to update tags in git repo
@dnolen https://dev.clojure.org/jira/browse/CLJS-2601 captures the same as the Planck build failure I mentioned yesterday (but as a minimal repro)
2018-03-12 in draft
clojurescript-site content related to the release; can change if needed.
For reference, the release-related PRs comprise https://github.com/clojure/clojurescript-site/pull/156 https://github.com/clojure/clojurescript-site/pull/178 https://github.com/clojure/clojurescript-site/pull/173
wow, been wanting to fix this one for a very long time https://github.com/clojure/clojurescript/commit/298b1261ad6490ec4e8c02b8c5044d4227ad9b00
anything that prints before browser REPL actually connects will still get sent over once the connection happens
Ah nice, I think both figwheel and the boot cljs repl implement a similar queuing solution, good job!
If ClojureScript is an unbuilt dep, even though any artifacts produced for JAR deps are put in the shared cache, when you go to use them, since
cljs.core will need to be compiled in the case of an empty output directory, this cascades a requirement to rebuild all of the shared cached artifacts (because they ultimately depend on
A consequence, it seems, is that artifacts cached based on unbuilt ClojureScript deps are not really usable. You could argue that we add conditional logic not to cache them in the first place. But, if we ultimately end up supporting shared cached artifacts built from git deps, then if ClojureScript is itself a git dep, then things will work out in that case in the future.
@mfikes we probably want to open a issue for that, not sure if we’ll address before release since it doesn’t directly affect most people
@dnolen The issue above doesn’t break anything, but I’ll write a JIRA so we can take a decision on it.
LGTM. I was wondering whether the “`cljs.main` tour” news post would replicate a lot of what would ultimately be in Quick Start. I can now see that Quick Start has a focus on ClojureScript itself, and the use of
cljs.main is just an ancillary / inherent thing that new users would have no reason to even notice.
I do like how it looks much shorter, and much less intimidating with lots of accidental complexity evaporating compared to the previous version.
And maybe one day in the future you will be able to just type
cljs -O advanced -c hello-world.core
@mfikes yes I think the announce and Quick Start serve different purposes, that they might overlap a bit is not a big deal
Quick Start is very short and to the point now https://github.com/clojure/clojurescript-site/blob/52a70e8ec6618cd9902f09434988c11a004628a3/content/guides/quick-start.adoc