Fork me on GitHub
#clojurescript
<
2017-06-27
>
miikka08:06:15

I just upgraded to 1.9.655 and I'm getting this error with advanced optimisations in a project that uses schema-tools. The property it points to is default:

kesäkuuta 27, 2017 11:09:15 AP. com.google.javascript.jscomp.LoggerErrorManager println                                                                 
WARNING: /Users/miikka/.boot/cache/tmp/Users/miikka/redacted/yzt/ko6id6/js/main.out/schema_tools/core/impl.js:222: WARNING - Keywords and reserved words are not allowed as unquoted property names in older versions of JavaScript. If you are targeting newer versions of JavaScript, set the appropriate language_in option.
return (!((other55787 == null))) && ((this55786__$1.constructor === other55787.constructor)) && (cljs.core._EQ_.cljs$core$IFn$_invoke$arity$2(this55786__$1.schema,other55787.schema)) && (cljs.core._EQ_.cljs$core$IFn$_invoke$arity$2(this55786__$1.default,other55787.default)) && (cljs.core._EQ_.cljs$core$IFn$_invoke$arity$2(this55786__$1.__extmap,other55787.__extmap));

miikka08:06:36

I thought it was safe to use JS reserved words as identifiers in ClojureScript. Is this a regression?

rauh08:06:42

@miikka That was discussed yesterday. There is a ticket on specter. Maybe schema-tools should also get a ticket

miikka08:06:10

@rauh Discussed where?

rauh08:06:25

Easiest fix is to up your :language-in in the compiler options

rauh08:06:37

On the cljs-dev channel.

miikka08:06:51

Ok, I'll take a look at the discussion

miikka08:06:38

Yeah, thanks

miikka08:06:14

Meh. default seems like a perfectly good field name to me but I guess it can't be fixed.

darwin11:06:02

@miikka I believe it could be fixed by generating js code which would access properties (fields) by string names, but that is quite some work which would need extensive testing and could introduce new problems.

pradyumna14:06:16

hi, is it possible to enable source map for source file references in stack trace in chrome console? It would be much easier to find source of exception.

dnolen14:06:11

@pradyumna if source maps are enabled that’s just how it works

pradyumna14:06:54

I have done that. And it shows so, when I use console.log

pradyumna14:06:33

But in stack traces it shows only link to js file

rauh14:06:55

@pradyumna How do you output the stacktraces to the console?

rauh14:06:15

B/c if you add other stuff, it'll link to the JS file.

pradyumna14:06:53

The exception is thrown by router.cljc and that shows the source mapped link to that file correctly

pradyumna14:06:41

When I expand the exception to see the stack trace then those are showing link to js file

pradyumna14:06:17

This is using re-frame

rauh14:06:41

I don't know what your code looks like, but if you dump them with (js/console.log "%s" ...) it won't work. You gotta use (js/console.log "%o" ...)

rauh14:06:04

So basically: If you stringify your error somehwere, you'll get links to the JS files

pradyumna14:06:38

Ok I'll try to look into re-frame how it is logging the exception

dealy15:06:55

I'm a bit confused about req vs req-un in spec. If I have the following in the same file spec fails: (s/def ::received-blob-count int?) (s/def ::cooked-blob-count int?) (s/def ::transformers (s/keys :req [::received-blob-count ::cooked-blob-count ::gg/gauge-vals])) gives this error msg: In: [:transformers] val: {:received-blob-count 0, :cooked-blob-count 0, :gauge-vals nil} fails spec: :etl-service.specs.app-db/transformers at: [:transformers] predicate: [(contains? % :etl-service.specs.app-db/received-blob-count) (contains? % :etl-service.specs.app-db/cooked-blob-count) (contains? % :etl-service.specs.gauge/gauge-vals)] when does it make sense to use req as opposed to req-un, I didn't think req-un would be necessary for things defined in the same namespace.

dealy15:06:48

@dnolen was that in response to my question? Upgrade to latest?

juhoteperi16:06:06

Reagent 0.7.0 released https://github.com/reagent-project/reagent/blob/master/CHANGELOG.md#070-2762017, it fixes a warning introduced in Cljs 1.9.660

udit17:06:30

@dealy req in a spec validates for namespaced keys as opposed to req-un which validates for keys with the same name. So when you try to validate the response map with spec containing req it fails as the keys are not namespaced

udit17:06:43

I typically use req-un in validating maps that I get as part of external request/response.

dealy17:06:06

yea, that's the way I have my code now, but some of the examples I saw had req with local unnamespaced keys. It is kinda confusing between the docs and some of the examples I was reading.

udit17:06:35

For data being passed around between namespaces of the same app req can be leveraged if you have multiple specs that are named same so that you can differentiate them by the namespaces.

udit17:06:19

@dealy maybe submit a pull request 🙂

chrisdavies19:06:20

Does anyone know how you'd do something like this es6: class Clock extends Component in ClojureScript?

wilkerlucio19:06:05

@dealy can you point the example you are mentioning? sounds like a bug in docs if that's the case

mobileink19:06:37

:require only works for goog and for js modules? is that accurate?

thheller19:06:54

@mobileink if you count CLJS as goog?

thheller19:06:43

sorry that was misleading, :require basically maps to goog.require

mobileink19:06:48

oops. add cljs namespaces. also clojure?

thheller19:06:56

so it works for everything that has a goog.provide (which CLJS generates)

thheller19:06:42

and js modules

mobileink19:06:47

or module.exports? (alpha)

thheller20:06:22

not sure what you mean by that but yes?

thheller20:06:03

ah yes, closure will rewrite files to have goog.provide and stuff

thheller20:06:05

I also have (:require ["react" :as react]) support in shadow-cljs but that isn’t “official” yet for CLJS

thheller20:06:50

but that is just syntax sugar for the manual thing

mobileink20:06:06

it's all about namespacing, yeah? goog.provide emulates namespaces, module.exports piggiebacks on that, and :require only understands namespaces? (fyi i'm working on docs.)

thheller20:06:25

yes, that sounds correct

thheller20:06:06

although not limited to module.exports

thheller20:06:28

the javascript module support just takes a file and scope all references in that file

mobileink20:06:29

more to the point: to use ordinary js lib foo, no :require needed?

thheller20:06:27

if you have a global js/foo than you don’t need a :require for it no

thheller20:06:45

but you also have to provide that foo manually

mobileink20:06:01

so, in contrast to clj, your pgm text can reference names that are not explicitly included (via :require or :import), so long as your html <script>s them in, so to speak?

thheller20:06:43

yes, you can always access globals via js interop

thheller20:06:28

clojure can as well with find-var and similar things

mobileink20:06:21

if i want to use a js lib that has e.g. foo.bar.baz, i always need to put it in the js namespace, i.e. js/foo.bar.baz?

mobileink20:06:37

iow, anything that is not modularized via goog.provide or module.exports must be qualified by js/?

thheller20:06:43

js is not technically a namespace but a special case for JS interop

mobileink20:06:15

thanks. cljs interop is a good bit more complicated than clj interop, i must say.

thheller20:06:01

yeah JS is a lot more dynamic than Java so you can do more things

mobileink20:06:48

shoot yourself in the foot in more creative ways? 😉

mobileink20:06:21

maybe #off-topic , but this strikes me as a (minor) flaw. in clj your program text cannot ref names unless you have explicitly authorized (via :require or :import). shouldn't cljs do the same?

mobileink20:06:20

iow js/foo should fail unless you have explicitly introduced foo somehow, in the pgm text rather than in an html file.

wilkerlucio20:06:37

@mobileink usually we wrap JS stuff, so you can have something like (def foo js/foo), then you can work on top of it

mobileink20:06:23

yeah, but imho that kinda breaks clj/cljs integration. no global ns in clj.

mobileink20:06:22

well, as mentioned, any name you want to ref in clj text must be explicitly introduced in the same text.

bronsa21:06:30

mobileink: this is not true

bronsa21:06:41

in clj you can refer to fully qualified java classes

bronsa21:06:01

without importing them

mobileink21:06:49

true! but not for clj code, only java (foreign) code, no? but alas js does not have such animals, and anyway my guess is that the majority of code uses :import.

bronsa21:06:46

js/ in cljs is interop

potetm00:06:31

@mobileink no that's not the case. In clj you can use the fully qualified name for any Java class anywhere in the program text and it will be resolved/loaded on the fly. It works just like Java code.

potetm00:06:44

And while perhaps most code uses :import, there exists a lot of code that doesn't. Especially for one-off invocations.

dnolen20:06:51

@mobileink it’s just not a good idea

dnolen20:06:05

JS is an embedded langauge, every environment has different ambient things

dnolen20:06:30

and there’s no way to guarantee anything at all

dnolen20:06:39

since JS has no native import facilities

dnolen20:06:51

none of this is true for Java

dnolen20:06:33

when you start thinking about higher level stuff, like polyfills what you’re suggesting could only lead to more not less problems

mobileink20:06:46

understood. but that's changing, no? since i'm about to go off on tangents i'm switching to #off-topic simple_smile

dnolen20:06:24

if by changing - you mean this was changed by the BDFL Rich Hickey and he probably thought about it at length

dnolen20:06:58

there are really very few choices in ClojureScript that weren’t put in place 6 years ago

mobileink20:06:27

thinking more about how js changes every few years. 😉

dnolen20:06:59

but it hasn’t actually changed that much

dnolen20:06:12

most people are transpiling still because it’s not safe to depend on anything

mobileink20:06:53

i have lots of qs but they're all dumb so off-topic. heh.

dnolen20:06:28

if it’s about ClojureScript rationale it’s not off topic really

mobileink21:06:52

you asked for it!

mobileink21:06:00

here' a little motivation. i rilly do not like mixed language pgmming. i don't want to do even a little bit of html. that's just me, i get it. (see miraj). in cljs, to use js libs, i have to muck with html. i know, trivial, but still, it ruins the aesthetics. in clojure, i never have to do this. to make a seamless dev experience, cljs should (in nutty principle) act just like clj. you wanna use sth, then :require or :import it. i do sth like this in miraj, but have no idea if it would work generally.

dnolen21:06:51

not caring about HTML is just a non-goal

dnolen21:06:01

some people use Clojure for Swing or Vaadin

dnolen21:06:13

same applies to ClojureScript - outside concerns

dnolen21:06:23

ClojureScript is just about running where JavaScript runs - sorting out all the other stuff is for the community and they’re doing an amazing job at it

dnolen21:06:42

the other thing is there are some old decisions and it’s important to understand they just aren’t going to change

dnolen21:06:03

personal aesthetics will always be trumped by 6 years of existing code

mobileink21:06:06

dnolen: running code always wins. how depressing for those of us with great theories.

dnolen21:06:23

lots of people in the community have already invested time / money / trust - ClojureScript just isn’t a new project that barely works anymore 🙂

mobileink21:06:34

dnolen: sure, it works great in practice - but how does it work in theory? (old uchicago joke, hahaha)

tjtolton23:06:26

^im gonna steal that joke

mobileink21:06:17

i am an admitted unreasonble outlier - all progress depends on me! haha that was a joke, really. seriously i am not asking for cljs to change, i am perfectly happy with it. but inho it's useful to think crazy once in a while.

dnolen21:06:28

there’s plenty of crazy things to think about still

dnolen21:06:34

just nothing to do with HTML 😉

mobileink21:06:36

more specifically, i'm thinking about how to doc cljs, contrast it with clj, etc. in a comprehensive way.

dnolen21:06:25

philosophical stuff is best left for books - official site doc’ing is just about documenting differences or things that will trip up users just starting out - we should stay focused on that

mobileink21:06:18

dnolen: completely agee, but speaking of which, the doc pr i subbed today - i don't know what the protocol is but i'd like to just invite everybody to pitch in. ok? i understand that my idea of good docs may or may not match that of you and your colleagues, np.

dnolen21:06:47

PR looked fine from a high level - can’t give feedback today but I definitely will this week - good rule of thumb is to follow Clojure style & tone for reference stuff - Guides are more flexbile - clojure.spec is a good example

mobileink21:06:06

dnolen: running code always wins. how depressing for those of us with great theories.

dnolen21:06:17

there’s plenty of interesting stuff to do that doesn’t require changing old decisions

dnolen21:06:01

I see 200+ open issues right now, many of them with massive impact

dnolen21:06:57

if you want to help out jump in #cljs-dev and listen and take something

mobileink21:06:29

personally i think doco is #1.

dnolen21:06:16

yes documentation is important and we need plenty of help there

mobileink21:06:41

i'll do my best, time permitting.

bbloom22:06:34

just catching up w/ compiler perf fixes - very nice work everyone 🙂