Fork me on GitHub
#clojurescript
<
2016-09-05
>
pseud07:09:41

Been searching a little these past days. Is there a way to compile out cljs.spec checks the same way that I might be interested in not having asserts ? Is it as simple as just wrapping those checks in an assert ?

am-a_metail08:09:04

@pseud Have a debug variable and use dead code elimination to compile it out?

anmonteiro11:09:05

@pseud: if you mean cljs.spec/assert, it is that simple, provided you add :elide-asserts true to your build

martinklepsch11:09:28

what was the name of that project that allowed you to write interop forms in a special way that would "extern them" automatically or at least circumvent name munging somehow?

pseud13:09:13

@anmonteiro Super, that鈥檚 exactly what I wanted, thanks 馃檪

mfikes13:09:29

@martinklepsch The closest thing I recall to that is the Externs Inference SoC thing: http://dev.clojure.org/jira/browse/CLJS-1074

martinklepsch13:09:42

@mfikes I managed to dig up the right google query just now: https://github.com/myguidingstar/fence

am-a_metail13:09:07

Is it still the case that a reader-macro wouldn't work?

darwin13:09:28

ad. speaking about externs, just started this little project a few days ago: https://github.com/binaryage/cljs-oops I tend to access foreign js names via strings only, have been using oget oset! macros for over a year with almost no pains and side-stepped the externs problem this way. cljs-oops will be just smart version of those macros, it will compile to plain aget-like code if possible (under advanced optimizations), but will give you a nice diagnostics/asserts in dev builds. ideas welcome!

martinklepsch13:09:30

I just learned about libphonenumber which is a Google Closure compatible library for validating, parsing and formatting phonenumbers. Now in the process of being added to CLJSJS: https://github.com/cljsjs/packages/pull/725 (small example included)

borkdude15:09:35

Are ClojureScript versions 1.9 to be used with Clojure 1.9?

mfikes16:09:09

@borkdude: Nah. If I recall the history, when Spec was ported to ClojureScript, it made sense for it to be released as 1.9.x given that Spec is in Clojure 1.9. But ClojureScript still depends on Clojure 1.8. It can dynamically make use of Spec for macros Spec checks if you are using Clojure 1.9.

mfikes17:09:58

I wonder what Shaun has driving this table: http://cljs.github.io/versions

shaunlebron17:09:12

I actually don鈥檛 specify a version of clojure in my cljs projects, I would hope that would be decided transitively by the cljs version I choose

shaunlebron17:09:11

@mfikes that version table uses the dependent versions at the top of the bootstrap script: https://github.com/clojure/clojurescript/blob/master/script/bootstrap

anmonteiro17:09:26

@shaunlebron the Clojure version that the CLJS compiler depends on is in the pom.template

anmonteiro17:09:13

probably that would be a better guide for CLJS users downstream

shaunlebron17:09:31

interesting, thanks. why the disparity?

anmonteiro17:09:39

AFAIK the bootstrap script is supposed to be for CLJS developers

anmonteiro17:09:53

David bumped Clojure to 1.9 for testing purposes

anmonteiro17:09:07

but releases still depend on 1.8

borkdude17:09:31

Ok thanks, I think it鈥檚 safe to upgrade to 1.9.x then. Will try tomorrow.

shaunlebron17:09:09

@borkdude: yeah, i think that鈥檚 what david is trying to assess by following 1.9 in the bootstrap script

shaunlebron17:09:53

compatible with 1.8 and 1.9-alpha7

micha17:09:23

^^ feedback, comments welcome

flyboarder17:09:41

@micha Interesting can you explain it a bit more?

micha17:09:55

it's just implementing clojure.core/bound-fn in cljs

micha17:09:04

so you can do like this

micha17:09:09

(def ^:dynamic *foo* 0)
(binding [*foo* 100]
  (js/setTimeout (bound-fn [] (prn "foo is:" *foo*)) 0))

