Fork me on GitHub
#clojurescript
<
2016-06-25
>
abdullahibra13:06:41

how can i create slack interface using clojurescript?, is there a library which will help in this?

shaunlebron14:06:06

@dnolen: should clojure.spec.gen alias to cljs.spec.impl.gen?

shaunlebron14:06:12

and if we preferred cljs.* usage, should we alias cljs.string => clojure.string, etc

dnolen15:06:37

@shaunlebron: yes to the former. We’re not doing any more aliasing.

dnolen15:06:27

yesterday changes were about eliminating differences between Clojure & ClojureScript not aliasing specifically

shaunlebron15:06:05

i’ll think about whether to list such namespaces in the api docs as clojure.* whenever possible

shaunlebron15:06:49

i’ll check the differences in their api and see if that’s a good idea

shaunlebron15:06:22

i imagine the original intention of using cljs.foo convention was that there would be api differences with the ported clojure.foo ns

dnolen15:06:47

that’s not the reason actually

dnolen15:06:03

it’s only about macros

dnolen17:06:48

@shaunlebron: most of the api differences between (clojure|cljs).(test|pprint|spec) are whether something is a macro or not

dnolen17:06:18

test and spec in particular rely on runtime metaprogramming stuff that we can’t do in ClojureScript so some thing which would otherwise be functions are macros instead

shaunlebron17:06:52

now that you implemented implicit referring, would you consider the clojure.* to be the recommended interface, and the cljs.* namespace to be an implementation detail?

shaunlebron17:06:25

oh actually, the (clojure|cljs) namespace naming differences in clojurescript are a separate issue from implementation differences with the clojure libs

shaunlebron17:06:35

okay, there is a clj clojure.string, and a cljs clojure.string

shaunlebron17:06:59

but a clj clojure.test and a cljs cljs.test

shaunlebron17:06:03

the naming choice for cljs took a turn to start using cljs.*

dnolen17:06:49

@shaunlebron: it’s important to understand what I said earlier

dnolen17:06:03

we only use cljs.* when we *can’t* use clojure.*

dnolen17:06:12

there is no other reason

dnolen17:06:21

nothing to do with API differences

dnolen17:06:02

ClojureScript clojure.string doesn’t require macros so there’s no conflict with Clojure clojure/string.clj

dnolen17:06:33

Clojure clojure.spec requires macros so we can’t use it

dnolen17:06:47

because we need to define both clojure/spec.clj and clojure/spec.cljs

dnolen17:06:53

but this isn’t possible

dnolen17:06:07

Clojure already claimed clojure/spec.clj

dnolen17:06:04

to be fair - in my experience is that hardly anyone understands this except for people who spent time contributing to the compiler

shaunlebron17:06:30

well, this is still confusing

shaunlebron17:06:55

src/main/cljs/ and src/main/clojure

dnolen17:06:06

those are beside the point

shaunlebron17:06:09

former being the library and the latter being the compiler

dnolen17:06:18

there’s no need to look at the source tree to understand what I am saying

dnolen17:06:36

Clojure implemented clojure.spec by creating clojure/spec.clj

dnolen17:06:58

for us to port clojure.spec we need to create clojure/spec.clj and clojure/spec.cljs

dnolen17:06:04

one for macros one for runtime

dnolen17:06:14

but we cannot create clojure/spec.clj

dnolen17:06:32

because there’s no way for the compiler to not accidentally load Clojure clojure/spec.clj

dnolen17:06:40

and not our macros file

shaunlebron17:06:02

because in jvm clojurescript, that accident could happen

dnolen17:06:10

that exactly right

dnolen17:06:22

the compiler has no idea what’s in a macros file and whether it’s for ClojureScript or not

dnolen17:06:55

if macro files had a different extension this could be avoided

shaunlebron17:06:59

i thought they were separated for some reason

dnolen17:06:05

as I said hardly anyone who hasn’t contributed to the compiler understands this subtlety

shaunlebron17:06:32

so implicit referring and ns aliasing allows cljs files to pretend that this naming issue isn’t there

dnolen17:06:49

for core namespaces yes

dnolen17:06:57

for user created libraries it’s not a big deal anymore because of reader conditionals

dnolen17:06:24

but reader conditionals didn’t fix the problem for core namespaces

dnolen17:06:34

that’s why I worked on this yesterday - to clean this up

dnolen17:06:25

(well except for the :refer bit which accomplishes something reader conditionals can’t do)

gowder17:06:44

This is going to be amazing. Really happy to see it!

shaunlebron17:06:42

which is auto-referring without regard to its type

shaunlebron17:06:18

thanks for walking through subtleties

dnolen17:06:34

@shaunlebron: the auto-referring thing is pretty simple

dnolen17:06:47

we simply filter all the refers we couldn’t find in the runtime ns - and we try to see if macros exist for those

dnolen17:06:02

we don’t find them we error out as var not found errors

dnolen17:06:11

I think thheller actually had something like this working for shadow-build, so he gets credit for the original idea and ticket

gowder17:06:47

I've been wondering for a while about the ultimate source of the cljs macro limitation ---is it just because the compiler is on the jvm? I recall an old @mfikes blog post where he demonstrated how to do bootstrapped macros in the iOS repl just by diddling with the namespace...

