Hello I'm trying to implement the "webpack method" on my "real" project but the compiler says Error: Cannot find module '@cljs-oss/module-deps' On a small/toy project, I do exactly the same and get no errors.

how do I suppress stack traces in the repl (cider)?

@souenzzo Looks like you have node_modules directory present, disable npm module support with :npm-deps false option

:install-deps option is no-op without :npm-deps

Hi guys, may I ask a very abstract question: is it possible (or is it worth it?) to use Clojurescript+ReactNative for business logic only? I'm fine with UI in Swift/Java, but I'd like to make a "core" engine which would handle HTTP calls, validation, forms handling, search, etc. I'm not really interested in x-platform UI as I have 100% positive experience with native technologies - I depend on pretty and fast native animations and other platform-dependent stuff - but I'm looking for a replacement for my current x-platform stack (C++ core/business logic/view models, djinni x-language bridging, Swift/Objective-C/Java/Kotlin for UI and platform-dependent code). So is it possible to make a small core in Clojurescript and then just execute callbacks on a native side which would consume nothing but maps and lists? Without touching ReactiveNative UI part. I'm eager to throw away C++ from my life 😬

Is metadata on namespaces allowed/supported in some way?

@martinklepsch allowed and supported yes (but as usual only available in analyzer data in the compiler env)

@thheller just to be sure, this syntax and all (ns ^:no-doc codox.example3), should be reflected in the result of parse-ns?

uhm actually I'm not sure if it works properly in CLJS. I vaguely remember fixing a related issue in shadow-cljs, not sure if I ever made a ticket/patch for this

but yes that is valid

(ns codox.example3 {:no-doc true}) would also be correct

@thheller hm, I can’t get it to work at all 😅 does any of this look wrong to you?

hmm CLJS might not store the data in the AST properly

only on the (-> ast :name meta)

this will get lost with caching enabled though

@thheller thanks (-> ast :name meta) was it! not sure I would have thought of trying that 🙌 🙂

https://github.com/weavejester/codox/pull/177/files

Guys, I am using Webpack to pack external libraries and calling them from js namespace from clojurescript. But I can’t optimize my code because of that.

Any solution for this ?

why can't you optimize?

Hi there, Anyone knows a good library (or safe piece of code) that exposes a cljs function that returns a core.async channel for javascript consumption?

@thheller, hi again. 😇 It was an early crying. I solve my problem with these steps: - I looked into Optimization Documentation. It Cryptes variable names. --I didn’t know, really ¯\(ツ)/¯ - I thought, If I change my variables into strings. --which is crytical/untouchable for optimization processor. - I change my variable accessing function with goog.object/getValuesByKeys function call. It solved my problem. I don’t think it would be that easy. My verbosity for newbies like me. —forgive me guys—

@thheller do you have any other solution for this. I don’t know, it is the right way or not…

does array-seq result in a lazy seq?

I'm getting (instance? LazySeq (array-seq #js[1 2 3])) => false so that means it's not lazy right?

@jjttjj Right. It returns a cljs.core/IndexedSeq, which can do nth, for example, in O (1).

thanks!

