Thanks for the quick response. Your references are helpful. I've looked at other similar examples from my google searching. My message was not clear in expressing my issue. I am doing what is shown in the clojure/javadoc.

IFn plus = Clojure.var("clojure.core", "+");
plus.invoke(1, 2);

All of the examples I've seen show a function that does not reference code in another file. My simple code example is below. Java file contains:

IFn foo = Clojure.var("mod.a", "foo");
foo.invoke(1, 2);

(ns mod.a
  (:require [mod.b])
  (gen-class)
  )

(defn foo [a b]
  (mod.b/bar a b)
  )

(ns mod.b
  (gen-class)
  )

(defn bar [a b]
  nil
  )

Thanks for the reference to the gist. I will study it. I guess I expected something simpler. Calling Clojurescript from Javascript required only include extern in the defn. I assumed it would be just as easy for Java.

I mean, fundamentally it is simple

:...

I bet you could make some nice ascii art this way.

:...<>...

Hope I inspired you to make another tweet-deffable lib!

^ perhaps something that encodes normal keywords into morse code keywords, :sos -> :...---...?

Making Clojure resemble some esoteric languages (like brainf*) 😂

Can you add an issue on clojure-site?

will do now

Thx

https://github.com/clojure/clojure-site/issues/572

Awesome sleuthing @U04V15CAJ!

Sleuthing done by @U2FRKM4TW :)

Awesome sleuthing @U2FRKM4TW!

there's some web related lib (I forget which) that uses keywords like : in tests

that's bad :)

data.xml does some interesting stuff like that :)

but I cannot deny that I also encountered this in a project which keywordized RDF URIs 😂

the issue we ran into with clj-kondo analysis was that we stored info about keywords, like this, given keyword :1.9 , {:name 1.9 ;;<- symbol ...} so when you would read back in that EDN, then the name value would not be a symbol. We should have stored this as a string anyway, but that's when an "invalid" keyword tripped us up.

@U0178V2SLAY This is just for you ❤️ https://github.com/quoll/remorse

Amazing. I just had to try this with babashka.

$ bb -cp src -e "((requiring-resolve 'kmorse.core/keyword->morse) :foobar)"
:..-._---_---_-..._.-_.-.

Were it my call, I'd probably name the repo remorse. :D Only because those keywords look terrifying.

If it were up to me, I would call the lib :-.-_--_---_.-._..._.

I’m sorry… I was focusing my creativity on creating the monster, not naming it 😊

I agree… “remorse” would be a better name

I renamed it, and updated the link above 🙂

you are all bad people

@U051N6TTC that reminds me of my encoder that disguises a plaintext to look like homerow keyboard mashing https://gist.github.com/noisesmith/561c215ffa39f71645b5

user> (base-_SEMI_lkjfdsa-encode "hello")
";ddks;jjfddas;;;"

Something like:

(defn higher-order-update
  [key xfrom]
  (fn [rf]
    (fn
      ([] (rf))
      ([result] (rf result))
      ([result input]
       (rf result (assoc input key
                         (get input key) ;; <-- stick xform somwhere here???
                         ))))))

