quick question: how much enthusiasm is there for getting core.matrix support in the ClojureScript world? We have an issue with some discussion here: https://github.com/mikera/core.matrix/issues/81

@mikera: you’re likely to find it a lot easier to get contributions if you allow cljc and drop 1.6

Well - I'd certainly love to drop 1.6 but 1.7 is still pretty new and there are production deployments out there with core.matrix running on 1.6.

@mikera: requiring 1.7 in new versions doesn’t make old versions stop working

Yeah, but sometimes they do like bugfixes and performance enhancements

Not sure if it might be better to haver separate cljs and clj source anyway.

All the implementations will be very different, it's mostly the core API and protocols that can obviously be shared

question: I have a hand-crafted legacy JS app (a bunch of files), with dependencies on jquery, openlayers and a couple more libraries. instead of a rewrite, we chose adding a cljs/om app alongside and mounting it on the existing dom. the problem I have is: I’d like to package the whole js as a single file, containing both the legacy app with its dependencies and the cljs/om app. Is there a way to bundle a bunch of JS files and their dependencies in a specific order inside the cljs app and be able to compile with advanced optimizations?

the problem I have is that if I bundle just the dependencies (via cljsjs for example), they get name-mangled and the legacy JS code can’t see them. So I’d say I need to bundle everything together

anyone has had a similar experience and would know what would be a good way?

txus: what gets name mangled? the js files packaged via foreign-libs are not touched by the compiler

@martinklepsch: I’m suspecting that when I include the cljsjs libs, since my cljs code doesn’t ever refer to them (even though they get require’d), the compiler treats them as dead code

because it seems to work if I include cljsjs, compile without optimizations and just <script> the legacy JS app — it sees the deps then

@txus: you can always inspect the compiled file to see if the files are included. afaik the closure compiler does not know about the js files itself it only gets the externs bit

> compile without optimizations and just <script> the legacy JS app what other approach have you tried?

@txus: if you interface with any JS you will need to write externs for it

you could try packaging the legacy js app as a foreign lib and making it depend on jq/openlayers. then it should be inserted at the right spot. as long as you don’t call any legacy functions from cljs you won’t even need externs

it is easy enough to get it included into a build but the :advanced compiled cljs might get renamed alot without externs

I'd recommend two separate files, the legacy one and the cljs one

@martinklepsch: that is a good idea, I’ll try packaging it as a foreign lib. cleaner anyway

keep all the legacy out of cljs compilation, you are just asking for trouble 😛

@thheller: actually that would be fine by me. Then I guess I’d need a separate build system for the legacy JS app, right? could I use closure compiler anyway?

or is there anything the JS cool kids are usign these days?

you have something for the legacy stuff already?

not really. So I can choose whatever I’d like

it is really messy — just a bunch of JS files, no optimization lol

no idea what the JS world is doing

@txus: do you need to load the legacy code before cljs?

who is going to be the "driver" of the stuff? the legacy stuff or the cljs?

eg. who is getting called from html?

closure compiler with JS not written for it is no fun at all

you can use simple optimisations but that is just a basic minify, there are simpler tools for that

the legacy stuff, it’s all independent

@thheller: code passed in as foreign library is not processed by the compiler is it?

It’s just prepended as is similar to how preambles have been handled before just with dep-ordering etc.

@martinklepsch: no it is not, but just the step of creating the foreign lib seems like too much work

creating a foreign lib without externs is effectively no work.

and who knows what kind of issues it creates

yeah but you gain nothing by including it in the cljs build process

just making that more prone to errors

you save a build step

not really

you have one for the foreign lib

one for the cljs

the alternative is to just append it to the cljs-built js file after it’s done

I'd use 2 files, way easier to debug that way

Does anybody know is there an elvis operator in CLJS?

