This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-14
Channels
- # admin-announcements (3)
- # alda (1)
- # beginners (12)
- # braveandtrue (4)
- # cider (9)
- # cljs-dev (109)
- # cljsrn (6)
- # clojars (4)
- # clojure (40)
- # clojure-japan (5)
- # clojure-russia (10)
- # clojurescript (42)
- # cursive (2)
- # datomic (6)
- # hoplon (3)
- # luminus (3)
- # melbourne (1)
- # om (4)
- # om-next (1)
- # onyx (41)
- # proton (2)
- # protorepl (1)
- # quil (1)
- # re-frame (6)
- # respo (1)
- # testing (1)
@dnolen you skipped over issue B+C on http://dev.clojure.org/jira/browse/CLJS-1733, should I report the as new issues or do you not agree that they should at least warn?
The only thing I can add to the odd KeySeq
issue above is that I also saw the underlying mseq
containing nil
values in addition to map entry pairs. I can only reproduce this downstream so I don't want to add further noise here (it could just be a downstream-specific issue).
@mfikes CLJS-1744 is same as the previous one but for create-array-node-seq
, I moved the rest logic where it belongs and left the ctor fns alone
@dnolen: I wonder if this has landed with recent enhancements, or if I’m not understanding what the issue is http://dev.clojure.org/jira/browse/CLJS-1029
@anmonteiro: not addressed by the recent enhancements - but also probably not a good idea either. Will close 🙂
@mfikes: just attached a patch to http://dev.clojure.org/jira/browse/CLJS-1274 I don’t foresee any self-host problems, and both self-host and self-parity tests are passing, could you confirm when you got some time?
@anmonteiro: Do you know precisely the shape of the macro that this is intended to support? This is perhaps close but not really what the ticket is about:
(defmacro defvar [name value]
`(def ~name ~value))
@mfikes: I think it’s meant to support things like this:
(defmacro deffoo [val]
`(def foo ~val))
where previously you had to do:
(defmacro deffoo [val]
`(def ~'foo ~val))
@anmonteiro: Ahh. OK. That fundamentally won’t work as is in bootstrap because (deffoo 12)
expands to (def foo.core$macros/foo 12)
@mfikes: right but then it should probably throw with my patch?
because foo.core$macros
wouldn’t be equal to foo.core
so it wouldn’t allow to define that ns-qualified sym
which is the old behavior
@mfikes: (def cljs.user/foo 42)
should however work in bootstrap
if you’re in the cljs-user
NS
but that’s just not useful for anything at all
One minor side comment on your patch is that the analysis error could perhaps be relaxed. Right now it sounds unconditional: Can't def ns-qualified name at line 1
Yep… just trying to do the due diligence to see if the patch meets the goals of the ticket, even under bootstrap. (I suppose it can’t.)
@mfikes: hrm, yeah, perhaps the error message should be changed
Clojure’s is not really helpful for this situation:
Can't refer to qualified var that doesn't exist
maybe Can’t def ns-qualified name in other namespace
(Not a serious thought, but knowing we have a separate macros namespace, it it an interesting idea if there were variations on syntax quote to control whether things expanded to the macro or runtime namespace.)
we do have the other ns param
probably worth putting that into the error message too
I’ll amend the patch to include that
cljs.user=> (def foo.core/foo 43)
Can't def ns-qualified name in namespace foo.core
That will help if someone bumps into this in bootstrap, as it would effectively end up emitting a diagnostic that reads Can't def ns-qualified name in namespace foo.core$macros
Attaching the amended patch just now
Thanks for the feedback, as usual!
@anmonteiro: Your second patch is identical to the first.
@mfikes: ooops, I forgot to commit
@dnolen: added a comment to this one on why it should probably be closed: http://dev.clojure.org/jira/browse/CLJS-1242
regexp?
already exists and serves the same purpose, I think
@dnolen: I wonder if this one is in fact a bug or not. http://dev.clojure.org/jira/browse/CLJS-1623
It would seem to me that using with-redefs
under :static-fns
is a no go
so the error is kind of expected
I think vars marked dynamic don’t get optimized right? that’s probably the only thing I’m interested in - a way to work around it
hrm let me check that
I understand it’s not a priority, just doing some basic screening and questioning myself when something obvious jumps to sight
@dnolen: right, :dynamic
vars won’t get optimized, so with-redefs
works under :static-fns true
Added a comment to the issue that demonstrates this:
http://dev.clojure.org/jira/browse/CLJS-1623?focusedCommentId=43541#comment-43541
so I think the problem with replumb is that before we had the file js/compiled/out/cljs/string.cljs
that now is not generated anymore from what I see...we have js/compiled/out/clojure/string.cljs
instead
@mfikes: can’t repro this one http://dev.clojure.org/jira/browse/CLJS-1657
self-host passes with current master and your test suggestion
@anmonteiro: The setup down in script/test-self-parity
employs the 3rd strategy in my comment in that ticket to make things work for certain namespaces. The fundamental problem is that self host can’t directly read from the filesystem in order to learn if implicit macro loading should be in effect. (But it is possible that some subtle things have changed since that ticket was authored.)
Has this already been fixed in master? WARNING: Wrong number of args (5) passed to cljs.analyzer/check-use-macros-inferring-missing at line 479 dev-resources/private/node/js/compiled/out/cljs/js.cljs
I am always late with my notifications 😄
@richiardiandrea: cljs.string
isn’t and never was a thing
yes sorry about that, I think I misinterpreted some error here, it looks the problem is elsewhere
@anmonteiro: closed the with-redefs
ticket
@anmonteiro: I’ve confirmed your observation with respect to http://dev.clojure.org/jira/browse/CLJS-1657 and added a recommendation to the ticket.
happy to get some feedback on the docstring of the refer-clojure
REPL special:
http://dev.clojure.org/jira/browse/CLJS-1742
Used most of the wording in the doc for clojure.core/refer
, adapted to the ClojureScript use case
@anmonteiro: I wonder if the “via inclusion” language is related to :only
. (Just a guess… hmm…)
Ah right, I missed that one
@mfikes: does this sound good?
Filters can be used to select a subset, via exclusion, or to provide a mapping
to a symbol different from the var's name, in order to prevent clashes.
or should I just eliminate the subset
part altogether
I think, so. I’m still trying to understand what, for example, (refer-clojure :exclude [juxt])
really does…
theoretically, it unmaps cljs.core/juxt
from the current NS, right?
not sure how it would do that in CLJS though
or how it really works
We are used to :refer-clojure :exclude
in ns
forms to effectively suppress warnings when you redefine core fns. But, right… at the REPL, it is not clear to me what this even means in Clojure.
It doesn’t unmap, no, I’ve tried that before
When I wrote that JIRA I avoided writing the docstring myself because of this lack of understanding 🙂
also why I requested feedback on my patch
so I understood the problem, it seems that now every time cljs resolves a clojure.string
deps and tries to load it, the *load-fn*
is called with cljs.string
instead
this happens for transitive js
deps, for instance of goog/string/stringbuffer
so before I was receiving clojure.string
, now I receive cljs.string
, which does not exists
@richiardiandrea: it tries clojure.string
first
or it should, so that’s what you should be looking for if you’re trying to suss out a bug
@dnolen: thanks for the confirm. if you say that, maybe there is something there, I will check the cljs source
@anmonteiro: @mfikes: :exclude
just removes that name from being checked for existence in core
I found that Clojure’s refer-clojure
actually does something close to its name, and wrote a ticket for ClojureScript: http://dev.clojure.org/jira/browse/CLJS-1745
Knocked it down to minor. In truth that’s the kind of ticket that could sit there a long time as noise 😞
Sorry for bothering again on this, just a confirm, do i understand right in saying: first, clojure.string
is sent to load-fn but then whatever the result of it (load or fail), cljs.string
is tried. So before load-fn was receiving one call, now two.
If the above is correct I need to keep track of the load result and avoid the second load here
@richiardiandrea: No, only if a load fails, and only if the initial segment of the namespace is clojure
, does it try again replacing the initial segment with cljs
.
thanks, I am threading through js.cljs
with a lot of debug-prn
😄
@richiardiandrea: Here is the branch logic https://github.com/clojure/clojurescript/blob/63e0d7380ee5c45d74a93613aafe982ee600e990/src/main/cljs/cljs/js.cljs#L346-L348
yep, I put a debug-prn there to understand why the load fails and:
core.cljs:155 Loading result: {:error #error {:message Could not parse ns form clojure.string, :data {:tag :cljs/analysis-error}, :cause #object[Error Error: No protocol method IDeref.-deref defined for type null: ]}}
this is why
In other words, if there was no error loading clojure.string
continue on with load-deps
on the (next deps)
, otherwise, if-let
can convert to cljs-dep
, try a require
on it.
would be good to add this log permanently
thanks Mike, that put me on the right path
I will open an issue, it is a one liner patch...so that we at least see it in the logs