(defn map-key
  [k xform]
  (let [xf (xform (completing #(assoc %1 k %2))]
    (fn [rf]
      (fn
        ([] (rf))
        ([result] (rf result))
        ([result input]
         (rf result (xf input (get input k))))))))

I haven't tested this at a repl, but this is approximately correct I think. It should be checking for reduced and similar though

plus it should call the completing part of xf too

checking for reduced like this?

(defn- multiplexable
  "Returns a multiplexable reducing function (doesn't init or complete the uderlying rf, wraps reduced -- like preserving-reduced)"
  [rf]
  (let [rf (ensure-kvrf rf)]
    (kvrf
     ([])
     ([acc] acc) ; no init no complete rf
     ([acc x]
       (let [acc (rf acc x)]
         (if (reduced? acc)
           (reduced acc)
           acc)))
     ([acc k v]
       (let [acc (rf acc k v)]
         (if (reduced? acc)
           (reduced acc)
           acc))))))

yeah. If you give me a couple minutes I'll have access to a computer and can give a more complete and correct example

Thank you very much! I will try it out tonight !

Okay @UTTHNCF5L I've got a couple minutes to work on this and I have a question now: how should this act when the transducer produces multiple values, or none?

Or is this a very limited usecase transducer that requires that xform be a stack that produces one value for each result with an optional reduced? result at the end?

I think my tranducers are expected to produce exactly one value per map in the series. But in more general case I think we should just duplicate items from the series or omit them. For example if xform is going to be (filter #(> % 0.5) than just omit all the maps where the :val is less than 0.5

So is there a particular reason you're looking for a transducer that operates on maps rather than doing something like this? Just to make it a little shorter?

(filter (comp #(> % 0.5) :the-key))

(defn key-xf
  [k xform]
  (fn [rf]
    (let [xf (xform conj)
          last-map (volatile! nil)]
      (fn
        ([] (rf))
        ([result]
         (try
           (rf (if (nil? @last-map)
                 result
                 (reduce #(unreduced (rf %1 (assoc @last-map k %2)))
                         result
                         (xf []))))
           (finally
             (vreset! last-map nil))))
        ([result input]
         (vreset! last-map input)
         (let [res (xf [] (get input k))]
           (cond-> (reduce #(rf %1 (assoc input k %2))
                           result
                           (unreduced res))
             (reduced? res) ensure-reduced)))))))

handles reduced, and when the xf produces one value or more than one. It handles producing more than one value by adding the same map multiple times with different values for the key

Works like a charm! Thank you very much once again!

> So is there a particular reason you're looking for a transducer that operates on maps rather than doing something like this? Just to make it a little shorter? There might be two reasons. First is to decouple the logic of filtering values from the specific position inside the map. Second, most of the time transducers need to map something (and often do aggregations like with moving average example)

Sure. Just be careful with aggregations because as I said, only the map paired with the last item before it emits an item will be assoc'ed into. Which won't be a problem if you're just keeping an aggregate and emitting on each input, but with e.g. partition-all it acts a little strangely.

glad I could be of help though

Are you passing in -Dlogback.configurationFile=resources/logback.xml as a JVM option when you run your app?

nope, I got the impression it picked that up automatically I will give it a try

In my projects, I definitely don't specify it explicitly anywhere - logback.xml is just picked up from the classpath.

yeah I just read that is the case and the other option is if you want to override for say prod, not sure how i can confirm if its even picking up the file

I do get this when I launch SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". which I have read should go when you import logback-classic into your dependency list

Just to make sure - when you run ( "logback.xml"), do you get some URL or nil?

yes I do get a file back, that is now going at the start of my app with a prn so I know which file its loading 🙂

I also notice that when launching my app I get this,

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See  for further details.
"file:/var/www/beanbag/workspace/projects/office-api/resources/logback.xml"
MLog initialization issue: slf4j found no binding or threatened to use its (dangerously silent) NOPLogger. We consider the slf4j library not found.
Jan 19, 2022 2:23:00 PM com.mchange.v2.log.MLog 
INFO: MLog clients using java 1.4+ standard logging.
Jan 19, 2022 2:23:00 PM com.mchange.v2.c3p0.C3P0Registry 
INFO: Initializing c3p0-0.9.5.4 [built 23-March-2019 23:00:48 -0700; debug? true; trace: 10]

I import tools.logging into my app should i also be importing logback even if I am not using it directly ?

You mean like via a (:import ...) clause in a namespace declaration? I don’t think so.

I wonder if there’s a typo somewhere in your logback.xml that is blowing up the xml parser and resulting in the “Failed to load class” error?

yeah, I guess the bit that bothers me is the magic part where its supposed to just use logback some how seems the magic is failing somewhere 😕

What's your dependency list? Usually logback-classic + c.t.logging + logback.xml in the classpath does the job. In some cases you need to add org.slf4j/slf4j-api

Maybe you could use clojure.data.xml to slurp and parse the logback.xml file, just to make sure it’s not blowing up during the parsing.

(related article giving an overview just in case you haven't seen it: https://lambdaisland.com/blog/2020-06-12-logging-in-clojure-making-sense-of-the-mess)

Yeah, Java logging is kind of a mess, and lucky us, we get to inherit the mess. 😕

I have read that article and many others, and tried a few different logging libraries 😛

ch.qos.logback/logback-classic {:mvn/version "1.2.10"}
        org.slf4j/slf4j-api {:mvn/version "1.7.33"}
        org.slf4j/jul-to-slf4j {:mvn/version "1.7.33"}
        org.slf4j/jcl-over-slf4j {:mvn/version "1.7.33"}
        org.slf4j/log4j-over-slf4j {:mvn/version "1.7.33"}
        org.slf4j/osgi-over-slf4j {:mvn/version "1.7.33"}

I will try reading the xml file, I will be annoyed if it just ignores an invalid xml file with out some kind of warning though

Your logging output above shows that some thing called MLog is being used. I don't know for sure but my hypothesis is that it's being picked up instead of Logback. I'd track that dependency and try to exclude it.

clj -Stree | grep "mlog" does not find anything just trying the load the xml idea

Are you sure that when you're getting that log output with MLog you are not using some aliases that might affect the classpath?

Also, don't grep mlog - the dependency itself might very well have a different name.

The fully qualified class name that's being mentioned is com.mchange.v2.log.MLog. So, try using (io/resource "com/mchange/v2/log/MLog.class").

Perhaps it’s bundled into c3p0? :thinking_face:

yeah https://stackoverflow.com/questions/5686619/turning-off-logging-for-hibernate-c3p0/5698667 it mentions logback in the answer but does not have a full example

I get this back when dumping the mlog resource

file:/home/oly/.m2/repository/com/mchange/mchange-commons-java/0.2.15/mchange-commons-java-0.2.15.jar!/com/mchange/v2/log/MLog.class

at least the documentation for c3p0 claims compatibility with slf4j & logback (https://www.mchange.com/projects/c3p0/#configuring_logging). I'd suggest looking closely at the dependency tree and verifying you see the correct version of logback-classic there

yeah I just modified mlog config intrestingly it gave me this error

com.mchange.v2.log.MLogInitializationException: slf4j found no binding or threatened to use its (dangerously silent) NOPLogger. We consider the slf4j library not found

my understanding is logback should be providing the compatibility for slf4j

yeah, as long as the versions of slf4j and logback are compatible

> Note that slf4j-api versions 2.0.x and later use the https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html mechanism. Backends such as logback 1.3 and later which target slf4j-api 2.x, do not ship with `org.slf4j.impl.StaticLoggerBinder`.

e.g. ^^ that might be a problem if your project somehow loads a different newer version of logback rather than the one you specified above. But this is just a hypothetical guess

I just cleared my .cpcache folder and it may be fixed 😕

I was not getting these before INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to ERROR

not sure at what point this got fixed now

I guess this is a case of a removed dependancy still in the cache folder perhaps

anyway thanks for all the help guys I think its solved now, the app even launches with these messages at the start now

15:14:23,706 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
15:14:23,706 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/var/www/beanbag/workspace/projects/office-api/resources/logback.xml]

I’m mostly using it to mark things in my ns which should not be relied upon, mainly “don’t use that, it might change” (e.g. not a part of the API)

Can you elaborate on the notion of it being a “holdover from OOP”?

OOP generally emphasizes private stuff - i will disagree though. It still makes sense to have a public and private api for things

(defn- length-helper [collection n]
  (if (empty? collection)
    n
    (recur (rest collection) (inc n))))

(defn length [collection]
  (length-helper collection 0))

basic example - but its pretty easy to have functions in a namespace that dont make sense to expose and are really implementation details

Ok, I’ll buy the use case where you’re publishing an API and you want to distinguish between what’s “official API” and what’s “internal implementation detail subject to change.” My beef is with seeing it used in standalone proprietary app code where it complicates things without adding any value.

Our standalone proprietary app code also has some kind of internal API. I liked @U3JH98J4Rs example. If we have a ns with a lot of such functions which are only used internally to clean things up, the devs might be happy to not have them provided by the code completion tools. But I get that this is more opinion based

just checked, and there are 114 private vars in clojure.core. Thought it was an interesting datapoint

clojure.core is the exception that proves the rule -- that there's no point in defn- for 99% of cases. Instead use namespaces to separate API from implementation and make everything public

clojure.set has a single private function. Would seem strange for there to be a clojure.set.impl with a single function and only one namespace that would call it. That seems far worse than a little metadata marking something private

I first learned about namespaces (packages) in CL. There is no access control enforcement mechanism there, so I don't consider them as being OOP related at all.

I find defn- useful. Like @U0N9SJHCH mentioned, it helps to distinguish internal from external. For maintenance, it also helps me to more easily find and obliterate unused code, although clojure-lsp now helps with finding unused public things too. There is also the ^:no-doc convention to mark non :private vars and nses as internal. I use this too.

I go with the meta data route, i.e., ^:private

I like to signal intent with

(alter-meta! #'your-var assoc :private false)

@U025L93BC1M Smalltalk uses the same convention - you can categorize methods as private purely to the inform the user of the class, no enforcement

@U0CKDHF4L ha, bold!

@U11BV7MTK clojure.core does many things which mortal programmers don't need to do, either for technical or historical reasons

I think calling defn- a holdover from oop is like calling spec a holdover from static typing. Its usecase is to allow you to implement your api, the namespace's public functions, in a way that holds a stable interface even as you improve the internals both in style, readability, performance, and other ways. Otherwise I think yes using defn over defn- does cause "bugs" in a sense, where a library dev either has to keep old helper functions around etc for fear of breaking callers, or they do break some small subset of callers by updating their internals. Either way is not ideal when the callers don't have a clear signal that it's internals subject to change.

You could put internals in an impl namespace, but I think that only makes sense when you have a lot of stuff to put in there or for tests and similar. A lot of smaller helpers get tested implicitly by testing the public api though, so in many cases it's just nicer to stick the helper next to where it's used, and in those cases defn- is appropriate.

another way is to make everything implicitly (public) impl and include an .api namespace for the api

Luckily, it’s not THAT much work.

=> (clojure.core/spread [:a :b [:c]])
Syntax error (IllegalStateException) compiling clojure.core/spread at (REPL:1:1).
var: #'clojure.core/spread is not public
=> (#'clojure.core/spread [:a :b [:c]])
(:a :b :c)

Why does this work? In my mind it goes symbol -> var -> value. This passes var instead of value, but that has not be looked up as some point, right? Or is #'foo a different var than the var which foo resolves to?

after thinking, it’s probably because the meta check happens when resolving the symbol -> var, right? when you access the var directly this is obviously skipped.

I think Alex will have a better answer, but I’ll present what I know. clojure.core/spread is a symbol. When eval-ed then it is looked for in the namespace. This lookup will find a Var object, but at this point it will see that the object referenced by the Var is marked as private, and an exception will be thrown. This happened in the .resolve part of the evaluation, and before it looks at the Var. If it weren’t private, then the var returned would contain the IFn and the eval usually continues by doing that dereference. #'clojure.core/spread is a reader macro that is equivalent to (var clojure.core/spread). Evaluating this creates the var object, and looks it up in the current namespace, but importantly, it uses an internal method called .lookupVar and does not use the .resolve method. Both of these methods lookup the value of the var from the namespace, but only .resolve checks the privacy flag.

The resolveIn code is at: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L7395 While lookupVar is at: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L7475

thanks, think that sort of matches where I ended up when thinking it through. always nice 🙂 also interesting to look at the compiler code. never dived in before but this seems fairly approachable. seems there’s also a path to accessing a private var by calling (clojure.lang.Compiler/resolveIn ns sym true) . Neat!

Just don’t write production code that way 😜

Since they're all reachable, I default to the "polite agreement" solution

:)

Use (add-tap #'f).

Will try 😄

It's described here: https://clojure.org/guides/repl/enhancing_your_repl_workflow#writing-repl-friendly-programs

I assumed it had something to do with pointers. Will read it :thumbsup:

indeed it does! #' is a var, which is a pointer to a function

As a short description, when you write (add-tap f) what's happening is it's looking up the var f and fetching its current value, which is a function, and passing that value to add-tap. Then when you update the function what's happening is you're making a brand new function and assigning that value back to the var f, but this doesn't update the tap because it doesn't look up the var again, it just uses the returned value. When you pass #'f then you're passing the var itself to add-tap, which only works because vars implement the IFn interface by looking up the value in the var and calling it as a function. If that weren't a part of vars, this wouldn't work.

So every time tap calls your "function" it does a fresh lookup of the var.

what's the gist of this solution? I took a look at https://s3.amazonaws.com/athena-downloads/drivers/JDBC/SimbaAthenaJDBC-2.0.27.1000/AthenaJDBC41_2.0.27.1000.jar but found various stuff, not sure of what is the one using the technique you refer to

(maybe Athena has nothing to do and I was fooled by my googling)

I'd observed it on the redis jar @U45T93RA6

which one is it?

How about a cps transform with success and failure continuations?

Like async ring middleware

Yeah have something roughly similar just not quote sure how I feel about it

works very well with reduce based things (like transduce)