This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
@mfikes: is there already something like lein try
for planck? https://github.com/rkneufeld/lein-try
@jellea: No… the bigger question in my mind right now: Can ClojureScript libraries in general be used in self-hosted “mode”.
@jellea: But, to directly answer your question: Currently the only mechanism for using code in Planck is via its source directory parameter, but that could be extended to consume things from JARs, etc. Happy to take PRs that lead to more flexibility.
@mfikes: hmmm interesting, will think about it is somebody already working on consuming things from jars?
@jellea: No. The closest it currently gets to the concept of “classpath” is that the -s
argument is repeatable, thus allowing you to specify multiple source directories. https://github.com/mfikes/planck/issues/18#issuecomment-127800764
@dnolen: has there been any conversation, thought, about recopying properly namespaced (i.e example/core.cljs requires "example.tester" in example/tester.js) closure libs to the output dir on incremental compile?
it would be pretty sweet because right now properly namespaced closure libs work without specifying them in :libs
@rauh: I would be interested in whatever you come up with by way of a list of cljs type hints. Maybe we could get you to create a wiki page?
@meow: Hmm yeah I did find a few in core.cljs and core.cljc, but I'm not sure yet how they all work together. Especially also with the Closure compiler type checker
The thing with type hints is that they're silently ignored so you never know if they did something
Also wasn't @dnolen talking about Google Closure type hinting in docstrings or something?
@meow: Yes the closure stuff is documented: https://github.com/clojure/clojurescript/wiki/Compile-Time-Type-Checking
One can get carried away with optimizations. Great way to kill a few days. So much fun...
@rauh: If you haven't played around with Devcards you should. They rock! You might like them.
@bhauman: I think I'm a nap and fresh pot of coffee away from forking devcards so I can attempt to create some PRs with the features I was asking for. Gonna give it a shot, at least.
@rauh: I just saw them in core.async and figured they were some kind of useful optimization hints, but I have no idea what they do.
@meow: hit me up if you have questions. For instance the ordered map thing is really just sorting the keys in the edn printer.
@bhauman: Yeah, I figured that one should be easy, and getting the source code for a function on-the-fly.
Well, I was thinking it might be nice to have something that worked magically inside of markdown text.
@rauh: oh, there is ^:const also - are you only interested in type hints or any optimizing hints?
@bhauman: okay, I'll keep that in mind. I was going to cheat and see if I could find out how Sean Grove was doing it in some code of his that I think I saw a while back. At least I'm pretty sure it was him.
Another Figwheel improvement (besides GCLosure JS reloading) is that dependents can be reloaded automatically without needing to specify :recompile-dependents. This I think is a big improvement that obviates the need for ^:figwheel-always. This is in 0.3.8-SNAPSHOT
@meow: Actually you're right ^not-native
seems to be a type hint, though I think it might be internal. ^:mutable
and :const
are tags for the compiler (not type hints).
@bhauman: Does Figwheel now use Closure dependency data to load changed files in correct order?
I could create a branch and install it locally, but I'm open to suggestions for the easiest way to work out of the live code rather than having to do a local maven jar install cycle
When I've been working on my own stuff I've "cheated" by using boot to include my library development directories in the classpath. Not sure how folks do that sort of thing with lein.
@meow: not sure, but i think you might want "checkouts": https://github.com/technomancy/leiningen/blob/master/doc/TUTORIAL.md#checkout-dependencies
@jackjames: cool, thanks
@juhoteperi: the answer to that yes! It loaded dependents in correct order before. I was un aware that I broke dependency loading order a while back. Now it works really well. Reload-all works as well. And I'm thinking of defaulting to loading dependents as that is the natural behavior that folks expect.
@bhauman: Interesting. I was exploring using that for boot-cljs/reload instead of getting dependency graph from cljs compiler state.
@meow: you can work on it live just by running lein figwheel and loading devcards/index.html in your browser.
@juhoteperi: the auto reloading of GClosure js is very cool as well
@bhauman: Reloading foreign-deps and closure libs? Boot-cljs/reload supported it before I broke dependency ordering. Will work again when Cljs API has dependency ordering call.
@juhoteperi: just GClojure libs for now.
@juhoteperi: without a :libs config
@juhoteperi: you should look at file_reloading.cljs it's getting closer and plays much better with cljs and closure. I think I need to get rid of core async dep. but we could share this code. https://github.com/bhauman/lein-figwheel/blob/master/support/src/figwheel/client/file_reloading.cljs
dependencies_
probably means it's supposed to be private, I wonder if Closure project would be interested in providing API to access the data?
@bhauman: Where does cljs repl implement this?
Found it