(aget o "firstChild" "nodeValue”)

Found it:

(some-> o .-firstChild .-nodeValue)

@thheller: I ended up using 2 files and it’s perfect!

thank you 😄

what did you end up using to build the "legacy" file?

@txus: any issues with the foreign-libs approach discovered or was it just faster/easier to do?

it was my first trial and it worked without much hassle so yeah, I just went with separate builds

I used bower to fetch dependencies and gulp to build / concatenate, uglify etc

got terribly confused with all the options, frameworks and build tools in the JS ecosystem

heh

hehe I know the feeling 😉

now it’ll be fun and clean surgically removing legacy code and rewriting it into cljs / om

Dumb question, but can someone remind me what the idiomatic way of getting a js object prop by string is? I know it’s not aget

goog.object/get

Thanks. Knew it was a closure thing

I just had fixed an error that only occurred in production and when compiling with :pseudo-names false (default)

when running locally it worked (even with :pseudo-names false + same optimization ofc.)

after setting :pseudo-names true everything worked fine

I’ve previously had strange problems that were fixed by setting :pseudo-names true — anyone else here?

:pseudo-names is a debugging feature, it’s not something that should be set otherwise

@dnolen: I’m well aware but my build breaks without it 😉

also a debugging feature isn’t particularly helpful if it magically corrects your build 😄

@martinklepsch: I’m pretty sure your issue is not related to :pseudo-names true

it’s very likely a symptom of a problem that exists in your build

@dnolen: I agree just confusing that it doesn’t occur in all contexts, preparing to debug more. this is gonna be fun 😄

my hunch, that you are not using a closure around your code

Closure is generating a name that clashes with some global thing

:pseudo-names true just prevents the clash

how would I wrap my cljs namespaces in closures? definitely sounds like a likely reason (name clash)

https://github.com/clojure/clojurescript/wiki/Compiler-Options#output-wrapper

@martinklepsch: ^

When sharing code as cljc, do you put it in a different namespace? for example, if I want part of the namespace foo.models.user (validators for example) in cljc, should I do something such as foo.common.models.user?

@dnolen: that was it!

@pupeno: you could put it in one namespace and just have bigger blocks for cljs/clj specific stuff at the end. That’s what I’ve seen a few times

Let me see how that looks.

@dnolen: thanks a ton for helping me figure this out. What’s the reason it’s false by default? At least for advanced it seems reasonable to set it to true maybe?

“If you’re enabling :pseudo-names to debug a problem and the problem disappears it’s potentially a name clash. Take a look at :output-wrapper” — @dnolen think that’s a good addition to the pseudo names docs?

soooo, I’m struggling to figure out how to set stubs for various things with Nashorn, per http://dev.clojure.org/jira/browse/CLJS-1076 I just don’t even know where to begin. Is this JavaScript code I have to write? Is it Java? CLJS? Where does it go, etc.? anyone have any pointers?

I’m having trouble getting cljs.test to work with a site using reagent. It throws an error when binding to elements. Does anyone have an example app that I could check out? I grabbed the polyfill from mozilla, but it doesn’t seem to be working correctly.

ha, andrewvida wrestling with something similar myself…will post an answer if I figure anything out

andrewvida: I do have to ask though, have you tried the style using a test runner as described here? https://nvbn.github.io/2015/06/08/cljs-test/

I’m struggling with doing this in a cider repl, but all my “Element not defined” and whatnot issues went away when I was able to load up my tests with an HTML stub

when running on the command line I mean

@ddellacosta yep, pretty much just like the post mentioned (minus figwheel)

gotcha, me too. Hmm okay then, sorry I can’t help much more, sounds like we’re in the same boat

I’d guess you could fill out that file more with some HTML fixtures, but not sure that fits into how you want to test

no problem.

@martinklepsch: if you control all the JS on the page (only Closure compat) then you don’t need it to be true

also implcations for async module loading etc. etc.

so not going to change it now

@dnolen, RE: http://dev.clojure.org/jira/browse/CLJS-1076 -- I’ve been able to do a super naive stub of setTimeout in my Nashorn-based REPL simply by doing (set! js/setTimeout my-dumb-timeout-stub)…what would the right way to do this be such that it could be included in CLJS or otherwise made available to users as part of their REPL by default? Sorry, I’m a bit clueless as to where to even begin with this.

@andrewvida: do you mind posting your test.js script and test.html? the test.js present in the blog post only evaluates the first argument, so the Function.prototype.bind polyfill should be included in the test.html

@ddellacosta: sorry I can’t offer any help on this right now

@ddellacosta: but look at the specific REPL sources (Rhino) in ClojureScript, they should how to stub out things

(Nashorn) etc.

@dnolen: understood, sure thing

actually that’s as much of a clue as I was hoping for, thanks very much

Hello guys, can you guys have a quick look at my issue here: https://github.com/cljsjs/packages/pull/256

I really don't know what is going on, it looks like cljsbuild is not prepending minified deps

and I need some hint on how to debug the issue

even just a switch to cljsbuild in order to see what it is importing and what it is not

I see here that I need to include my deps in the html

https://github.com/reagent-project/reagent-cookbook/tree/master/recipes/autocomplete#step-2-add-necessary-items-to-resourcespublicindexhtml

is it true? shouldn'it do it by itself, prepending them?

@richiardiandrea: I think that example doesn't make use of foreign libs support

Martin I opened an issue on cljsbuild and with mies (David's altirnative), it looks like it's working

@richiardiandrea: what did you change?

Just build with mies not with cljsbuild

The mies issue is probably superfluous

Can you put your test project online somewhere?

I mean, it works with mies

Yes of course, give me some time

And I think jqconsole package is good..it looks a building issue on cljsbuild (not sure, we'll see)

This is definitely strange and if mies works I'd assume that it's some kind of dependency issue

Yes I think so too

https://github.com/arichiardi/hello-world-cljsbuild-issue

the project with the issue

@richiardiandrea: what do you run in that project? lein cljsbuild?

@martinklepsch:

lein do clean, cljsbuild once min

script/release

cool. Will give it a spin. If you have a minute adding that info to the issue probably wouldn’t hurt

btw

lein do clean, cljsbuild once dev

thanks for being so persistent and getting it to work 👍

done

@martinklepsch: @maria found an issue in cljsbuild, just an update

@richiardiandrea: Sorry for not being clear enough, but it's actually not a lein-cljsbuild issue. In you case the example won't work if you use the :main option in combination with either :simple or :advanced optimization. So if you would add the :main option to your mies release script, you would get the same problem that jquery won't be included in the final build.