dnolen18:06:39

@gowder: bootstrapped ClojureScript is 8mb and does not support advanced compilation

dnolen18:06:43

pretty big limitation

gowder18:06:05

(There needs to be a "slowly understanding nod" slack reaction for when @dnolen offers yet another patient explanation of how this all works )

lwhorton18:06:07

whew, here’s a doosey. When generating an externs file for a js lib… if that lib uses es6 import syntax, including things like import * from ‘./…’, how am I supposed to figure out what to “protect” from inside the externs file? Similarly, that es6 syntax has to be packaged by something … so assuming we bundle with webpack, what’s the deal with the exports there? It looks like webpack actually just ‘exports’ a function that is self-invoked with the dependency map... I’m assuming someone has done this before, given the scope of cljsjs (but I cannot find an example of webpack inside cljsjs packages)

dnolen18:06:28

We’re about 2 weeks away from 5 years of ClojureScript 🙂

dnolen18:06:06

oops, maybe a month?

shaunlebron18:06:39

commit 515900f9762102987bda7d53b919dafc0b6c0580
Author: Rich Hickey <[email protected]>
Date:   Thu Jun 2 19:45:57 2011 -0400

    initial commit

shaunlebron18:06:10

announcement date is probably a better birthday

shaunlebron18:06:22

@lwhorton: do JS libs publish es6 source?

shaunlebron18:06:57

anyway, es6 spec enforces statically analyzable exports/imports, so generating something like an externs file seems possible

lwhorton18:06:35

@shaunlebron: this lib does… ill look around for an analyzer

shaunlebron18:06:53

i mean, you only have to protect the public API, yeah?

lwhorton18:06:02

yes, but even with that i’m not too sure how es6 ‘exposes’ imports such as ‘import *’… for example, `export defaults { button1 as foo, button2 as bar }`. if I `require * from ‘button’` - what do i get?

shaunlebron18:06:47

import * as name from "module-name”;

shaunlebron18:06:17

you get a static export map from module-name

shaunlebron18:06:04

i don’t think you can just do import * is what I’m saying

lwhorton18:06:55

would the extern for that look like: var button = { foo: function() {}, bar: function() }?

shaunlebron18:06:33

i don’t really know

shaunlebron18:06:12

i think an answer would only be meaningful in the context of the transpiled artifact

lwhorton18:06:02

ill keep digging on dr google

shaunlebron18:06:41

exploring the library’s transpiled source or interactively from a js console would give you the vars and paths to include in your externs, yeah?

lwhorton18:06:44

that’s a good idea, ill poke around there too

shaunlebron18:06:10

i wouldn’t get caught up in the es6 stuff, especially when in reality it’s es5 es3 that our cljs applications are interoping with

bpicolo20:06:36

How do people tend to deal with times in cljs?

bpicolo20:06:49

Issues suggest this is not maintained: https://github.com/andrewmcveigh/cljs-time

bpicolo20:06:59

Currently using interop with moment which is naturally unsexy

bpicolo20:06:18

Well, I guess it's maintained, but not working atm : p

dnolen20:06:06

@bpicolo: that’s just a wrapper over Google Closure stuff

bpicolo20:06:27

dnolen right.

dnolen20:06:53

my personal rule of thumb is that if I can use Google Closure directly I will

tomjkidd21:06:37

It's only been a couple days playing for me, but I was able to create a simple audio recorder

tomjkidd21:06:00

Nothing sexy, but I'm happy

volrath23:06:31

Hello, I'm planning on giving an introductory talk to my coworkers about Clojure(Script), to get them interested into this world. We're a web dev company so I'm mostly aiming to give them a taste of ClojureScript, but since they have little to none experience with LISP or functional programming, I need to cover the basics. Any suggestions on resources I could use? Existing talks, articles, exercises or examples? Thanks.

easystreet23:06:30

volrath: the interactive tutorial linked from here has been well-received: http://chimeces.com/cljs-browser-repl/

volrath23:06:52

great, thank you, I'll take a look

zentrope23:06:04

Anyone ever gotten Exception in thread "main" java.lang.NoSuchMethodError: com.google.common.base.CharMatcher.javaUpperCase()Lcom/google/common/base/CharMatcher;, compiling:(/private/var/folders/kl/mtjj27rn63scmln5_xzbtc600000gn/T/form-init2613897690507300801.clj:1:125) before?

zentrope23:06:12

Happens with advanced compilation, even when I comment out everything in my “main” namespace.

zentrope23:06:17

lein deps :tree is clean. I wonder if one of the jars for the server side of the app is interfering? (This is a mixed server + client project.)

zentrope23:06:52

Interesting. If I explicitly set the closure-compiler jar just under the clojure dep itself, it works.

tomjkidd23:06:09

volrath: Stuart Halloway is good at quick up-to-speed for reading clojure code https://www.youtube.com/watch?v=VrmfuuHW_6w&amp;t=13m05s

tomjkidd23:06:25

Its done by 17:40, but that is a really good intro

volrath23:06:11

awesome, that'll be really helpful, thanks!

zentrope23:06:40

It’s datomic. Breaker of all on the classpath.

zentrope23:06:05

excluding com.google.guava from datomic-free seems to do the trick.