iirc prepl was designed so you’d have multiple connections open for different use cases, i.e. a separate connection for completions

Tutkain doesn’t use prepl, but does open (by default) two connections to each Clojure runtime; one for evals, one for everything else. Additionally, it technically allows you to open as many connections (these eval connection plus tooling connection pairs, really) as you want to a single runtime, but I don’t see much of a reason to do that, really.

the stuff in ctd.tree is the replacement. you might also want to look at how -X:deps tree works as it puts all of that together. See: https://github.com/clojure/tools.deps.cli/blob/main/src/main/clojure/clojure/tools/deps/cli/api.clj#L80-L125

if you have follow up questions, best in #C6QH853H8

just plain old -X:deps tree does the job, somehow I missed that. Thanks

Even if it works, don't do it. You're relying on a specific order of things inside {...}, which isn't a great thing.

You’re just talking about destructuring right? (as there isn’t a problem with evaluating expressions inside regular maps)

Yes.

So is my idea of a “dynamic default” that you can easily see in a docstring just a bad idea?

Just use a plain let. Everybody knows it, everybody does it that way. If it's important to document, add it explicitly to the docstring. Alternatively, if you don't use wildcard-limit if wildcard-append? is not true, just set its default to 1 unconditionally.

https://clojurians.slack.com/archives/C03S1KBA2/p1684892002684079?thread_ts=1684891012.800579&cid=C03S1KBA2

Thank you!

it would be helpful if you shared a full example and what output you get

Another thing to consider is that the ^Baz syntax is a https://clojure.org/reference/metadata#_metadata_reader_macrosand happens at read-time which is before the macro has a chance to make any changes. It might be the problem is with your test is written rather than your macro. An example that demonstrates your issue would be helpful.

The output I’m getting is "cannot resolve class for baz (tagged as Baz)" Nevermind, that’s the error message from my code.

An example would helpful. My guess is that Baz isn't imported in the namespace where the test is defined.

And I think what macro does is (-?> tag symbol resolve).

It is actually defined in the test namespace. But when I was debugging it further, resolve relies on *ns* which was set to user when test is running outside of repl.

I guess the simplest fix is to wrap with binding [*ns* ...]

And the test works when executed in repl

maybe, but I wouldn't expect that your macro should be in charge of resolving

(defmacro my-macro [form]
  form)

(meta (macroexpand '(my-macro ^Memory {})))
;; {:tag Memory}

(meta (my-macro ^Memory {}))
;; {:tag com.sun.jna.Memory}

{:tag Memory}
;; {:tag com.sun.jna.Memory}

I think resolving the symbol, Memory , to the class com.sun.jna.Memory typically happens after the macro returns a result (ie. during evaluation)

The difference between (meta (macroexpand '(my-macro ^Memory {}))) and (meta (my-macro ^Memory {})) is that the former's result is before evaluation and the latter's is after evaluation.

I think this example captures everything I have. I apologize for the error message above, it was from my code. resolve returns nil and even macroexpand fails to resolve the macro name properly when run non in repl. If I don’t use n-test/m and do just m, macroexpand doesn’t resolve it and leaves as is.

Testing n-test
nil nil

FAIL in (m-test) (n_test.clj:21)
expected: (= n_test.A (macroexpand (quote (n-test/m (A. 5)))))
  actual: (not (= n_test.A nil))

Example output if not using a fully qualified name for m:

Testing n-test
(m (A. 5)) clojure.lang.PersistentList

FAIL in (m-test) (n_test.clj:21)
expected: (= n_test.A (macroexpand (quote (m (A. 5)))))
  actual: (not (= n_test.A (m (A. 5))))

You can read my other responses for the explanation, but your macro shouldn't be calling resolve in this case. If you did want to try and test using macroexpand, then you should test for the symbol, 'A and not the class n_test.A.

I agree that resolve doesn’t work in test runner. But it perfectly works everywhere else where the macro is used.

It’s been in the codebase for ages 🙂

Without resolve, it is just a symbol A that doesn’t carry any meaning that macro tries to extract from it. It wants to get access to the record class it represents in a given context.

Generally, macros don't have access to runtime info and only see the code as raw data literals. Given your example, I don't see why ^A needs to be resolved.

But they need to be able to recognize symbols and generate code based on what those symbols represent.

An example would be helpful, but usually, resolving A to my.class.A happens at evaluation time after the macro runs.

If you do need access to runtime info, then usually the macro generates the code that will run at runtime to use the runtime info.

I agree that it is an option but that defeats the purpose of this particular macro which tries to perform evaluation time checks (such as that the field exist on a record) and generate efficient code (such as accessing the field using the java interop.

That makes sense.

It sounds like your macro is correct. Maybe try using quasi quote in your test:

(macroexpand `(n-test/m ^A (A. 5)))

It kinda depends on what you're trying to test.

Oh, cool, it does work for this example. I’ll try it for the original problem. Thanks a lot for the suggestion!

Yep, that works there too! Thank you very much!