This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (107)
- # aleph (1)
- # announcements (7)
- # aws (8)
- # beginners (57)
- # boot (3)
- # braveandtrue (18)
- # cider (6)
- # cljdoc (8)
- # cljs-dev (140)
- # cljsrn (1)
- # clojure (191)
- # clojure-berlin (5)
- # clojure-finland (1)
- # clojure-hamburg (4)
- # clojure-italy (17)
- # clojure-nl (14)
- # clojure-spec (1)
- # clojure-uk (72)
- # clojurescript (29)
- # component (2)
- # cursive (10)
- # datomic (30)
- # docker (1)
- # figwheel (1)
- # fulcro (14)
- # immutant (2)
- # juxt (18)
- # leiningen (52)
- # nrepl (3)
- # off-topic (8)
- # pathom (1)
- # pedestal (3)
- # re-frame (6)
- # ring (3)
- # ring-swagger (5)
- # rum (4)
- # shadow-cljs (15)
- # spacemacs (9)
- # specter (12)
- # tools-deps (11)
- # unrepl (11)
- # vim (7)
- # calva-dev (372)
- # clojure-europe (3)
@dnolen oh just sounded like a sound thing to do for saving time for other folks
yeah I see your point and the decision is of course yours, but the work has been done so I guess it is just a matter of deciding if it's work pushing a button...I would do it...
kk just as a data point, one of the most used libs for reporting errors
humane-test-output, was affected
sorry having some context helps me evaluate and Idon't remember anymore what this is aobut
I'm happy to have a different opinion if it's possible for me to evaluate your thought process
so...first of all it is not a big deal...but something that I have just been thinking a bit when things broke under my feet :smile:
should it still be considered a breaking change and therefore signaled in the release notes?
your answer above suggests you don't think so, but gut feeling was saying that it should have
well the issue is this: https://github.com/pjstadig/humane-test-output/issues/37
you might argue that there is some technical debt to cleanup in that lib....you are actually probably right, but I am just the messenger :smile:
@mfikes what's the status of https://dev.clojure.org/jira/browse/CLJS-2945 given CLJS-2913?
so I was looking at CLJS-2999 yesterday while doing CLJS-3010 and was wondering if it was worth addressing the fact that the protocol namespaces are different between CLJ and CLJS
defprotocol Datafiable is in
clojure.core.protocols, and then the public implementation is in
Datafiable to be extended via metadata
Datafiable to match same namespace as CLJ so that metadata protocol extensions are portable for it
Sorry for the delay; I see above I have 2 things int the queue. Will try to get to them over the ext hour or two
@dnolen For https://dev.clojure.org/jira/browse/CLJS-2945 the issue still exists, with the root cause likely being that we’d need to add the CLJS-2913 improvements to the runtime side of things.
I’ve been porting
ex-str to ClojureScript, so I’ll see if I can cobble together an experimental patch for CLJS-2945. I suspect it would need some baking time before we are happy with it, but I’ll at least make a stab at it.
mkay. still working with datafy, I’ve shuffled the namespace’s around to match CLJ and enabled extension via metadata. Still, there’s some differences:
- if the datafied value differs from the value passed into datafy, clojure.datafy/datafy adds a
::class metadata with a symbol of the original value’s
.className. I’m not sure how best to support this for all environments and through advanced compilation.
- several default implementations of datafy, specifically:
- Throwable - CLJS equivalent would be
js/Error, although I’m not sure that covers all cases
- clojure.lang.Namespace - no CLJS equivalent AFAIK
- java.lang.Class - I’m not sure if this is possible, since JS “classes” are constructor functions
reading into it, I think the intention for the
::class metadata is to at-a-glance be able to switch depending on what the type of the original value was that was datafied
e.g. if you have multiple values that get datafied to maps, it would be useful to know what the original value was to do things with it later
well I’m still trying to think of how to do it in a way that works for all environments and with advanced compilation
https://dev.clojure.org/jira/browse/CLJS-2945 now has an experimental patch that shows a potential avenue for essentially pushing the improvements to exception handling down into the runtime for what I think is
It worked, producing the following, but, there’s honestly a lot of work that would need to be done before we are happy with it:
cljs.user=> (foo "A") Execution error - invalid arguments to cljs.user/foo at (<cljs repl>:1). "A" - failed: int? at: [:n] cljs.user=> (ffirst 1) Execution error (Error) at (<cljs repl>:1). 1 is not ISeqable
Right. The only reason to include the other phases is if we wanted self-hosted users to be able to use them. But, to be honest, they could all be deleted from there.
The source of this patch was some work I was doing for Planck, where all the phases exist.
Yeah, for self-hosted, the code could be there dormant, but usable by REPLs like Planck or Lumo if they wish
We might be able to drop this case: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/repl.cljc#L893
Well, you raised a good point, we have the case above that may not be used in Clojure, and the converse of all of those in ClojureScript.
(An interesting aside is that repl.cljc could in the future be used for both Clojure and ClojureScript, but for now it is still really Clojure.)
But, TL;DR, the extra cases on either side hurt nothing, and on the ClojureScript side, the extra cases could be used for self-hosted.
One thing that is missing from that patch is that it only revises the Node stuff, and didn’t do anything for browser, etc.
It also interestingly might mess with current code that expect a parseable stacktrace in that string. But, having said that,
pst still seems to work properly.
So, in short, I bet this kind of patch might be in the direction we want. I just slapped it together so quickly, I’m nervous that it is solid yet.
@mfikes I see, but can't we just wire
extract-canonical-stacktrace to this existing runtime stracktrace stuff?
Oh, yeah, the
extract-canonical-stacktrace could be wired up. (It may not even really be needed—that was from WIP where I was trying to copy Clojure’s
But yeah, in general, I don’t see any huge challenges. Just some good old fashioned work to bring that patch up to a higher level of quality. Alternatively, a derivative of that patch could be landed and further refined over time
@lilactown patch looks ok but weren't there tests for datafy? Pretty sure there were so I don't see how they could work now?