(indexed? (array-seq #js [1 2 3])) => true

@scknkkrer you might be looking for (defn ^:export your-fn [] ...) if you mean to call your.app.your_fn() from HTML?

Entering 1/2 in a figwheel REPL and with "lein cljsbuild once" I get: "failed compiling constant: 1/2; class clojure.lang.Ratio is not a valid ClojureScript constant." lumo is dealing with it just fine returning a float for cljs.

In another project I get "No method in multimethod 'emit-constant' for dispatch value: class clojure.lang.Ratio"

unfortunately a quick web search has not revealed what is exactly the status of ratios.

@whilo I’m not sure ClojureScript supports ratios

it doesn't

but it should be able to read expressions like this, i think

the reason it works in Lumo is because the underlying compiler platform is JavaScript

yes, it seems the cljs reader can deal with ratios just fine

and JavaScript just accepts the 1/2 pattern and a bunch of other garbage

but shouldn't the cljs reader throw an error at me?

@whilo I think the reader reads it just fine

the error you’re getting is from the ClojureScript emitter if I’m not mistaken

yes, isn't that a bit weird?

paging @mfikes

^ do you know if there’s an open JIRA for this?

well whether it should work is really up for discussion

just because the reader passes it through isn’t a reason

coercing to another numeric type isn’t desirable IMO

@whilo so you’re just asking for a more meaningful error like "ratios aren't supported"

A motivating similar example. Consider .3 That is not a valid thing in Clojure. The fact that it seems to do something in ClojureScript doesn't mean it is valid in ClojureScript.

(All I'm sayin is that there are things you can type which have undefined behavior.)

@dnolen that is an option. i have just been confused by porting some clojure tests and 4/2 was working, while 1/3 stayed a ratio and was throwing the error at me

if 1/4 is supposed to be syntax for ratios and they are not supported then it should probably not be readable

if 1/4 is a valid shorthand for 0.25, then it should be autocasted

well I don’t really agree with either of those conclusions 🙂

perfect 🙂

whether it’s readable or not is not that relevant I think

reading is more than source

autocasting is not really a thing in Clojure

far as I tell this is just about the error message

what does 1/4 mean?

what does it mean in Clojure?

then that’s what it should mean in ClojureScript

there it is describing a rational number and equivalent to (/ 1 4), right?

unless … we cannot provide generic arithmetic

which we can’t yet

not without damaging performance across the board

you mean polymorphic arithmetic?

yes

what would be the interesting types in cljs? big numbers and ratios? or full protocol support like core.matrix(?)

i am atm. working with core.matrix in cljs

Actual 64-bit integers would be interesting as well 🙂

right

what is happening in js land in this direction?

there’s a multimethod proposal which far as I know hasn’t gone anywhere

hmm, how can this not be a perf problem in js? clojure piggiebacks on java's polymorphic method dispatch, right?

JS only has one numeric type - Double

JS engines however play lots of tricks due to the spec

yes, but i guess some people would like to support richer numerical types

to optimize to 32bit integer math when they can

just for reference, i am porting https://probprog.github.io/anglican/ to cljs atm.

I've played with https://github.com/gfredericks/exact a bit. It can be tedious, but is definitely useful

@whilo anyways - in case somehow something was misunderstood 1/4 is a valid literal in Clojure

it can’t be yet in ClojureScript - due to the issues I’ve mentioned

FWIW, https://dev.clojure.org/jira/browse/CLJS-555 is one of the most highly voted JIRAs

i agree and it is not critical for me, i have moved to the (/ 1 4) expressions

ratio support itself is helpful, because of floating point numerical errors. it makes testing of some code easier and precise

i am now getting (not (m/equals [10.666666666666666 10.666666666666666 10.666666666666666 10.666666666666666] [10.666666666666664 10.666666666666664 10.666666666666664 10.666666666666664]))

for example

which means i need to use different equality semantics with an epsilon

You also have the unfortunate difference with (/ 0) between Clojure and ClojureScript. Former is an error, latter is a hosty mathematical ¯\(ツ)/

presumably it’d be very hard to add different forms of math to + without incurring a dynamic dispatch overhead on all mathy things

(my favorite javascriptism is (+ .1 .2))

If you're so inclined, -0.0 will bother you endlessly 🙂

omg. and it keeps track of the signs if you keep multiplying -0 times itself. haha.

It exists, you just can't print it. Behold: (/ (/ ##-Inf))

https://dev.clojure.org/jira/browse/CLJS-2379 if interested

oh i see. i didn’t know about that in javascript to being with and now that i’ve learned of it i now learn it won’t print in clojurescript. 🙂

Are shadow-cljs and cljs.main comparable to each other?

@ghopper they are different, if you have been using cljs.main I'd suggest you try figwheel.main as the cli is comparable

I've actually been using cljs.main. I was just wondering if they were on the same level.

but shadow and figwheel.main are both more fully featured

Err, I've been using figwheel.main.

Ok, so shadow-cljs would be comparable to figwheel.main?

yes, it has a different compiling strategy

I just figured I'd try all the options before settling on something. I started with Boot-cljs, then I tried pure cljs.main, then I moved on to your figwheel.main.

It uses the normal cljs compiler under the hood though, right?

yes, AFAIK

:thumbsup: Thanks

I'm still not sure I buy into this CLI script with Makefile idea. It's certainly very nice for some things during development, but there's a lot to be said for the build process entirely being a clj program.

@ghopper and there is nothing preventing that

you can trigger your build process from code in a very straightforward way

You make a fair point. I think I just need to spend more time to figure out where the happy middle ground is between using CLI argument only and calling the clj API instead.

I kinda jumped from one extreme to the other.

so you are aware that you can add main options to deps.edn?

Hmm, no, I'm not actually sure what that does.

I know I can just write build scripts and clj $script them.

https://github.com/bhauman/figwheel-main-template/blob/master/src/leiningen/new/figwheel_main/deps.edn#L13

you can create aliases that invoke command line args

and you can invoke that alias clj -A:build

Oh, right, yeah. I thought you were saying there was a :main entry in deps.edn that did something. I'm familiar with aliases. That's a good idea over just doing everything in the Makefile.

I've only used them for my system global aliases for rebel readline and such.

I do like that over all the phony tasks I have in my Makefile.

an interesting pattern is to have a user.clj file with a bunch of tasks in it and then invoke functions in it via these aliases

Do you by any chance have a repo you can point to that's using this?

{:main-opts ["-e" "(user/build)"]}

I'm sorry I don't

It's a good idea. I was thinking I'd need separate namespaces for each to use -m.

That's alright :thumbsup:

I know this is kinda new ground. Overall I'm liking the direction. It feels a lot cleaner without the overhead of Boot's abstractions.

(or Leiningen for that matter)

way less magic, but you better get the classpath right 🙂

🙂 Thanks for talking through things with me.

you would want to separate namespaces if you had a vastly different set of dependencies for certain tasks

Yeah, certainly. So if you had for e.g. tasks for managing AWS infrastructure via CloudFormation, would you do that in a Makefile, or would it make sense to use clojure.java.shell to call the aws CLI?

That's kinda outside the scope cljs, I guess. I'm just trying to figure out how to divide things.

it really depends right?

is it a simple single call? is your team only on unix?

should you be using a java AWS api?

All good point. I hadn't thought about non Unix contributors. That is one of the benefits of using Boot and clj only stuff.

I think there is a clojure aws wrapper

There's a number of AWS calls, and I hadn't really considered using a Java API. I guess if we're sticking with the CLI it should be through the Makefile.

https://github.com/portkey-cloud/aws-clj-sdk

Yeah, there is. It's quite nice, though the CLI does a lot for you that I don't want to do manually.

This is the one I was using: https://github.com/mcohen01/amazonica

perhaps better to start simple then

Right, and the CLI through a Makefile is simpler than trying to shell out from clj I think.

absolutely

gotta go make some dinner 🙂

Of course 🙂 Thanks again