This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (14)
- # aws (27)
- # beginners (10)
- # boot (152)
- # cljsrn (3)
- # clojure (93)
- # clojure-hk (4)
- # clojure-russia (35)
- # clojure-switzerland (1)
- # clojurecup (1)
- # clojurescript (146)
- # core-async (23)
- # cursive (2)
- # devcards (1)
- # editors (1)
- # hoplon (28)
- # jobs-rus (4)
- # ldnclj (3)
- # leiningen (3)
- # luminus (2)
- # off-topic (4)
- # om (174)
- # re-frame (1)
- # slack-help (5)
updating boot fixed the error 😃 i was on 2.2.0 via homebrew. didn’t realize it was outdated.
have you ppl seen https://shaunlebron.github.io/parinfer/ yet?
@sekao: though im still a subime user at the moment, i like your vision with nightcode! my colleagues enjoyed your narration of Quest Quest too 😉 https://youtu.be/0GzzFeS5cMc?t=2083
on that note, as a continuation of my parinfer quest, i've just realized that Visual Studio Code has just been open sourced aaand got an official plugin system too https://code.visualstudio.com/updates that makes it a serious alternative to sublime actually... despite being a full blown ide, it's quite frugal still. might be a light weight alternative to cursive...
@onetom thanks very much! And yeah I've seen parinfer, it looks great. I made something kinda similar in pure clojurescript here: https://github.com/oakes/paren-soup
@onetom: Looks like there is a parinfer for atom : https://github.com/oakmac/atom-parinfer
No - I think it’s a great way to get noobies using clojure w/o having to learn emacs/paredit
Yeah - smartparens works pretty well for me. Off topic for the #C053K90BR channel - how are you liking spacemacs?
and my workflow is more buffer based, and i couldn't get a good way to swap buffers without a lot of keystrokes
the only problem with vim is that the package mangers have no concept of transitive dependencies
Seems to me that
boot should be included in the clojurescript Quick Start and Dependencies sections.
Seeing increasing “Yeah I switched to boot and clojurescript builds are so much more approachable.” in #C03S1L9DN channel.
Yeah but there is a big pull to figwheel/devcards in the community — need a solid story there for
been mostly working on the 2.5.0 release of boot when i have a minute for recreational programming
@donmullen: Devcards works with React.js components only
@juhoteperi: Thanks for confirming.
Or well, I could be wrong. Readme mentions it should work with any Cljs code.
I think there is an impression that if people leave lein or homemade scripts for boot - they loose figwheel.
Not yet. I haven't had time or incentive to work on Boot-reload as it's working well enough for me.
If figwheel isn’t really getting additional features - then makes sense to just leave well enough alone.
Probably boot-reload and boot-cljs-repl will be integrated into boot-cljs and then renaming that wouldn't make sense
There was some reason... maybe
Boot-reload might require additional dependencies
But there could be a way to add deps to cljs compiler pod through cljs.edn perhaps
It will need to use Closure so I doubt writing Closure JS would make it any faster
Also, we need more complex client, not simpler
There bunch of problems with current implementation that break reloading in some cases
It needs Closure dependency graph
just whatever produces the js files should annotate the fileset with the info reload needs
Hmh, using metadata on fileset could be useful, might help with some of the problems, like only reloading JS files belonging to the open application
Still, I have little interest in fixing things that have been already solved in Figwheel client code
Also, "inject it into the page" would be surprisingly hard
But how to edit the served html?
No, I generate index html with Hiccup
I could but I don't want to. Generating it in the code makes it trivial to add cache-busters and to enable development tools with environment variables.
I think it makes more sense to just have separate reload tasks for Cljs and non-Cljs development
there are probably all kinds of unexpected useful tools that can use that to do things for you
but you're right, there should bedifferent specialized tasks for different purposes too
@juhoteperi: i haven been thinking about the gpg change in 2.5.0
Is there any reason to use the old way?
The new implementation should be compatible
only if someone is already using it and doesn't want to change their things to the new way
I feel strongly that the new implementation is correct and old uses bad practices and is unusable in some cases (CI)
Hmh I guess it's okay
Is it possible to set in on the global ~/.boot/cache/boot.properties?
boot -u leave other properties besides version in that file alone?
I think the GPG option is more about user than about project
but i spent an hour today with a gem issue that resulted in a shitshow in production that came out of nowhere