This so super ROTFL: https://cljs.github.io/api/cljs.core/js-%3Eclj 😄 😄

(inc nil) should be solved* at development time with #clojure-spec + instrumentation, don't? * Solved/detected

how are people testing the rendering code in their cljs UI's? (i use om.next, so i can test the most of the logic already)

@cjhowe you could use devcards?

https://github.com/bhauman/devcards/blob/master/README.md

@souenzzo something like that might be possible - but the issue is that we use those same arithmetic functions everywhere in the implementation of the standard lib itself

@dnolen @souenzzo curious, why does that make it an issue?

(I, too, was hoping for specced core to make such restrictions in core function semantics clearer)

@reefersleep persistent data structures rely on primitive arithmetic being fast, no checks

you also have many libraries written over the years with those exact same assumptions

ah OK, I get the no-checks-for-speed part… I wonder if this could be circumvented somehow? Maybe give developers a large-grained choice of using specced core or not?

The point about the libraries seems moot in the face of your comment much further up about the semantics being undefined. Ideally, libraries shouldn’t rely on undefined behavior… right?

I’m not going to get into this right now

😄

but I would estimate 6 months 1 years of hammock time

so you have a lot of free time to think about this be my guest 🙂

I’ll be sure to remember that 😉 😛

I would say this easily one of the hardest known problems

totally get that it’s something cljs core developers have probably already put way too much thought into, and not something easily conveyed to outsiders without the proper context

Wouldn’t mind being credited with solving that, then. But would probably mind the time needed 🙂

does anyone have any good resources on unit testing in cljs?

Where is clojure.edn/read-string ?

cljs.reader/read-string

does anyone have any resources/examples on using core.spec to handle form input validation?

@dpsutton there’s really not that much to it, cljs.test more less mimics clojure.test - the only other bit is running the tests from command line and that depends on your build tool

Hi, I was wondering if one could do a (require-macros ... inside a cljs/eval-str?I am getting a error self__.rdr.cljs$tools$reader$reader_types$Reader$read_char$arity$1 is not a function

@tiagoantao pretty sure you can because I do it all the time in Lumo

can you post a snippet that’s not working for you?

@anmonteiro: https://github.com/tiagoantao/turtle/blob/master/src/turtle/paperjs.cljs#L103

thanks!

The non-macro stuff works

@tiagoantao weird that it works since you’re not returning a string for the source

a cljs.core.async/go call returns a channel

your loadfn looks fishy

but works without the require-macro

(there are a couple of lines there for functions, the two other requires)

I’m not convinced

I just tested it without the require-macro

@tiagoantao try this first:

(defn loadfn [mp cb]
  (go
    (let [response (<! (http/get (str "" (:path mp)
                                   (if (nil? (:macros mp)) ".cljs" ".cljc"))))]
                                        ;(prn mp (:status response) (:body response))
      (prn mp (:status response))
      (cb {:lang :clj
           :source (:body response)}))))

what's the status of clj-refactor for clojurescript? eg when I try to rename a symbol in .cljs or .cljc, it says not possible..

@anmonteiro: thanks! It now works with macros. Strangely it was working with the (require

like I said, I’m not convinced 🙂

it probably just appeared to work because the JS code was loaded in your environment

does anybody know how to resolve these warnings?

WARNING: Can't take value of macro cljs.core/use at line 9 /home/vinicius/.boot/cache/tmp/home/vinicius/Documentos/presidios-pb/4uo/-mt9ni4/static/js/app.out/om/dom.cljs

@vinnyataide which CLJS version are you on?

sounds like a warning produced in an old version

@anmonteiro

[org.clojure/clojurescript "1.9.473"
                   :exclusions [org.clojure/clojure
                                com.google.guava/guava]]

can you upgrade to 1.9.908?

the warning should just go away

yeah

@anmonteiro

java.lang.NoSuchMethodError: com.google.common.base.Preconditions.checkState(ZLjava/lang/String;Ljava/lang/Object;)V
clojure.lang.Compiler$CompilerException: java.lang.NoSuchMethodError: com.google.common.base.Preconditions.checkState(ZLjava/lang/String;Ljava/lang/Object;)V, compiling:(closure.clj:100:1)

woah

uh

You probably have an outdated version of Guava

ops shouldnt be posting on this thread

You should be on whatever Guava version Closure dependends on

I'm thinking of doing a cljs wrapper for the js version of libp2p (https://libp2p.io/), and eventually filling in a fully native clojure(script) implementation In the libp2p organization, the various modules are all split into separate repos... is that a good idea for a clj(s) lib, or should I just keep it to one clj-libp2p repo?

@anmonteiro still same error message

is this what they call dependency hell? =P

Can someone well-versed in dead code elimination and :npm-deps answer a question? DCE works based on what’s reachable from the :main entry point, correct? We have an old project that adds a bunch of .js files through the :preamble, but those files respond to many things outside our control (onload events, DOM mutations, global js flags, etc). If I add them via :npm-deps, will functions not directly reachable get removed? If so, is :foreign-libs a better choice?

@kingmob that sounds like :foreign-libs use case to me

Thx @dnolen! Does the :foreign-libs vector respect the order of libs?

And do the :foreign-libs come before the main code?

it’s not really a guaranteed thing if you don’t specify :requires - if you need an order then you must specify dependencies via :requires

@kingmob in production yes - :foreign-libs come first

Thx! Is :npm-deps similar, but for pulling from node_modules? Or could it run through :advanced optimizations?

:npm-deps is a completely different thing

it’s just for consuming node_modules and the assumption is Closure will see everything

whether :advanced works or not depends on the library under discussion

Got it, thanks so much. Any plans to add a flag so :npm-deps libs don’t go through Closure?

E.g., could it allow us to take advantage of npm’s deps without having to specify them manually?

no interest in that at this time

everything is going to go through Closure - if that’s not going to work for you then you need to use foreign libs

Got it. Thanks for your help.

but you also said something which is actually treated orthogonally anyway

:npm-deps is just about specifying node deps, particular useful for upstream libs

consuming node_modules is a separate thing

you can consume it without :npm-deps

still - my other point is unchanged - Closure is what handles node_modules in the end so whatever you consuming needs to work with :advanced

@dnolen Did I hear that Closure Compiler had some new support for consuming npm libs, or did I imagine that? I don’t see anything online… Right now, my plan is to specify what I need in package.json, and consume it in :foreign-libs. Maybe some of them can move to :npm-deps if their unreachable behavior isn’t needed.

ok just found out the problem, using datomic and cljs in same project give some inconsistency with guava