clojure 2023-05-26 | Slack Archive

What am I doing wrong? Here’s the function declaration:

(defn find-by-last-name
  "Find users by str-last-name"
  [db {:keys [last-name limit] :or {limit 200} :as params}]
  (core/find-by-last-name db params))

But there is no :limit key in params. I think it always worked before

p-himik12:05:52

Nope, it has never worked that way. params is exactly what you've passed in (coerced to a map in some cases). :or affects only the bindings creates by :keys.

licht1stein12:05:16

I see, thanks!

licht1stein12:05:08

That makes a lot of sense, actually, now that I think about it

licht1stein12:05:38

So I just did this, for the record:

(defn find-by-last-name
  "Find users by str-last-name"
  [db {:keys [last-name limit] :or {limit 200}}]
  (core/find-by-last-name db {:last-name last-name :limit limit}))

igrishaev13:05:05

(def defaults
  {:limit 200})

(defn find-by-last-name
  [db opts]
  (call-your-func db (merge defaults opts)))

or this

licht1stein13:05:52

Thanks!

licht1stein13:05:52

But the way I did it you can see the default parameter value in function documentation

rolt13:05:25

just a warning:

(let [{:keys [limit] :or {limit 1}} nil] limit)           ;; => 1
(let [{:keys [limit] :or {limit 1}} {:limit nil}] limit)  ;; => nil

if the key is present but the value is nil you won't get your default, ~~that's why I'd recommend merging instead~~

DrLjótsson19:05:30

@U02F0C62TC1 , the same is true for merge, no? A nil value in opts will overwrite the default value

rolt10:05:47

yes you're right, I guess my initial point was that :or has not the same behviour as or but the merge part is a mistake

👍 2

Brian Beckman16:05:50

SOLVED Hello — I have an S-expression that seems to be too big for the Clojure reader! It’s about 2,025 lines long. lein run on the gist linked below gives me

┌─(~/tmp/reader-test)────(brian@Golf37:s011)─┐
└─(09:28:14)──> lein run                                                                                                                              1 ↵ ──(Fri,May26)─┘
Syntax error (IndexOutOfBoundsException) compiling fn* at (reader_test/core.clj:1:166).
Method code too large!

Full report at:
/var/folders/cp/df32wpxn1ps8dmn6w_tydwdr0000gn/T/clojure-7617868419525093815.edn

and that seems to be an unavoidable Java limitation. The S-expression is a vector, so I can break it up manually. Or I could write a preprocessor in some other lisp, say SBCL. But I’m looking for ways to ingest it and break it up with Clojure code. I’ll be grateful for any of your kind advice! https://gist.github.com/rebcabin/7b2f14fc83149181feaa6ee136953012

🏁 2

hiredman16:05:33

it isn't too big for the reader, the problem is you are passing it through the compiler

hiredman16:05:58

the compiler emits jvm byte code, and the jvm has a limit on how large method bodies can be

hiredman16:05:52

the easy solution for this is don't include it as a literal in your source code, keep it has a resource file and load it at runtime from there

p-himik16:05:27

Also, wrapping it in (def data ...) seems to fix the error for some reason.

hiredman16:05:18

exactly when you hit the too large method limit is going to be very context dependent, the def thing may punt it down the line until you add a few more items

hiredman16:05:28

like for example def is handled specially at the repl, so you may not see the error at all there

Brian Beckman16:05:30

these give me good ideas to try … more later

p-himik16:05:32

Hah, yeah. That "fixes" requiring the code. Compiling it still produces the error.

Brian Beckman16:05:35

i definitely need to compile it! I’m doing syntax checking on it via clojure.spec. It’s intermediate rep for a Python compiler.

p-himik16:05:27

Not sure how the need to compile follows from the usage of either spec or Python. You can definitely check dynamically created data with spec.

🏁 2

Brian Beckman16:05:31

Brian Beckman16:05:36

working on it …

Brian Beckman16:05:27

ok, i think reading it in as dynamic data will work. TY!

👍 2

2023-05-26

Channels