This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-06
Channels
- # aleph (2)
- # arachne (4)
- # aws (3)
- # beginners (196)
- # cider (131)
- # cljs-dev (208)
- # clojure (193)
- # clojure-boston (1)
- # clojure-dev (26)
- # clojure-greece (4)
- # clojure-italy (26)
- # clojure-losangeles (1)
- # clojure-russia (11)
- # clojure-spec (40)
- # clojure-uk (78)
- # clojurescript (168)
- # cursive (25)
- # datascript (1)
- # datomic (31)
- # docker (8)
- # docs (1)
- # emacs (20)
- # fulcro (62)
- # hoplon (3)
- # jobs (1)
- # leiningen (3)
- # luminus (1)
- # nrepl (25)
- # off-topic (10)
- # other-languages (3)
- # parinfer (11)
- # planck (37)
- # portkey (54)
- # protorepl (11)
- # re-frame (2)
- # reagent (19)
- # remote-jobs (1)
- # ring (2)
- # rum (8)
- # shadow-cljs (23)
- # spacemacs (4)
- # uncomplicate (6)
- # unrepl (77)
- # vim (56)
- # yada (2)
hrm socket REPLs have me thinking that we should probably be sharing JS environments … need to think about this more
from my inexperienced point of view it seems that the default-compile
stuff is exactly what needs to be executed on another thread for the socket REPL. It seems things in cljs.main
can be reused....but again, I don't have the complete pictures in front of me...
Maybe with 1.10.x, ClojureScript REPLs should align with Clojure, and print the version instead of the bit about :cljs/quit
:
$ clj -m cljs.main
ClojureScript 1.10.126
cljs.user=> ▊
I think we should tag array-index-of-keyword?
(and so on) with @noinline
. This way JS engines can optimize the functions better with IC lookups (it'll see the same type)
ok this is pretty cool 🙂 Socket REPLs give us a pattern for sharing JavaScript environments
I'm curious if you are adding "REPL isolation" for Socket REPLs, which means that each Socket REPL gets its own *1
, and other dynamic vars
I think Clojure does that here https://github.com/clojure/clojure/blob/2a08ef40018f1b504602545603eec840b05b33b1/src/clj/clojure/main.clj#L66
Yep, Plank's socket REPL was exactly the same. Got it working, and only added isolation later.
https://github.com/clojure/clojurescript/commit/81a39e581b8bbcb63444e1df7041c2414b0f3958
So hopefully this will solve that Jira ticket, but is this possible only for browsers? Should we apply the same patch to all the other repls or there are other pitfalls there?
it doesn’t matter which one you quit, as long as one is open the environment is persisted
tickets welcome, I’m not planning on stalling the release for this, but I just wanted to make sure that we have a good shared env socket REPL working that people can kick the tires with - I think hardening socket REPL / pREPL is probably the focus of the next release
I'd really love to see talk of just making the browser/server repl env more robust period
I read the Quick Start and its funny that I don't see the following sentiment spelled out explicitly, if the main CLJS tools are just toys not intended for real work, this should be stated clearly eh?
I, also, don't see that sentiment in the tweets announcing the features that cljs.main
provides
Why are we still in this situation making these tools the core of the initial presentation of CLJS while at the same time sharing the unspoken belief that they don't have to be robust because the are just for beginners, or experienced folks who need to test something really quick?
@dnolen I think I’m having a little a-ha moment after what you told me yesterday. Is it correct that basically, we let Closure handle the JS dependencies/modules and then “all” we do is compile the CLJS sources such that they are compatible / in sync with what we think Closure does with the JS files (e.g. module names in goog.provide/goog.require)?
I guess there’s one earlier step in the pipeline where we index / collect the JS files that we think Closure should process.
@bhauman we have be realistic about time and effort and coordination no? That’s what I was implying
@dnolen Pfew, I finally understand something! I’m a little sad it took me so long though. 😉
@bhauman also I don’t really follow, cljs.main is intentionally an extensible pattern not tied to any particular ecosystem tool so I don’t see what is misleading here?
@dnolen I'm talking about the Browser REPL and how it continues to be central to our introductory material, which clearly emphasizes its use. And I think it is miss-leading if everyone in the community knows that it can't be used to do "real work", but we don't tell newcomers that. Also I do think that as we raise the browser repl to be the default cljs.main experience, that yes people (including experienced cljs devs) are going to expect it to work better than it has in the past. The disclaimer that "but this doesn't really work that well, this is just for toy examples" isn't there. And it shouldn't be ... it should work very well and developers should be able to use it and rely on it. Yet all these improvements continue apace, let's simply bring the browser REPL (and the watcher) on board for the ride. They are much more important IMHO
I still don’t really follow, none of the REPLs by themselves are great for real work. They all require non-trivial setup to integrate with web server
So you don't think that given the tweets, and the the demos, or that someone who reads in the QuickStart without any knowledge of the ClojureScript community, will not get the impression that we are recommending this as "a" or even "the" way to work with CLJS? And that they could perhaps mistakenly perceive this as the CLJS experience?
these sorts of things are always intentionally light weight introductions so you can play around
based on the feedback on new Quick Start (from beginners and from people who use Figwheel, boot or whatever), I think this is well understood
@bhauman what I’m trying to say is you’re stating something which doesn’t seem directly related to a completely different thing - which is “yes the browser REPL needs a lot of work”
@bhauman all this said I very much am thinking about making cljs.repl.browser
less of a toy - but I’m approaching this from a very different vantage point - making it compose with Socket REPL & pREPL - and ensuring I can add it to Pedestal project or whatever
I am not currently interested in looking at extending the features beyond what the Clojure REPL provides at this point - i.e. hot-reloading - can think about that at some other point when all the fundamental ducks are in row
It would be nice to get to the bottom of the inexplicable "does not connect" issue that seems to occur. (Worried about new users being turned away, concluding that "this stuff doesn't work at all".)
No, on my macOS boxes, I get a failure rate that might be around, say 20% of the time.
@richiardiandrea sharing JS environment is possible for all Socket REPLs, in fact browser REPL is really the only super annoying case
Ok so let me rephrase the question: should the fix be applied to node repls as well? As you know i am very interested in solving that Jira ticket 😃
@dnolen The funny thing is… both graphql
and iterall
have .js
modules side by side with .mjs
, but their package.json
files use "module": "index.mjs"
. I wonder if it would be better and less evasive to fallback to index.js
when encountering a package.json
like that (and if index.js
exists of course).
@richiardiandrea look at what I did and go fix it 🙂
so I was thinking about a change that applies that mechanism to all repls, how does it sound? asking because most of the times I am wrong 😄
the only thing I am unsure of is the lock
, with those many atoms and binding
s I thought you would not need to lock
yeah you need to look carefully at what I did for browser (which actually still has some issues)
yep I know, in replumb
I employed some trick, let me try if I can send it over to you...or actually...I might just write some bunch of code and see if you like it 😄
the retry always happens and you need to make sure you set a state like :initializing
and the next transition function does not do anything when it sees that
yep that is how to achieve idempotency basically with atoms only 😄
lol ok
node --trace
tells me it’s using index.js
. Looks like I can drop the .mjs
wrestling and just change how Closure & CLJS go from package.json
to index.(m)js
.
@dnolen And you’re probably right to. I’m going back to CLJS master and see how far I can get importing graphql and iterall without .mjs
files being involved at all.
@dnolen Ah. We explicitly pick "module"
over "main"
in module_deps.js
. That’s why index.mjs
is picked up instead of index.js
(`"main": "index"` is also set).
maybe @anmonteiro knows why?
I think it’s right
If it is, I think we may have to special-case "module"
entries that use .mjs
files (until those are stable).
If I swap module and main, it picks up all the JS files and most things work (all the graphql modules loaded from .js
files are present at runtime, e.g. module$Users$jannis$Work$oss$clojure$clojurescript$node_modules$graphql$type$definition
)
we default to ["browser", "module", "main"]
to mimic webpack resolution
we can probably expose a flag in the CLJS compiler too: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1786
that sets those options
again, I think ["browser", "module", "main"]
is correct, otherwise we run the risk of processing bundled files which may not yet be read by Closure due to the UMD problem
Yep, I agree it’s correct. But if "module"
points to a .mjs
file then we’d either have to support .mjs
files or attempt a fallback to the corresponding .js
.
With .mjs
being experimental right now, I’d lean towards the latter. What do you think?
I think we could support .mjs
actually. AFAIK it’s in Node.js Current
I don’t think it’s experimental anymore. Checking
experimental
@mfikes https://dev.clojure.org/jira/browse/CLJS-2620, we just need to make sure quit-prompt
usage still works
and we need a better title for the new flag something more generic repl-title
or something
@dnolen Yeah, and I was pondering even conditionally wrapping so that nil
could be though of as “off”
(when quit-prompt
(quit-prompt))
Added another patch, illustrating various use cases of suppressing and/or replacing the title and quit-prompt
Nice. The MapEntry
qualification commit (https://github.com/clojure/clojurescript/commit/ed385ad484f9c6b2471b0ee371fac805d8194c3e) fixed the issue with prismatic.schema (claris.rules) 🙂
Mmmmh, how do we feel about being able to do the following?
:npm-deps {"/path/to/local/npm-package-0.1.0.tgz" "0.1.0"}
I had the idea after looking at http://podefr.tumblr.com/post/30488475488/locally-test-your-npm-modules-without-publishing and it’s a ~3 line change in cljs.closure/maybe-install-node-deps!
. Essentially:
(ProcessBuilder.
(into (cond->> ["npm" "install" "@cljs-oss/module-deps"]
util/windows? (into ["cmd" "/c"]))
(map (fn [[dep version]]
(if (and (string? dep) (.exists (io/file dep))) ; this is new
dep ; and this
(str (name dep) "@" version))))
npm-deps))
Oh this is cool
Yeah, all it requires is a directory with a package.json
and at minimum one .js file, so existing (or private) code doesn’t necessarily have to be published via npm first.
Browser REPL for uberjar built from master is connecting completely reliably for me
while true; do cat repl-input.txt | java -jar cljs.jar; done
just loops without ever failing to connect.Oddly (I forgot this fact about Windows): You can just "run" the cljs.jar
; Windows knows what it is and has Java run its embedded cljs.main
.
I’m super happy the browser repl is getting a little makeover. The new experience is super slick.
BTW, here is the potential revised copy for the browser REPL:
Welcome to the ClojureScript browser REPL.
This page hosts your REPL and application evaluation environment. Validate the connection by typing `(js/alert "Hello CLJS!")` in the REPL.
To provide your own custom page, place an `index.html` file in REPL launch directory, starting with this template:
(Trying to make it succinct, without being too terse / curt.)I’m wondering if we now feel comfortable removing that little debugging note from the docs
https://github.com/clojure/clojurescript-site/blame/master/content/guides/quick-start.adoc#L409
@potetm it’s not in there anymore, @mfikes has experienced spottiness but I cannot reproduce here
@potetm yeah I’m getting a little bit frustrated at it at the moment trying to wire it up programmatically to Socket REPL, there’s definitely a strange race condition in there
if you write a program that tries to connect twice via Socket REPL, you’ll probably be able to recreate the issue
second REPL thread calls setup, but someone already started so it skips, but then it gets to the other initialization stuff sooner
I think the issue must be something about the second REPL getting to browser-eval
first
but I see the 2nd REPL never gets past the first form for evaluation - declaring (ns user ...)
Hmmm…. nothing is jumping out offhand. Esp. w/ the lock in place. Like you say, it’s tough to reason about w/ the dynamic vars in play.
My plane is landing right now. I’ll see if I can get it breaking on my box later and go from there.
what is the lifecycle of the repl? because what if you try to lock the whole thing? just to see if the problem is the fact that -evaluate
or -load
should also be within the critical section...did not have time today but these problems are fashinating (and frustrating) at the same time
Not sure I follow, but repl-env lives throughout the repl session. As the name implies, setup
is called once at the start, subsequent operations are made via on user demand evaluate
and load
.
ok I am new to this so thanks for explaining me that 😉
Draft update for the browser REPL copy in https://dev.clojure.org/jira/browse/CLJS-2623
Yeah I'm not at all shocked that there's a bug there for brepl. I almost automatically lean towards a refactor. I'll take a closer look in a bit.
@potetm I don’t actually think it needs a huge refactor cljs.repl.server
is understandable