micha17:09:18

and it will print foo is: 100

flyboarder17:09:07

awesome! i wasnt aware bound-fn wasn鈥檛 in cljs

shaunlebron17:09:57

is that used for lazy sequences? I鈥檝e been bitten by that a few times

micha17:09:13

it's used for asynchronous callbacks

micha17:09:54

like in the example above, the *foo* var has the value of 0 when the timeout callback is fired

micha17:09:04

like for example

shaunlebron17:09:37

yeah, it makes sense

micha17:09:43

(def *foo* 0)
(cljs.core/binding [*foo* 100]
  (js/setTimeout (fn [] (prn "foo is:" *foo*)) 0))

micha17:09:48

that will print foo is: 0

shaunlebron17:09:11

submitting it to the compiler?

micha17:09:46

it's EPL, and i signed the contributor agreement 馃檪

borkdude17:09:52

"Returns a function defined by the given fntail鈥, what do they mean with fntail?

flyboarder17:09:52

@micha will that be in next hoplon? I dont see the ns in master

micha17:09:23

@flyboarder yeah i'm putting together the release today

darwin17:09:45

it is quite deep problem to solve in a performant way

micha17:09:03

@borkdude fntail is the [] ... in (fn [] ...), if that makes sense

borkdude17:09:46

@micha why does bound-fn accept multiple arguments?

micha17:09:12

it's a function, so it will probably need to accept arguments

borkdude17:09:56

@micha I see, it鈥檚 just a convenience macro to create a function for bound-fn*

micha18:09:47

@darwin i like your idea of making a whole new thing, the zones

micha18:09:00

i wonder if the javascript with form is useful

darwin18:09:21

the problem of my implementation is that we have to wrap every access to 鈥渮oned鈥 var in (zones/get var) call which is a dynamic lookup, problem of your solution is that each call to bound-fn-wrapped function will potentially do a lot of work in storing/restoring bindings

darwin18:09:18

it is a trade-off question: 鈥渨ill my code at runtime call bound-fn-wrapped function many many times (e.g. in a tight loop)?鈥 or 鈥渨ill my code run a tight loop inside my wrapped function to access 鈥渮oned鈥 vars many many times?鈥 or eventually 鈥渨ill my code run through binding form many times and then will rarely call the wrapped function?鈥

dvingo18:09:27

hello, does anyone know how to lookup a namespace var in (non-bootstrapped) CLJS at runtime like - something akin to find-var in clojure which doesn't seem to be in CLJS yet

shaunlebron18:09:02

@danvingo: not sure, but really curious why the need for a var lookup keeps coming up

dvingo18:09:49

i'm trying to write a debug helper for a hoplon app by looping over all the vars in a namespace and displaying their values in a component

darwin18:09:18

@danvingo: it is not there AFAIK, you have to write a macro which emits a subset of compiler state as data into your cljs app

dvingo18:09:56

found this thread, which i haven't tried yet

dvingo18:09:59

very cool, thanks!

darwin18:09:09

@danvingo: also if you don鈥檛 need it to work under :advanced mode, you could just query js environment, goog/cljs namespaces are just plain js objects in non-advanced builds

dvingo18:09:32

ah of course! yea it's just for dev

stbgz18:09:44

hey all so I鈥檝e spent some time reading pommergranate/aether/lenin stack, and if we wanted to move depends resolution out of the jvm

stbgz18:09:00

we鈥檒l need to port almost all of those parts

stbgz18:09:54

it won鈥檛 suffice to just re-implement aether in js or cljs

shaunlebron18:09:20

all of those parts as in just pomegranate and aether

stbgz18:09:45

Lenin uses java stuff as well as some aether classes

stbgz18:09:00

lein sorry

stbgz18:09:20

so does boot

stbgz18:09:24

I think another approach will be to just to re-write those tools in cljs period

darwin18:09:52

assuming nodejs?

stbgz18:09:23

at least at the beginning we could abstract that out for other runtimes later

darwin18:09:57

what it the motivation for this? IMO, unless you make it at least 10x faster, people won鈥檛 start to use it just because it is written in cljs 馃檪

darwin18:09:20

we will end up with a split, few people using it and rest stays with the old stack...

shaunlebron18:09:30

classpath.clj is just using Exclusion constructor for messages, and an exception for dependency errors.

shaunlebron18:09:19

the motivation is to allow a build tool to work without the jvm

stbgz18:09:21

Lein assumes the need for class path and does some work with that

stbgz18:09:28

Class paths don't make a lot of sense in a jvm less world, we would have to rip that out or move around or do something about it

stbgz18:09:44

The way I see it all we need is the ability to fetch dependencies from clojars or a maven repo, and resolving those dependencies for the compiler to work properly

stbgz19:09:25

Fortunately the bootstrapped complier delegates the resolutions of dependencies externally so aside from fetching dependencies all we need to do is implement the load-fn to point to the downloaded dependencies

micha19:09:35

@darwin i actually like the zones/get part

micha19:09:12

looking at your implementation i now understand how "zones" and variables are really fundamentally different

micha19:09:38

having the clear semantic difference is, i think, actually a good thing

micha19:09:46

like in cljs the concept of "dynamic var" is pretty superficial

micha19:09:06

zones, on the other hand, are not redundant

darwin19:09:25

well, I would call them 鈥漽oned鈥 vars, it would be just an optional modifier, like :dynamic is

micha19:09:30

like the earmuffs warning

micha19:09:56

sort of an indication to me that something is amiss, if we warn about which characters we use to name a thing in lisp

darwin19:09:56

have you seen my proposal in the FAQ in the readme "Can this be ported to ClojureScript as part of standard binding macro in a backward compatible-way?"

darwin19:09:36

but I don鈥檛 want to push it, zones are perfectly usable as a library for me ATM

micha19:09:39

i don'treally see the need though

micha19:09:56

what is the advantage to having zoned names look like vars?

darwin19:09:05

we just need some benchmarks and maybe fine-tune the implementation

micha19:09:12

we already use earmuffs to make dynamic vars look different in a superficial way

micha19:09:22

your way is far better, imho

micha19:09:41

i think the complexity of making the compiler figure out zones would have little benefit for me

darwin19:09:47

one advantage could be that you can use one binding form and mix zoned/normal vars there, simply you don鈥檛 have to think if the 鈥渧ar鈥 you are working with was created in zone or not (assuming you don鈥檛 plan to do async calls inside your binding)

darwin19:09:44

imagine you are using a library, author decided to create a zoned var, you want to override it in binding in your app code, you don鈥檛 plan to do async stuff, so you should not be forced to investigate how the var was created

darwin19:09:59

but maybe this is not a good argument to hide the difference

micha19:09:36

yeah i don't see myself using it that way

micha19:09:04

i definitely do need the ability to save dynamic bindings for async calls though

micha19:09:19

but i always know which things are dynamic

darwin19:09:00

yep, in app code the situation is quite clear, you have full control, problems may arise when app and libraries have different assumptions, for example if library does not support zones, you cannot easily work around that, somehow 鈥渦pgrade鈥 library鈥檚 dynamic vars to 鈥渕ove" in a zone

micha19:09:56

that's ok 馃檪

micha19:09:01

good work man!

darwin19:09:15

thanks 馃檪

darwin19:09:53

you can use your solution to work with zones-unaware async libraries, the price would be just slightly slower code crossing bound-fn boundaries

darwin19:09:13

maybe that would be a good future addition to cljs-zones

darwin19:09:20

some tooling to do that

micha19:09:42

i'm slightly skeptical now of the value in overriding the variable lookup semantic for dynamic vars

micha19:09:33

having a clean separation of thread-local and global might have other benefits