I just used it this week (from a tools.deps project), and it works. It could probably use a bit of a style revamp, though.

:marginalia {:deps{marginalia/marginalia {:mvn/version "0.9.1"}}
               :main-opts ["-m" "marginalia.main" "-d" "doc/commented-code"
                           "-D" "Your project's description"]}

that alias does the trick

Sometimes in Clojure "unmaintained" is better described as "stable, working, without the need for further changes". Note that I say "sometimes", not "always".

I'm specifically running into the bug which this unmerged PR from 2017 fixes https://github.com/gdeer81/marginalia/pull/175 And not wild about the prospect of forking the project for a four-token change

You could ask in #CE1A21MPF if someone might be willing to take that project under their maintenance in the clj-commons group of projects.

I've forked it, made my small fix, and deployed to Clojars for now. Depending on adoption at work this could either be an abortive effort or it could turn into me actually doing some maintenance on it. If any future searchers of this Slack also need fixes to be deployed, feel free to ping me or open a PR to https://github.com/tsmacdonald/marginalia

I usually check the Network view for projects that haven't seen much recent maintenance. Not sure if you looked, but there is someone who did a bit of work on the project and even apparently released a "1.0" version. I haven't looked in any depth at what is there, but I often find useful contributions worth adopting/merging that have built up on projects like this that aren't too active.

@U30H25RT6 Had taken it over from @U050WRF8X and was actively maintaining it for quite a while but when I updated the Generating Documentation page on http://clojure-doc.org last week I noticed it hadn't had any updates for a while... and I don't know how active Gary has been here this year?

@UJLF48QJC If you think you might end up doing some maintenance on it but want some support before you make any commitments, we could talk about transferring Marginalia into clj-commons where at least we could rotate through maintainers going forward?

I've lost track of it over the years, but if people find it useful still then I would love to see it go into clj-commons or some such

Hey Sean and Fogus (hello, thanks for a lovely tool!). We're definitely going to use Marginalia at work (Metabase), so I feel good about doing some maintenance on it (no fun working on software you don't use…). I can definitely help with modernizing the tests (and setting up CI), synthesizing the various improved forks and PRs, making it work with deps.edn and not just project.clj, straightforward bugs, fielding new issues/PRs, etc. So, sounds like clj-commons is a good fit for that (and it's definitely appealing that if I run out of gas somebody else could take over and it won't just be Another Random Fork) Should I open a new issue on clj-commons/meta? I'll also open an issue on the main repo to give Gary a chance to weigh in. He hasn't posted on this Slack since 2019 or done anything public on Github this year, but maybe he's still lurking

Yes, please open a meta issue. I'll def. vote for it to moved. I'll see if I can find any alternative contact deets for Gary....

https://github.com/clj-commons/meta/issues/76 Thanks, everyone!

a good way to do this is to pass the timeout channels as arguments through the fns in the program

Yes, I have done it this way, but found confusing this throws an error.

This looks to me like timeout has some type hints on it that your redef doesn't match.

Try redefining fixture-timeout like so

(defn fixture-timeout [^long _t]
  (timers/timeout 10))

Cool I will try that, I would never come up with that! Thanks

I was looking at this, and I see clojure.lang.IFn$LO which sounds like "IFn, for Long->Object" to me. I know that there's explicit overrides for some code which permit taking primitive arguments that get compiled differently, so your deftest is compiled against that specific variant which takes a primitive long and returns an object, so when you redefine it using with-redefs the type no longer lines up with what the code was compiled against.

I believe the code has special variants for doubles and longs for arguments and return types up to 8 arguments?

I could be wrong about how many arguments it goes out to, but I know it only special cases primitives for longs and doubles.

You were totaly right, it works now! Next time I will be able to read IFn$LO 😄

Glad I could help!

Yep, exactly like described here: https://stuartsierra.com/2015/04/26/clojure-donts-concat

I suspect the string never exists. This is turning a large collection built with (lazy) concats into a string

We have some concats in the relevant namespace (which yup, I hate). Hopefully that will be it! > I suspect the string never exists. This is turning a large collection built with (lazy) concats into a string I'll check that out as well :thinking_face:

Quick check is wrap them in an into [] to drop the function invocation

Not sure about the exact context here, but maybe ropes would be helpful for your usecase? https://github.com/IGJoshua/ropes

The idea behind ropes is constant time concatenation of strings and since they implement the CharSequence interface they can be used for a lot of things strings can be, including regex search targets

But perhaps this wouldn't resolve the particular issue in this case if you've got so many concats as to make stack overflows.

If you want a no-dependency solution to this, you could consider using vector-of with :char and use into instead of concat.

That or cgrand/xforms' string reducing functions.

@U11BV7MTK, the string is the result of an http GET request by clj-http/client, do those never exist? Plus, clojure's print works (instantaneous). Only on inspection it overflows, so it's some cider/emacs issue

Something is building up a lazy sequence based on a bunch of concats. If that eventually ends up as a string it doesn’t seem to be making it to that point. Totally possible that it is cider doing this for inspection

This is the context https://github.com/clojure-emacs/cider/issues/3511 I'm looking it atm. I cannot reproduce it. (-> (clj-http.client/get "") :body)) is a String and I can inspect it. I can also run a related deftest with low Xmx and it doesn't SO.

I don’t believe stack overflow is related to memory in the traditional sense

yeah, because otherwise (if I don't inspect it), it works perfectly as a string

How can I set the cider xmx? I'll try to test it with higher xmx

I don't think that's what Dan meant. You can get SO with any amount of memory. The two things are hardly related.

You can set e.g. "-XX:MaxJavaStackTraceDepth=1000000" which is what I always do for misc reasons. Those are called JVM system properties

how can I increase cider process' stack size?

It’s all the same jvm. Just set your own processes memory constraints. But this is the number of function calls, not the size of stuff. And in fact I suspect you could trigger this on an empty sequence that concats a ton of empty sequences together

...I also always set "-Xss6144k" for a similar reason

@U45T93RA6 At the risk of stating the obvious, when reproducing this you should use the same exact dependencies that @U060FHA3K28 has. Not just the dev toolchain, but all dependencies. Mentioning only because I don't see e.g. clj-http version in the linked issue.

[clj-http "3.12.3"]

Can you trigger the issue with only that library on the classpath and nothing else (apart from CLJ and Lein stuff and anything else directly relevant to the issue)?

linked it there. hold on, i'll check with only that library

yep, still SO

println in the repl is instantaneous and has no issues with the string, by the way

(loop [i 0
       acc "x"]
    (if (< i 566607)
      (recur (+ 1 i) (concat acc "x"))
      acc))

same SO error

But this one is in the repl, not only on inspection

Ran the snippet in lein repl:

Error printing return value (StackOverflowError) at clojure.lang.RT/seq (RT.java:535).

if I pass it into println , also SO error

As far as the original issue is concerned, the conversation continues over here https://github.com/clojure-emacs/cider/issues/3511#issuecomment-1760046563 FYI I'll unsubscribe from this thread.

So it's concat's fault. Is cider's source available somewhere within emacs, if I have it installed?