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 ?

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

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

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?

@anmonteiro Super, that’s exactly what I wanted, thanks 🙂

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

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

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

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!

this is the original dumb implementation: https://github.com/binaryage/chromex/blob/c8c326a62a5a4cad1816865a3d6a619246c0081e/src/lib/chromex/support.clj#L5-L27

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)

Are ClojureScript versions 1.9 to be used with Clojure 1.9?

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

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

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

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

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

https://github.com/clojure/clojurescript/blob/master/pom.template.xml#L28

probably that would be a better guide for CLJS users downstream

interesting, thanks. why the disparity?

AFAIK the bootstrap script is supposed to be for CLJS developers

David bumped Clojure to 1.9 for testing purposes

but releases still depend on 1.8

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

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

compatible with 1.8 and 1.9-alpha7

^^ feedback, comments welcome

@micha Interesting can you explain it a bit more?

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

so you can do like this

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

and it will print foo is: 100

awesome! i wasnt aware bound-fn wasn’t in cljs

is that used for lazy sequences? I’ve been bitten by that a few times

it's used for asynchronous callbacks

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

like for example

yeah, it makes sense

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

that will print foo is: 0

submitting it to the compiler?

it's EPL, and i signed the contributor agreement 🙂

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

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

@flyboarder yeah i'm putting together the release today

yay 🙂

bound-fn ticket is here http://dev.clojure.org/jira/browse/CLJS-1634

it is quite deep problem to solve in a performant way

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

@micha why does bound-fn accept multiple arguments?

my stab at it: https://github.com/binaryage/cljs-zones

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

@darwin interesting

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

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

i wonder if the javascript with form is useful

somehow

the problem of my implementation is that we have to wrap every access to “zoned” 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

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

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

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

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

@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

found this thread, which i haven't tried yet

http://stackoverflow.com/questions/23345663/call-a-clojurescript-function-by-string-name

you might get a clue here: https://github.com/binaryage/cljs-devtools/blob/06870cbc93a8ec0b29a02f64a736bde4f097334e/src/lib/devtools/formatters/markup.cljs#L437-L452

very cool, thanks!

@danvingo: also if you don’t 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

ah of course! yea it's just for dev

and you could maybe use this to demunge names back to their “original” versions: https://github.com/binaryage/cljs-devtools/blob/06870cbc93a8ec0b29a02f64a736bde4f097334e/src/lib/devtools/munging.cljs

thanks

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

we’ll need to port almost all of those parts

it won’t suffice to just re-implement aether in js or cljs

all of those parts as in just pomegranate and aether

Lenin uses java stuff as well as some aether classes

lein?

lein sorry

so does boot

okay

https://github.com/technomancy/leiningen/blob/master/leiningen-core/src/leiningen/core/classpath.clj

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

assuming nodejs?

yes

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

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

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

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

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

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

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

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

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

@darwin i actually like the zones/get part

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

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

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

zones, on the other hand, are not redundant

well, I would call them ”zoned” vars, it would be just an optional modifier, like :dynamic is

like the earmuffs warning

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

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

yes

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

i don'treally see the need though

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

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

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

your way is far better, imho

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

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

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’t plan to do async stuff, so you should not be forced to investigate how the var was created

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

yeah i don't see myself using it that way

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

but i always know which things are dynamic

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 “upgrade” library’s dynamic vars to “move" in a zone

that's ok 🙂

good work man!

thanks 🙂

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

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

some tooling to do that

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

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