Clojurians
#cljs-dev
<
2018-03-25
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

dnolen00:03:20

as long as the thread is run with bindings in place it will work

john00:03:34

I think threads are inheriting out like david said

mfikes00:03:35

(OK, I don't truly understand the problem anyway.)

dnolen00:03:38

because it’s the same *out* as the initiating process

dnolen00:03:49

but it wouldn’t be if you didn’t propagate bindings

mfikes00:03:03

REPL evals are working, as well as prns

mfikes00:03:08

By the way, lein --version reports 2.8.1 for me. I think I updated it when I ran into a Java 9 issue

mfikes00:03:38

browser REPL seems to be working with the piggiehack as well

dnolen00:03:01

piggiehack

mfikes00:03:34

Sorry, not cool to use pejorative terms, but it was irresitable.

dnolen00:03:51

anyhoo I think this is fine for now

dnolen00:03:58

Emacs users can sleep easy

dnolen00:03:44

@jumblemuddle thanks for the report, sounds like this is probably fixed in master

mfikes00:03:23

Oh, I finally get what you were saying earlier, David about the 50%. Yeah. Lots of people use stuff but never roll up their sleeves to fix it.

mfikes00:03:32

My pet peeve is people complaining about docs, but not contributing to those docs.

dnolen00:03:46

well, I would summarize as some people have very distorted notion of the labor distribution wrt. contribution in the Clojure ecosystem

mfikes00:03:56

Maya Angelou: "What you're supposed to do when you don't like a thing is change it. If you can't change it, change the way you think about it. Don't complain."

dnolen00:03:32

I think ClojureScript itself is doing pretty well

mfikes00:03:51

Yeah, one thing I have noticed is this notion that there is this "big" core team contributing to ClojureScript.

dnolen00:03:54

right we have lots of contributors - but the number of outlying tasks far exceeds what we can deal with in a timely manner

dnolen00:03:00

and testing ClojureScript is a PITA

dnolen00:03:09

due to all the environmental issues

mfikes00:03:20

Well, it is easier with cljs.main :slightly_smiling_face:

dnolen00:03:22

so seemingly simple changes often aren’t

dnolen00:03:48

right it helps - but we have an heterogenous environment issue that Clojure doesn’t

mfikes00:03:49

Right, the problem where you aren't sure if you broke some corner case for some wierd situation.

dnolen00:03:21

but still I don’t think ClojureScript itself has much to complain about

dnolen00:03:40

but the external tooling story doesn’t seem that great to me, especially critical stuff

dnolen00:03:35

to be fair it’s thankless work

john00:03:36

this new stuff will make that better

dnolen00:03:03

which I is why I think folding it in, and getting people to use the standard stuff is way forward in the long run

dnolen00:03:20

but this meme that the “community” can do it better

dnolen00:03:23

zero evidence

dnolen00:03:51

and it’s been 10+ years

mfikes00:03:11

Yeah, there is a lot of truth in that

dnolen00:03:14

which is just to say the Rich Hickey way is not bad

john00:03:20

Lots of folks would vote to fold things in

john00:03:29

it's just how much y'all want to maintain

dnolen00:03:48

@john well you get difference of opinions about that of course

dnolen00:03:22

but no we don’t want to maintain sugar-y stuff for the most part

dnolen00:03:43

linting, prettier error messages, etc.

mfikes00:03:39

I'm trying to think back, what was the motivation for cljs.main. Was it always in the back of your mind? Was it clj that finally made it make a lot of sense? Hmm.

dnolen00:03:59

I think I was just irritated that we didn’t have basic Clojure stuff

dnolen00:03:17

and then when I started on it I realized this would fix a lot of problems

dnolen00:03:26

for myself, for testers, and for newcomers

john00:03:33

when did that start?

dnolen00:03:55

cljs.main idea is actually a pretty old ticket

mfikes00:03:57

When you ask: What's next for ClojureScript? Half a year ago you couln't have predicted cljs.main was part of what was going to happen.

dnolen00:03:00

pretty sure 1NNN

mfikes00:03:39

It actually seems to have ended up being more useful that I initally thought.

dnolen00:03:42

but looking back I think that before

dnolen00:03:11

cljsbuild etc. seemed fine - and of course they will continue to be needed useful etc.

dnolen00:03:37

but after spending a lot of time with these tools I think it dawned on me there was some benefit to just have ClojureScript do it out of the box

dnolen00:03:18

and now I think it’s ended up becoming a baseline for user experience

mfikes00:03:34

Right now, without it having been released yet, it is difficult to predict what the uptake of cljs.main will be. Will it be a flop and forgotten? Or will it take over the ClojureScript world? Of course somewhere in between is the answer, but it is hard to predict what it will be. :slightly_smiling_face:

dnolen00:03:35

to be fair - planck, lumo, shadow-cljs had a lot of these affordances already

dnolen00:03:14

but I didn’t really look too closely - just wanted to simulate Clojure

mfikes00:03:53

One thing is crystal clear. The new user Quick Start is much cleaner, and less intimidating and cruft free now.

dnolen00:03:31

I don’t think cljs.main will supplant existing tooling anytime soon

dnolen00:03:30

but also I don’t think it’s hard for people switch either if they are so inclined

mfikes00:03:32

Yeah, I put that tweet in the talk I gave :slightly_smiling_face:

john00:03:58

clj won't be replacing lein at work for a while, until we figure out ways to migrate our project files over

dnolen00:03:22

I know consuming project.clj is something that’s being talked aobut

mfikes00:03:50

Yeah, Alex said something like "it is very easy to do it poorly"

dnolen00:03:00

but in anycase, cljs.main is an investment in the future

john00:03:04

Just seeing a full pedestal stack on it would be interesting

john00:03:30

I don't know, I'm hoping some time in 2018, I can start all projects with just clj/deps.edn/cljs.main things

john00:03:25

Some of the private repo stuff is coming together now I think

richiardiandrea00:03:27

Piggieback was recently "given" to the Clojure-emacs org on GitHub and should receive more love. Agree with everything you say in the backlog here..it is still a heavy weight, hackinsh thing that quickly solved a tooling problem. That is why socket REPL has to happen.

john01:03:50

Looks like lots of emacs folks are moving away from nrepl though

john01:03:17

unrepl and spiral and inf-clojure

richiardiandrea01:03:46

Yeah that is what I hope :smile: socket repl support is already a thing in inf-clojure and spiral/unrepl

richiardiandrea01:03:20

And actually lumo and Planck are directly supported as well thanks to their socket servers

richiardiandrea01:03:37

(in inf-clojure)

john03:03:44

So does anyone have opinions on what method to use to switch between web connected repl clients?

john03:03:19

I've been playing with :, :, etc.

john03:03:53

The original design spec for socket repl mentions this: :repl/attach {:server server-name :client session-id} - attach to existing session and interpret vars in terms of that session

richiardiandrea04:03:49

I like this, it should be always clear and visible which env you are connected to, I think. The command seems to hint at multiple servers in the same socket as well? Did you find that in a Jira?

john05:03:57

I think in that context, :client actually refers socket clients connected via different sockets

john05:03:34

The situation I'm talking about is having multiple socket clients connected to a compiler env that is also connected to potentially multiple web clients

john05:03:17

in the above example, I'd imagine server-name might be something like {:server cljs.server.node :client 3} which would connect you to the same \out\ as some existing socket session.

john05:03:45

So yeah, maybe one day you can just pass your cljs.server.* namespace in and clojure.server will just pull the socket client list off of the env object

john05:03:33

launching a new server should get the last running env if one is already running

john05:03:56

actually, unique envs per server namespace are keyed off of their [host port] pairs

john05:03:41

but clojure.server could know how to go into the @envs of every cljs.server namespace and grab the most recent one, unless you also pass in something like :env-key [host port]

john05:03:48

So I think the call to attach to a repl client and to attach a repl client to one of potentially multiple downstream clients, should be different. Perhaps :repl/attach and :client/attach, where client attaches downstream clients

john05:03:25

from within the context of whatever repl attachment you're in

john05:03:48

and the particular cljs.server.* namespace just deals with the :client/attach situation

john03:03:13

Which never got implemented

john03:03:55

The place to hook into the reader though feeds through tokens though, not lines. I guess you could go popping and pushing values but it's easier just to use one value to represent your repl change request

john03:03:08

and repl quitting is already :repl/quit

john03:03:13

or you could make passing in a map optional, and if it has a particular key, it'll be read as a repl read time command

john03:03:34

like {:cljs.repl/cmd :switch-client :value 3} or something

john03:03:30

fighweel adds {:conn 2} to a prompt when a second connection is made.

john03:03:01

I don't think client switching has been implemented yet

dnolen10:03:14

we definitely need to put together a contributing to Closure Compiler guide

dnolen10:03:32

it’s not hard, but Closure Compiler README itself doesn’t offer enough information

dnolen11:03:07

https://github.com/google/closure-compiler/issues/2846 now has a test case, hopefully this can make it into the May release

dnolen11:03:20

New page documenting how to contribute to Closure Compiler https://clojurescript.org/community/closure

dnolen13:03:42

Kicking off 1.10.238

mfikes13:03:18

Cool. Is this a release candidate? (Is it worth updating docs to point to that number?)

dnolen13:03:40

nah, this is just the release

mfikes14:03:00

OK. Will update any references in docs I've been maintaining.

dnolen14:03:29

Yes, I think we should push everything now, and then we can do announce on the mailing list tomorrow, social etc.

dnolen14:03:35

this includes site stuff

dnolen14:03:39

everything but the announce posts

mfikes14:03:43

OK, I'll leave dates as tomorrow.

dnolen14:03:46

@mfikes I don’t think the date bit is important for anything but the announce posts

mfikes14:03:06

Right. I think that's where dates are.

mfikes14:03:37

There are a lot of compiler option PRs that may conflict that we can merge early and resolve conflicts on.

dnolen14:03:59

release is building

mfikes14:03:05

Ahh cool regarding the news label. I realized after the fact that we may have been able to use a label instead of the gist above to achieve the same.

john14:03:28

how do you guys want documentation typo reports / PRs?

mfikes14:03:22

For small typos, you can just use the ability to edit directly and submit a PR. https://clojurescript.org/community/contributing_site#minor

mfikes14:03:46

(For a typo in merged content.)

dnolen14:03:50

@mfikes yeah I think we only have three news posts

dnolen14:03:58

I merged the new Quick Start

dnolen14:03:25

@mfikes I think 156 & 178 are good for tomorrow

john14:03:39

@mfikes my edit button on github, when editing directly, is grayed out and says "you must be signed in and have push access to master branch to make changes" which is weird if it's just a PR right?

dnolen14:03:40

and then I think 185 should wait till Wednesday while those first two soak in

mfikes14:03:55

OK, I can set 185's date for Wednesday

dnolen14:03:19

creating the uberjar, hopefully this is the last release we have to do that

john14:03:26

@mfikes Sorry, I was looking at the source view directly. It does let me edit from the reading view

dnolen14:03:56

@mfikes so I’ll merge those two posts in the am tomorrow

mfikes14:03:08

One minor issue to resolve is that the main new article for 1.10.238 has a link to the Shared AOT Cache news article, which would come out later. One way to resolve this would be to simply eliminate the small paragraph that says "You can read more at Shared AOT Cache."

mfikes14:03:09

If we do that, perhaps I can add a tiny bit more to that copy, to point to the :aot-cache compiler option or somesuch

dnolen14:03:50

I would change that to say that more information about that will be coming later

dnolen14:03:57

and link to the docs

mfikes14:03:01

I guess, it would link to the news section as a whole. Let me see...

dnolen14:03:50

seems fine

dnolen14:03:01

if we want to edit that to point to post later - easy enough

mfikes14:03:06

Definitely. In hindsight, this time around instead of a "Sneak Preview" pre-release series of news posts, we are doing a post-release series. :slightly_smiling_face:

dnolen14:03:47

after this release, I think we should just shoot for monthly releases a la Closure - I didn’t expect this one to take so long, almost six months?

mfikes14:03:24

Right, that can be good and bad.

mfikes14:03:44

There may be lots of bugs people have been waiting for for too long.

dnolen15:03:15

still this is an impressive release - a huge thanks to everyone that contributed and tested

dnolen15:03:23

@r0man btw I think I know why noone can reproduce your problem and I didn’t really believe the bug report since the situation seemed impossible wrt. code

dnolen15:03:00

the build will use whatever is in resources/brepl_client.js, we should clean that - and I think you have a bad one in there

dnolen15:03:21

we build a cached one

jannis15:03:36

There's still a tiny PR pending to fix a list item and add mention for the :package-json-resolution flag: https://github.com/clojure/clojurescript/pull/71

mfikes15:03:13

^ Jannis you probably want to make a patch instead

mfikes15:03:22

And attach it to a JIRA

dnolen15:03:46

Yeah I never look at PRs on ClojureScript

jannis15:03:45

Can do, just thought I'd reduce the hassle with a tiny improvement like that. I can get a patch ready tomorrow morning.

jannis15:03:33

@dnolen No problem

dnolen15:03:18

We don’t take PRs at the moment, that might not have been clear

jannis15:03:26

It's good to know though ;)

mfikes15:03:45

I have no experience with it, but there is a pull request template feature that could be abused to essentially include copy to redirect requestors to instead ensure CA signed and submit a JIRA patch. https://help.github.com/articles/creating-a-pull-request-template-for-your-repository/

alexmiller16:03:19

I have a PR template for clojure-site

alexmiller16:03:42

feel free to steal

jumblemuddle17:03:21

@dnolen Thanks for taking a look at the node repl / piggieback issue. I kinda assume it was going to be something that should be changed in piggieback, though I appreciate you implementing that piggiehack. :smile: It works like a charm. Thanks, @mfikes, for testing as well. Sorry I wasn't around to test.

jumblemuddle17:03:32

@john You mentioned spiral/inf-clojure; do you have experience moving from cider to one of those? Can you speak to the quality and usability of either one?

richiardiandrea18:03:50

I can speak for inf-clojure as I am the main contributor now, of course it is awesome :smile: However I am still working on cljs REPL integration. I am using lumo with it now and it works like a charm. Of course nothing fancy, as inf-clojure is on purpose just a thin layer on top of a normal REPL. Spiral is more complex and it employs the unrepl protocol, with a couple of very innovative ideas. The one I like the most is that you don't have to have any of the dev dependencies on the classpath of the server: the client sends the namespaces that it would like to use.

john19:03:09

Yeah, I'm not an emacs user, so I couldn't say.

mkvlr18:03:03

@jumblemuddle think this is best asked in #unrepl which spiral is an implementation of (@volrath is the author of spiral and is in there as well). I think unrepl is very well designed, curious to know how it works for you if you give it a shot.

jumblemuddle18:03:27

@mkvlr Thanks, I'll go there.

john23:03:28

is 1.10.238 up on maven?

mfikes23:03:50

The last one took 12 hours to appear. It looks like we are only 9 hours into the process. :slightly_smiling_face: