This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-28
Channels
- # aws (7)
- # beginners (69)
- # boot (67)
- # cider (9)
- # cljs-dev (159)
- # cljsrn (2)
- # clojars (25)
- # clojure (345)
- # clojure-austin (9)
- # clojure-berlin (1)
- # clojure-dusseldorf (10)
- # clojure-italy (3)
- # clojure-nl (1)
- # clojure-portugal (1)
- # clojure-spec (73)
- # clojure-uk (59)
- # clojurescript (163)
- # clojurewerkz (1)
- # component (26)
- # core-matrix (2)
- # cursive (20)
- # datascript (32)
- # datomic (15)
- # dirac (16)
- # emacs (3)
- # hoplon (35)
- # jobs-discuss (87)
- # jobs-rus (95)
- # luminus (15)
- # om (135)
- # om-next (3)
- # onyx (47)
- # pedestal (67)
- # perun (74)
- # play-clj (4)
- # portland-or (1)
- # proton (4)
- # re-frame (13)
- # reagent (18)
- # remote-jobs (17)
- # rum (20)
- # specter (11)
- # untangled (101)
- # yada (18)
Jira etiquette/testing question - I've tested CLJS-1868 compilation on both Windows and Mac, for both :none
and :advanced
, and I've confirmed that it compiles and the new paths look good. The closure libraries are included and under :none
they show up in the out
folder as expected, but I haven't actually programmed anything that uses them, only tweaked the quick start files. Is this enough to say that it works for me on Jira, or should I try writing some code that actually uses the included cloure libs first?
so I just tried upgrading my work project to latest CLJS 494 and it didn't work, then tried 473 and 456 also no luck.
the last time I had an issue like this was about with protocol detection, but we fixed that
@thheller did you upgrade from 1.9.229?
it’s a big bump from 293 to 456, you think you can bisect?
by big bump I mean there were a lot of commits
its too late for me to dig into this now, will try some stuff tomorrow .. just completely surprised the usual :pseudo-names
debug option doesn't work as it disappears
sounds good, keep me posted
it looks like something was optimized away, but there should be more people reporting this if that were the case
the check that failed is {:pre [(ifn? x)]}
... removed that :pre
and just test (when-not (ifn? x) (js/console.log "x is not ifn" x))
the console message display the object as x is not ifn function (a) {
... with the full code of the function
so (goog/isFunction x)
returns false ... I have no idea what is going on. going to sleep.
Just created and attached a patch to http://dev.clojure.org/jira/browse/CLJS-1960
It addresses the first part of the solution proposed in this design doc: https://github.com/clojure/clojurescript/wiki/Enhanced-Node.js-Modules-Support
the patch makes is possible to supply a :npm-deps
entry in the compiler options, such as:
{:npm-deps {:react "15.4.2"}}
and then require react
directly from a CLJS namespace. e.g.:
(ns foo.core
(:require [react :as React]))
(def foo (React/createElement "div" nil "Hello, World!"))
the compiler will install the supplied node modules automatically
Awesome great
I appreciate people trying out the patch and reporting back!
Will do
This plus boot-pack-source
solves my packaging requirements thanks 😀
There might be one hiccup along the way with some modules: you might encounter this Google Closure Compiler issue: https://github.com/google/closure-compiler/issues/2308
^ the fix for that hasn't been included in the February release and some modules may crash the compiler
if you know how to build the Closure Compiler, use a master checkout
@anmonteiro did a git bisect to find the bad commit
git bisect bad
de05b15568c848a1d4f80a44bdffd486abd05150 is the first bad commit
commit de05b15568c848a1d4f80a44bdffd486abd05150
Author: António Nuno Monteiro <[email protected]>
Date: Mon Nov 7 12:07:32 2016 +0100
CLJS-1768: cljs.spec perf tweaks
This patch implements the changes in the following commits:
:040000 040000 f8eee4c6e8289c5ec539c478e67c48d0de485f84 f261f856c8492bd4880be536186ccc8ad3fe3557 M src
no idea why that would cause my app to fail as it fails at a point where spec isn't involved at all
verified just for sanity git reset --hard de05b15568c848a1d4f80a44bdffd486abd05150
breaks while git reset --hard de05b15568c848a1d4f80a44bdffd486abd05150~1
works
opened http://dev.clojure.org/jira/browse/CLJS-1961 will post my progress there
@anmonteiro sorry for wasting your time, your commit wasn't causing this at all. I messed up my externs and somehow that made it look like that commit was causing it.
Had some Google Analytics externs that went missing, somehow the ga
variable must not have been touched before that commit
should have been my first clue to look for externs when :pseudo-names
worked, guess I shouldn't try to debug those things at 2am
for giggles the the function that was replaced by ga
was goog.isFunction
which caused by {:pre [(ifn? x)]}
to fail 😛
That’s probably not related directly to ClojureScript, but is there a way to make JS stack traces show source mapped ClojureScript code in stack frames?
I thought browsers can do it already. But if not, this probably could be achieved via stacks rewriting, the way it’s done in React.
@roman01la I believe DevTools developers try to do their best to do this whenever possible
obviously, if you handle error objects yourself and printing them somehow directly this transformation is not present
@darwin Yes, but I’m interested if there any evidence that source mapped stack frames are supported or not.
AFAIK it is definitely NOT supported from the ECMAScript, so DevTools tries to be smart and transform presentation if they detect you happen to be printing a stack-trace
if you interact with js/Error
object in your code for example and processing .-stack
by hand it won’t be source mapped, but if you console.log it, DevTools will detect it is a strack trace and try to present it source-mapped
not sure about this particular case, but it definitely works when logging js/Error
or exceptions for example
another place is when DevTools present some error or exception on their own (without you explicitly logging it), similar heuristics apply
@roman01la source mapping is exclusively coming from the devtools, the runtime itself doesn't do any mapping at all
@thheller I believe it’s possible to change function names in stack frames via fn.displayName
prop
that’s how it is done in React I guess
@thheller yeah, exactly, instead of this clojure$string$includes_QMARK_
it would be nice to see this clojure.string/includes?
looks like displayName
is the way to go
I know this is kind of unnecessary when you used to read stack traces, but would be a nice to have for novice devs
@darwin what about cljs-devtools?
well, cljs devtools tries to present user-friendly names when formatting, if I remember correctly
since there were a bunch more names it hard to process but I really don't remember the details
btw. reverting munged names is a non-trivial task: https://github.com/binaryage/cljs-devtools/blob/3e6b8d65cd540ad82d7dfa1330b557752c4023a8/src/lib/devtools/munging.cljs#L480
@roman01la there is some work done to manually re-map stacktraces here https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/stacktrace.cljc
@anmonteiro whoa nice!
@thheller no problem, glad you figured it out. Kinda interesting how goog/isFunction
ended up being replaced by ga too 🙃
the fact that everything worked with 1.9.293 is so strange, the externs where missing there as well. guess it replaced a function I didn't reach but then at some point that was shifted.
(ns foo
(:reqire [my-project.domain.specs :as specs]
[cljs.spec :as s]))
;; for reference: the predicate on :specs/thing is just `string?`
(js/console.info "Incorrectly used other-ns-spec evaulates to:" :specs/thing) // => :specs/thing
;; ^ it correctly fails to identify that as the `thing` spec from the `specs` namespace and assumes the literal keyword ":specs/thing"
;; but..
(s/valid? :specs/thing "") // => true
(s/valid? :specs/thing {}) // => false
;; ^ it correctly identifies & validates when doing an s/valid
is there some magic going on under the hood to correct that mistake when doing validations?
this isnt causing any problems, its just a common mistake my team members themselves making when still learning ::
vs :
that im curious to know if is working as intended
@samueldev you should be using ::specs/thing
for the keyword to be expanded as :my-project.domain.specs/thing
@anmonteiro yup I understand that now - but am curious as to why the validation passes (it seems to correct the mistake for you, and understand what you were trying)
@samueldev Are you sure that s/def is ::thing and not :spec/thing?
ok @favila @anmonteiro i dont think im crazy
(s/def ::this-is-a-test-map-spec
(s/keys :req-un [:blah/asdf :blah/fdsa]
:opt-un []))
(js/console.log "1:::::::")
(def val1 "")
(js/console.info (if (s/valid? ::this-is-a-test-map-spec val1)
true
(s/explain-data ::this-is-a-test-map-spec val1)))
(js/console.log "2:::::::")
(def val2 {:asdf "" :fdsa {}})
(js/console.info (if (s/valid? ::this-is-a-test-map-spec val2)
true
(s/explain-data ::this-is-a-test-map-spec val2)))
(js/console.log "3:::::::")
(def val3 {})
(js/console.info (if (s/valid? ::this-is-a-test-map-spec val3)
true
(s/explain-data ::this-is-a-test-map-spec val3)))
what about it?
in ^ that example code, the output is thus: https://puu.sh/uo7l0/a231485d14.png
@samueldev uh…`:req-un [:blah/asdf :blah/fdsa]` this doesn’t make sense to me
you’re saying “these unnamespaced keywords are required”, but you’re passing namespaced keywords
the namespaced keyword is the name of the spec
just the name part is used to match the key
OK I’m probably not the best person to be answering spec questions 🙂
Is there a spec for :blah/asdf ?
it has :asdf
and :fdsa
which are required
then as @anmonteiro said, it’s meeting the spec
the spec requires those (unqualified) keys to exist, and they do
is :blah/asdf
going to make it look for the key :asdf
? i guess im just misunderstanding
in 1, yes
that’s what the “-un” part means
(s/keys :req [:blah/asdf :blah/fdsa])
will look for a map with keys :blah/asdf
and :blah/fdsa
(s/keys :req-un [:blah/asdf :blah/fdsa])
will look for a map with keys :asdf
and :fdsa
okay. so basically i can effectively think of the -un
as trimming anything but the last part of the keyword (anything after a /
) ?
in both cases, keys
will try to validate the value for those entries with the specs for :blah/asdf
and :blah/fdsa
the / is the divider between the qualifier and the name of the keyword
okay. that was my confusion then. i assumed that :blah/asdf
would not do any "trimming" and would look for explicit :blah/asdf
- i understood it was only parsing qualifiers VS keywords when using :req
also in the above examples i perhaps wasnt clear: :blah/asdf
and :blah/fdsa
are not defined anywhere
if you have two :req-un specs that share the same name, the result is undefined (so don’t do that)
so
(s/def ::this-is-a-test-map-spec
(s/keys :req-un [:blah/fdsa]
:opt-un []))
Does not throw an assertion error, but
(s/def ::this-is-a-test-map-spec
(s/keys :req-un [:fdsa]
:opt-un []))
doesin both cases, you are expected to provide a fully-qualified keyword that refers to a spec
keys
does two things: 1) checks that required keys exist (fully-qualified for req, unqualified for req-un) and 2) checks that the value for every key is valid according to the spec
@samueldev Said differently, :req-un and :opt-un are the only exception to the spec rule that "Map specs should be of keysets only" https://clojure.org/about/spec#_map_specs_should_be_of_keysets_only
It only allows one kind of aliasing: an un-namespaced key to a spec with a matching name part.
I don’t see how that’s an exception
it’s still a map defined by its key specs
every map spec still defines only one spec for that key though
yes but {:foo "x"} could be e.g. :bar/foo or :baz/foo spec depending on what spec you choose to conform the map to
yes, but you must choose. whichever you choose, the map spec specifies the key spec
but that doesn’t violate the point being made in that section
which is that a map spec is built up of key specs
and the specs used for values in the map are not specified by the map spec but by the spec identified (whether exact or partial match) by the key
I’m disagreeing with "the only exception to the spec rule"