This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (16)
- # bangalore-clj (4)
- # beginners (19)
- # boot (27)
- # cider (82)
- # clara (2)
- # cljs-dev (343)
- # cljsrn (97)
- # clojure (222)
- # clojure-hk (1)
- # clojure-italy (25)
- # clojure-russia (5)
- # clojure-serbia (2)
- # clojure-spec (7)
- # clojure-uk (28)
- # clojurescript (97)
- # cursive (8)
- # datomic (52)
- # docker (1)
- # emacs (15)
- # hoplon (39)
- # jobs (4)
- # lumo (21)
- # off-topic (3)
- # om (66)
- # onyx (7)
- # parinfer (5)
- # pedestal (2)
- # play-clj (10)
- # portkey (2)
- # protorepl (2)
- # quil (1)
- # re-frame (36)
- # reagent (33)
- # spacemacs (3)
- # specter (4)
- # sql (19)
- # test-check (31)
- # unrepl (4)
- # untangled (3)
ah we do have a little bit more work to do wrt. all this modules I think - REPL support
IMO there may be good reasons to use
js* for people who know what they are doing :slightly_smiling_face:
btw. canary just generated first downloadable jar release: https://github.com/cljs-oss/canary/releases/tag/r1.9.769-33e8067
@anmonteiro updated - sadly I didn’t record my thoughts when I opened it and it’s pretty old
@mfikes https://dev.clojure.org/jira/browse/CLJS-2231 I don’t think this is a problem in master, we check to see if the fn is set
Testing this patch out, which may meet the need: https://github.com/mfikes/clojurescript/commit/c163bd72e3566640c9a2be59b9e8853b78240020
@mfikes I think we should stop setting them to fns that throw and push that logic one level up
I thought quickly about TypeScript, but I think that needs proper compilation instead of per file preprocessing.
:commonjs/`:amd` processing uses compiler options
:language-in to process the sources,
:es6 processing uses always
Perhaps js-modules should allow setting
:language-in per module-type, or directory
Hmh, or at least Closure supports "TypeScript-style type annotations: > Initial work on supporting TypeScript-style type annotations, with the --language_in=ES6_TYPED flag.
That note from 2015 is only thing in Closure changelog about TS, so I'm not sure how good the support is
I updated the preprocess post with a bit more content: https://github.com/clojure/clojurescript-site/pull/112
The headers can be probably improved, but I think the order of content should be okay
@juhoteperi funny enough I was thinking about that exact case yesterday - I think we should hold off on how we will bulk preprocess - I don’t really think anything we’ve decided closes any interesting doors
Yeah, if we need to later change how preprocessing works, we can for example group-by the sources similar to module processing. And this doesn't break the
@juhoteperi yeah also there’s a lot of new stuff here and I think further changes should probably be guided by usage feedback
I’m working through an issue where it appears a warn is printed for a bad
aset and this is potentially in the communication infrastructure between Figwheel and the app, and the warn itself seems to cause yet another, and it cascades. I end up seeing this in the Figwheel console, but no warnings there
Figwheel: message from client couldn't be read! Figwheel: message from client couldn't be read! Figwheel: message from client couldn't be read! ...
^ Sorted the above. Will send a PR to Figwheel. Also, less critical but cool: The new feature is pointing out invalid uses of
aget at runtime in
core.async. A simple example is here where
aget is called, and then the result is checked for
nil rather than also first checking to see if the array is non-empty: https://github.com/clojure/core.async/blob/master/src/main/clojure/cljs/core/async/impl/timers.cljs#L84
testing things at the REPL is good thing to focus on. Going to start digging into requiring all the different supported module types at the REPL myself.
watching all these single function lodash modules get copied over during testing :unamused:
resolve-var to clean up the module stuff like I preferred https://github.com/clojure/clojurescript/commit/4e85b044902b5a32a0dcc6e1e5f4ff22bbaf0505
lein test and
script/test passing but could definitely use more testing - and if anything fails - more test cases
further cleanup is possible if we unify JS module indexing instead of doing it separately as we are now
There might be a useful change to consider for the
aget runtime logging. I think we are only getting the message and not the stack. I suspect this is due to
str being applied to the exception.
I’ll try such a change locally and see what I get. I have bad
aget somewhere occuring at runtime, but all I’m seeing is the
"Error: Assert failed: (or (array? array) (js/goog.isArrayLike array))" portion, making it hard to track down.
@mfikes maybe unrelated, but in cljs-oops in dev-mode, I did extra work to make sure that assertions are properly reported pointing to user code at call site location - not somewhere into my library code
Yes. In our case, I think we may have the call to
checked-aget at the top of the stack, and the rest of the stack being user code. (It is really just using
for example in devtools console user will see link to your checked-aget, which is not that useful
Ahh, right. A challenge too is this is all after macroexpansion. The line number appear to point back to the macro call site.
cljs-oops is also just a macro expansion, the trick is to generate js/Error. object at the call site and then throw it from within you lib code
but this might not be appropriate for cljs.core, just wanted to mention this technique
@mfikes where is that happening? re
str on checked array error, I thought we call
yeah I’m pretty sure what’s being done is entirely reasonable for both Node.js & Browser
That makes sense. I’m digging into Figwheel code and I see stuff that explains it I believe. Not a compiler problem. It seems to let the console log it, which would be RN, and then it attempts to serialize the exception back, which leads to issues:
You are right, you could spend all day figuring out non-compiler stuff.
ios:cljs.user=> (*print-err-fn* *e) Figwheel: message from client couldn't be read!
I did one more careful read of the “Checked Array Access” sneak preview post and found one small error (it referred to
unsafe-get instead of
unchecked-get). Pushed a fix for that. Otherwise it LGTM.
Ahh, I see there are a couple of further changes I missed right near the end. What was the commit nit?
I suppose with the removal of the change to
js* to support parameters, “Again, the theme of successive refinement.” odd (the “again” part.)
@mfikes agreed I would drop, I think the theme of refinement is clear just in the flow of the prose
Cool. I slipped it in with one word: “As time moved on, our friend aget (as well as aset) was refined to”
Not sure if that will actually work (first time trying to post a picture in a thread), but it's the only thing in the post that seemed like an issue to me - I suspect it can be fixed by just removing the extra
aget after the snippet.
Thanks. There is already a PR https://github.com/clojure/clojurescript-site/pull/117
Great post though, hopefully it will help reduce the questions. It does make me wonder how many people will ask for
oset sugar to wrap the
Something recently put on master is causing something downstream in my RN project to complain about
module-deps. Will bisect. It is not causing any behavior to break AFAICT. https://gist.github.com/mfikes/be782a414965cb3d2b2637c1ed29d54a
Another aside: Figwheel hot-load updates after changing files used to take 2 seconds for me with the 1.9.671 release but now take about 12 seconds with master (with
:checked-arrays off). Sorry for sharing without a minimal repro.
module-deps observation above is with the very last commit on master ((https://github.com/clojure/clojurescript/commit/2ba8ec76ec3977143afc5137e22c47838ac9d5a7) but not the prior.
@mfikes we do index the top level of
node_modules though that would surprise me if that was a problem
Yeah, I again apologize for no minimal repro. Willing to try ideas locally if any are had.
@mfikes do you have
:verbose on? if so you’d see if base node deps are getting installed in the case of your gist
if you do then somehow Figwheel is skipping that step, and your error would make sense
@mfikes the 2->12 problem might be related to us reindexing the node_modules directory on every file save?
@anmonteiro I suspect you are correct. The 2->12 problem: https://dev.clojure.org/jira/browse/CLJS-2238
@dnolen Negative result on
:verbose shedding any light. It doesn’t appear to log anything relevant: https://gist.github.com/mfikes/8a4d210657fc8baa3064c869d5646520
One thing I’m wondering: Just because I have a
package.json file sitting in my current directory, does that mean that ClojureScript should assume I’m using it? (I suspect it is just there for the React Native packager to have fun with.)
I think probably (node_modules) but should probably only index once, memoized like classpath libs.
It’s probably OK. I added some
util/debug-prns to look at the sets involved in
requires set is stuff I recognize, like ClojureScript and some
goog namespaces, taking maybe 2 inches to print in my console. The
top-level set takes approximately 1/3 of a mile of console to print, and their intersection (the important bit,
node-required), is emtpy. So it doesn’t seem to functionally hurt, and the perf would be fixed with good memoization.
In terms of counts:
requires 77 top-level 14748 node-required 0
top-levelnumber prints about 12 seconds after the first.
hrm so should I put something together for you to look at or don’t you see any value?
if we find it still has a significant perf cost we can simplify it to your approach
As an aside, I’m now pretty sure the
module-deps stuff that gets logged (https://gist.github.com/mfikes/be782a414965cb3d2b2637c1ed29d54a) is somehow related, as it does 3 of them, each 12 seconds apart from each other
I was seeing this problem while developing Lumo too and this fix + CLJS-2240 solves it
@dnolen CI has also been green which is reassuring https://github.com/mfikes/clojurescript/commits/master
great. I’m glad you brought it up, I had noticed it yesterday but failed to open a ticket
(require '["lodash/array" :as lodash-array]) working in the standard Node.js REPL
@anmonteiro hrm, looks like there might be something wrong with
@anmonteiro do you see a problem with just creating it temporarily if it doesn’t exist?
@anmonteiro hrm I don’t really under what your
gen-user-ns stuff does when it’s handed a form
@dnolen there’s certainly a comment here https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L3756-L3758
in order to handle modules correctly we need to convert
ijs by calling
parse-ns on result
where you shouldn’t be able to require something with an alias that is already aliasing another namespace
ClojureScript Node.js REPL server listening on 50913 To quit, type: :cljs/quit cljs.user=> (require '[clojure.string :as s]) nil cljs.user=> (require '[clojure.string :as s]) nil cljs.user=>
@anmonteiro here’s the problem, I’m thinking about disabling that thing and if you want to figure out a way to bring it back you can
in order to even know that somebody wants to loads a module you must process the AST at least twice
@dnolen so you’re saying that we may have 2 requires (2 passes, really) that are really trying to load the same namespace but it gets different names?
@anmonteiro it gets different names because don’t know what name Google Closure is going to invent during
this is already true in build compiles - but it’s less of deal there because
process-js-modules happens before you compile anything else
^ @dnolen this looks like you’re processing a file through Closure under Node.js ?
when really if you have
:target :nodejs it should just emit a
without any investigation I would say that somewhere we’re not binding
:target :nodejs :slightly_smiling_face:
Pretty sure it's been said before, but you are all killing it lately - amazingly inspiring to see this much work and love go into ClojureScript!
Did anyone else get any emails from Kyle Pennell at Stackshare about the CircleCI article? I got an automated one from having contributed to CLJS
it is pretty clever, to scrape repo contributors and then get their emails from github web or git commits
@anmonteiro it’s was trying to analyze the transformed module (which isn’t possible currently)