This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (93)
- # boot (3)
- # cljs-dev (5)
- # clojure (49)
- # clojure-india (8)
- # clojure-russia (1)
- # clojure-spec (4)
- # clojure-uk (37)
- # clojurescript (33)
- # cursive (4)
- # datomic (4)
- # fulcro (11)
- # graphql (1)
- # lumo (16)
- # mount (1)
- # off-topic (21)
- # onyx (2)
- # portkey (4)
- # shadow-cljs (3)
- # spacemacs (4)
- # sql (1)
- # vim (1)
is there a recommended way to avoid shadowing in names? in python, if you have to create a variable called
list, you'd name it
list_ instead to avoid shadowing python's core function
Many people will intentionally abbreviate names they don't want to shadow, e.g. lst
One might argue that a var called list is a badly named var. If it’s just holding any generic list, I’d go for l. If it ere a list of foos, I’d call it foos.
hm, if I have a fairly large module (specifically something that generates a single pdf file) and lots of small functions that create parts of it, should I use dynamic binding to pass a reference to the data structure those functions pull their data from (it's the same for all) or should I just keep passing it down?
Hello guys, I was trying to setup a Solo datomic cloud environment. I was able to establish a connection through the bastion server but when a run a command I get a "Forbidden to read keyfile a". I tried to setup the IAM policy, but I am not sure where I should attach the policy to GetObject from S3.
it'd be great if
#() anon functions worked well with the threading macros... such a shame i need to wrap them in extra parens
java.lang.RuntimeException: Method code too large! errors in namespaces where there are no large methods, but lots (as in, thousands) of definitions. Is there an upper limit on the number of top-level forms?
@jrychter Any deeply nested doseq uses in there? Or using the core.match library or some other library that has small macro invocations that can expand into big code?
I would not be surprised if there was something about have many defs in the same namespace alone that causes that error, but not familiar with what it would be.
@andy.fingerhut no — just defs. These are auto-generated definitions for FontAwesome, later used by some clever macrology. Here is an example:
(def pen-square-solid "@noinline" "M400 480H48c-26.5 0-48-21.5-48-48V80c0-26.5 21.5-48 48-48h352c26.5 0 48 21.5 48 48v352c0 26.5-21.5 48-48 48zM238.1 177.9L102.4 313.6l-6.3 57.1c-.8 7.6 5.6 14.1 13.3 13.3l57.1-6.3L302.2 242c2.3-2.3 2.3-6.1 0-8.5L246.7 178c-2.5-2.4-6.3-2.4-8.6-.1zM345 165.1L314.9 135c-9.4-9.4-24.6-9.4-33.9 0l-23.1 23.1c-2.3 2.3-2.3 6.1 0 8.5l55.5 55.5c2.3 2.3 6.1 2.3 8.5 0L345 199c9.3-9.3 9.3-24.5 0-33.9z")
That is exactly what I'm doing right now — but it still takes a while, as each compilation run takes several minutes (it's a large project).
I'm puzzled, though — this ns contains just the ns definition:
(ns ui.fontawesome.paths (:refer-clojure :exclude [key filter list clone comment import print map sort sync repeat])) — and the defs. There are no functions in there.
And I was pretty happy with the whole setup (the resulting ClojureScript only includes code for the icons that are actually used), until I updated Font Awesome, regenerated the defs, and everything broke because the authors added new icons.
I just created a Clojure/Java namespace with 1 million def statements, and require'd it from the REPL. It took a while, but no error.
I don't have a quick way to try it with ClojureScript, which may give different results.
Also, loading it interactively (through Cider) works fine. What fails is building an uberjar with
I have no idea if this is a huge plumbing change for you, but an alternative to consider would be putting all of those values in a big map with keys like :pen-square-solid. However, having a single map of that huge size in your source code rather than a data file loaded at run time might lead to the same problem, so better to test out a big map in a source file before changing all the plumbing.
Not sure if the issue is triggered by many top level defs in namespace, or large quantity of data.
No, that won't do. The whole idea here is to have individual defs, with annotations, so that macros can use a single one and only the ones used get included in the resulting ClojureScript.
I have the limit pinned down to somewhere between 6550 lines and 6600 lines, and there are approximately two lines per def.
With a namespace that just has many auto-generated defs like these: (def x0 0) (def x1 1) (def x2 2) (def x3 3)
Well that's a bit of a problem. I felt quite smug about the whole system. I don't think any other language/solution can include only the actually used icons easily.
I don't know if having large strings instead of integer values would lower that number.
Well, AOT is there mostly to avoid surprises in deployment — to have a more predictable build. It's not there for performance, which I don't really need.
Ok, I got the exact number.
ns form + 3274 defs is the maximum I can AOT compile. Adding the next def breaks things.
I think I can work around this by splitting the fontawesome library by categories, but this isn't work I expected to do 😞
i'm sure bronsa could answer this but what does a namespace of
def forms get compiled into? Seems strange it would hit a method too large error
That's why I'm wondering where to ask about this next. Perhaps it's something that can easily be fixed or worked around. I know it isn't a frequent use case, but it's a good one.
I would imagine it's the static class initializer method that is triggering that -- and the
def initialization would be part of that. I'm guessing but it "makes sense" to me.
yes, there is I believe a ticket for this issue - it’s in the init methods if I recall