Fork me on GitHub
#clojurescript
<
2015-08-16
>
rauh00:08:23

Is there somewhere a list of all cljs type hints that we can use?

jonas04:08:23

@mfikes: yeap, looks like it’s a (bootstrapped) clojurescript issue.

mfikes04:08:57

@jonas: Yeah, that’s my current guess. I haven’t tried to figure out what it is.

mfikes04:08:45

@jonas: It was actually discovered a day before Planck even existed simple_smile

tel13:08:17

@mfikes: that is so cool! and just what I was missing

jellea14:08:36

@mfikes: is there already something like lein try for planck? https://github.com/rkneufeld/lein-try

mfikes14:08:49

@jellea: No… the bigger question in my mind right now: Can ClojureScript libraries in general be used in self-hosted “mode”.

mfikes14:08:34

@jellea: (For example, the use of macros that can’t compile as ClojureScript.)

mfikes14:08:57

@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.

jellea14:08:23

@mfikes: hmmm interesting, will think about it simple_smile is somebody already working on consuming things from jars?

mfikes14:08:41

@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

mfikes14:08:29

@jellea Perhaps embracing the classpath idea would work out.

bhauman15:08:30

@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?

bhauman15:08:07

it would be pretty sweet because right now properly namespaced closure libs work without specifying them in :libs

bhauman16:08:57

it would allow require :reload to work in this situation as well

meow18:08:57

@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?

rauh18:08:05

@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

rauh18:08:48

The thing with type hints is that they're silently ignored so you never know if they did something

rauh18:08:53

I have this list for hinting: boolean array number string seq function object

meow18:08:13

I think I've seen ^:mutable ^:not-native

meow18:08:49

Also wasn't @dnolen talking about Google Closure type hinting in docstrings or something?

bhauman18:08:50

yeah a catalog of what they actually do would be amazing

meow18:08:16

So far I've just put them off.

meow18:08:47

One can get carried away with optimizations. Great way to kill a few days. So much fun...

meow18:08:51

@rauh: If you haven't played around with Devcards you should. They rock! You might like them. simple_smile

rauh18:08:52

Btw, the ^:mutable and ^:not-native are no type hints AFAIK

meow18:08:02

@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. simple_smile

meow18:08:52

@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.

bhauman18:08:07

@meow: hit me up if you have questions. For instance the ordered map thing is really just sorting the keys in the edn printer.

meow18:08:03

@bhauman: Yeah, I figured that one should be easy, and getting the source code for a function on-the-fly.

bhauman18:08:42

@meow: yeah that exists in cljs arleady no need to bring it into devcards simple_smile

bhauman18:08:11

@meow: an example would be great though in the api docs

meow18:08:25

Well, I was thinking it might be nice to have something that worked magically inside of markdown text.

meow18:08:21

But I would start with just making it work with a normal function.

bhauman18:08:08

in markdown would be hard because it's a macro that gets the data at build time

meow18:08:26

@rauh: oh, there is ^:const also - are you only interested in type hints or any optimizing hints?

bhauman18:08:26

no var data at runtime

meow18:08:17

@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.

bhauman18:08:49

yeah he was doing it in the gamma stuff

bhauman18:08:59

the playground

meow18:08:18

yep, that's what I thought I remembered

meow18:08:36

seemed like a mighty fine idea when I saw it

bhauman18:08:26

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

rauh18:08:14

@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).

juhoteperi18:08:40

@bhauman: Does Figwheel now use Closure dependency data to load changed files in correct order?

meow18:08:32

@bhauman: okay, I created a fork of devcards

meow18:08:57

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

meow18:08:39

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.

meow19:08:16

@jackjames: cool, thanks simple_smile

meow19:08:49

ugh, symlinks - unfortunately I'm on windows at the moment

bhauman19:08:00

@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.

juhoteperi19:08:57

@bhauman: Interesting. I was exploring using that for boot-cljs/reload instead of getting dependency graph from cljs compiler state.

bhauman19:08:03

@meow: you can work on it live just by running lein figwheel and loading devcards/index.html in your browser.

bhauman19:08:40

@juhoteperi: the auto reloading of GClosure js is very cool as well

bhauman19:08:36

@meow: you can do the same source -path trick in Figwheel. I do it all the time.

bhauman19:08:17

For cljs checkouts is overkill, source paths is easier and more flexible.

juhoteperi19:08:19

@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.

meow19:08:46

@bhauman: ok, thanks. I'll give it a shot.

bhauman19:08:52

@juhoteperi: just GClojure libs for now.

bhauman19:08:27

@juhoteperi: without a :libs config

bhauman19:08:00

You can just add your js file next to you cljs files

bhauman19:08:22

@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

juhoteperi19:08:37

dependencies_ probably means it's supposed to be private, I wonder if Closure project would be interested in providing API to access the data?

bhauman19:08:53

I'm using the same patterns as cljs repl

juhoteperi20:08:23

@bhauman: Where does cljs repl implement this?

dottedmag22:08:31

I am following modern-cljs tutorial, but brepl is very flaky: it does not connect most of the time (I see there is no long-polling connection open after <iframe> loads the REPL code). Is it a known issue?