vectors or https://github.com/clojure/data.finger-tree

It isn't possible to have an immutable linked list that you can update the tail of without copying the whole list

What's the downside to the finger-tree? i.e., why not replace the core list with them?

Oh, maybe it only does constant time read of the tail, but doing an append to the tail in constant time is not possible for persistent immutable data-structures, like hiredman said

I think finger trees are constant time conj to either end

It doesn't say much and I really don't know the matter, but the implementations look quite similar: https://github.com/clojure/data.finger-tree/blob/master/src/main/clojure/clojure/data/finger_tree.clj#L224-L230

(cons  [_ b] (deep (digit meter-obj x)
                       (EmptyTree. (finger-meter meter-obj))
                       (digit meter-obj b)))
  ConjL
    (conjl [_ a] (deep (digit meter-obj a)
                       (EmptyTree. (finger-meter meter-obj))
                       (digit meter-obj x)))

(def dl (apply double-list (range 1000000)))
=> #'user/dl
(cc/quick-bench (conj dl -1))
Evaluation count : 22189998 in 6 samples of 3698333 calls.
             Execution time mean : 25.125505 ns
    Execution time std-deviation : 0.093653 ns
   Execution time lower quantile : 25.004565 ns ( 2.5%)
   Execution time upper quantile : 25.209793 ns (97.5%)
                   Overhead used : 1.901927 ns
=> nil
(cc/quick-bench (conjl dl -1))
Evaluation count : 32925162 in 6 samples of 5487527 calls.
             Execution time mean : 18.172871 ns
    Execution time std-deviation : 2.377633 ns
   Execution time lower quantile : 16.432850 ns ( 2.5%)
   Execution time upper quantile : 21.952353 ns (97.5%)
                   Overhead used : 1.901927 ns

Found 1 outliers in 6 samples (16.6667 %)
	low-severe	 1 (16.6667 %)
 Variance from outliers : 31.6430 % Variance is moderately inflated by outliers
=> nil

I believe the big O run times of finger trees are good, but their constant factors hidden by the big O notation is larger in implementations, often by a factor that makes them less attractive for actual use

Finger tree just looks like a generalized rope to me.

Awaiting I don't think has any limits. There's a limit on how many puts

I think there is only a limit on blocking takes/puts

I think 1024 pending puts per channel is the limit

If you get that issue, slow down your puts by having better back pressure handling, or use a bigger channel buffer, or use a dropping or windowed buffer to drop extra puts when consumer is too slow

since the question was about close-ch puts are not the problem. just takes. assuming that closing the channel is the only "signal".

@U0K064KQV > There’s a limit on how many puts It is conceivable on the number of data that are put on to the queue of a channel. But on the other hand, isn’t the code itself (e.g.,alts) gets somehow transformed into some anonymous function and being put into some implicit queue waiting to be executed when conditions are met? If so, there shall be some limit too.

You're right, form some reason I thought that they allowed it to be unbounded, but I checked the code, they apply the same limit of 1024 for takes as well. So you can't have more than 1024 pending puters or 1024 pending takers on the same channel

It's only when the handler is blockable, but I think that's always the case

hmm interesting. I thought it was only blocking ops but I guess not?

Not from what I understand, I always struggle a bit to read the code though. But the blocking ops like >!! and <!! are implemented with the async take! and put! just wrapped in a blocking promise. It's the async put! and take! which >! and <! eventually calls that will throw an error if you try to put or take more than 1024 in the pending takes and puts queues. When the handler is not blockable?, the put! and take! will not add it to the pending takes and puts queues in the case the channel buffer is full and no immediate takers / puters we're available, so it's kind of dropped, but that's used from offer! and poll! where that's the expected behavior. Otherwise it's added to the puts and takes queues but only if they're not at 1024 elements already. If they are, it throws an error.

And it seems it's the same for Clojure and Clojurescript

> which >! and <! eventually calls that Which part of code did you see >! get translated to put! ?

https://github.com/clojure/core.async/blob/5282c0f42cba832e262965164b154f5995954513/src/main/clojure/clojure/core/async/impl/ioc_macros.clj#L1010

But to be honest, I more relied on what it said here for that: https://clojure.org/guides/core_async_go > go just ends up calling put! eventually anyway, so there really isn’t a downside

I am guessing https://github.com/slipset/deps-deploycan be used to deploy to ossrh (I tested with a snapshot and it seemed to work) but to fulfil the release https://central.sonatype.org/publish/requirements/ I get the feeling some custom tools build program would likely be necessary. Any pointers would be super useful 🙏

https://github.com/IGJoshua/coffi

This uses build.clj for building a jar, and deps-deploy to deploy to clojars

It could be a reasonable starting place.

The other requirements here I believe could be accomplished, you just have to deploy more artifacts than just the .jar, which could most easily be done if you're calling deps deploy manually from your build.clj. The only actual challenge as far as I can tell for the requirements on central is javadocs.

Agreed, I played with using deps-deploy / pomegranate as a library in a custom tools.build program (to control for extra stuff in pom, dummy source & javadoc jars), sounds like I was on the right(ish) track with that.

I suspect maven central might not like the dummy jars if they see that's what's happening.

Is there a reason you have to publish to one of those repositories instead of clojars?

I think its ok > If, for some reason (for example, license issue or it's a Scala project), you can not provide -sources.jar or -javadoc.jar , please make fake -sources.jar or -javadoc.jar with simple README inside to pass the checking. We do not want to disable the rules because some people tend to skip it if they have an option and we want to keep the quality of the user experience as high as possible. and uh, I am doing analysis explicitly for maven (i.e I have been told it has to be maven in this case), I understand these probs are solved for clojars :)

fair enough!

To put a bit of meat on that, central is a better target for libraries to be consumed by other jvm languages (incl java) - due to the requirement otherwise for users to add clojars as a repository to their build tool (maven, gradle etc) even for transitives. That is the root of why this matters for some clojure projects. IUUC anyway.

But yea, I wouldn't recommend it if clojars will do!

Those are Clojure's equality semantics. Things are equal by value and behavior, not strongly on type

I’ve just integrated https://github.com/logfellow/logstash-logback-encoder into my logback config

https://cambium-clojure.github.io/

https://github.com/puppetlabs/structured-logging

Cambium looks interesting

is goes beyond logging, but i find https://github.com/BrunoBonacci/mulog 's approach interesting. Otherwise for logback logstash config: https://github.com/pyr/unilog is nice. It's a bit of a pain to add attribute via mdc though

I think that’s exactly it, they are serializing the lambdas for later use

can you make a java class that closes over and then invokes your passed in function?

I wonder if this library could help you get around it: https://github.com/ajoberstar/ike.cljj#converting-clojure-functions-to-java-sams

@U11BV7MTK that would be a way. Found an issue in their GitHub, Kotliners seem to have the same issue. But I wanted to choose Jobrunr over Quartz because it is way easier to use, and with that tradeoff I think I will re-evaluate

no, because implementing an interface using reify or from java using implements doesn't set the synthetic flag on the class

oh

is serializing intrinsic to the operation or a feature you can opt out of?

I think the RAM scheduler might work, but I need persistent Jobs

oh my god, are they essentially putting () -> Users.pruneUsers() into the db?

they get the bytecode for the lambda and decompile it and then do something with that

Not sure, still reading into it https://github.com/jobrunr/jobrunr/blob/ad13c4fa2e72ff7113913e682a4d4ac2f83e3b16/core/src/main/java/org/jobrunr/jobs/details/SerializedLambdaConverter.java

there are bugs like https://github.com/jobrunr/jobrunr/issues/289 about the decompiler hitting bytecodes it doesn't understand

I could always create a Java Class which executes a passed Clojure function in a Lambda, did something like that before. But something tells me, that support of any languages on the JVM besides Java is not a priority here

The extent at which static languages are willing to become dynamic always astounds me. They basically implemented a byte code based eval

java is highly dynamic, this is just a particular choice a lib/tool made

We're probably in "arguing semantics" territory. But Java has no eval, so you can't just store some code as text in a DB, and dynamically load, parse and run it.

That kinda describes clojure itself though right?

> That kinda describes clojure itself though right? > What do you mean?

the jvm quite handily dynamically loads, parses and runs code. A helpful library to do this is the Clojure jar

Ya, the JVM is pretty dynamic of a runtime, but Java isn't as dynamic as the JVM.

I mean, Clojure goes through crazy extent to be dynamic as well, all it has to do on top of the JVM, bundling a compiler, including a bytecode generator ASM, hooking up a nightmarish combination of class-loaders and all that. Being dynamic in itself is difficult. But when the effort is centralized in the language constructs, its better, because you end up with a better dynamic implementation. In Java, I see a lot of code-bases doing their own ad-hoc implementation of dynamism that is missing from standard Java. I think there is a famous quote about this... Found it, it's Greenspun's tenth rule: > Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. This Java lib seems to be an example of this to me.

> Other programming languages, while claiming to be simpler, require programmers to reinvent in a haphazard way a significant amount of needed functionality that is present in Lisp as a standard, time-proven base.

> It can also be interpreted as a satiric critique of systems that include complex, highly configurable sub-systems.[3] Rather than including a custom interpreter for some domain-specific language, Greenspun's rule suggests using a widely accepted, fully featured language like Lisp.

Interesting read: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

you know guy steele worked on the java language spec and famously said something like "we managed to drag c++ programmers halfway to lisp"

I encounter that a lot in practice. Because teams are always hesitant if I bring up Clojure. It's too dynamic, how can you understand anything of what the code is doing, there's no compile error, how do you know what has broken. But then, in 90% of all legitimate production Java enterprise app, you'll start to find Class.forName("..."), and other things that are to bring in more runtime dynamism/configuration to the system, which is similarly just as difficult to understand anything of what the code is doing and similarly bypasses all compiler errors as well. The downside is that, you're under the false impression this is not the case, and you've put in place no mitigating processes or safe-guards, unlike say in Clojure, where you accept the dynamism from the start, recognize its utility, and learned patterns and mechanisms to tame it and make it an asset.

The same is true for meta-programming as well, where you'll find pre-processors, code gen, and all that...

I avoided the library in the end and used quartz instead. If really had to, I probably had tried to wrap the functionality in my own Java class

yeah I think I'll probably just end up using the REST API for this. Really unfortunate design decision 😕

this post has lot of information on how to set things https://ericnormand.me/guide/clojure-jvm#java-options

You typically don't need to worry about it much. The default xmx is 1/4 of total ram so maybe decrease that a bit

Setting the max ram is a reasonably good idea on the JVM because the way it works is that it will take up as much memory as you give it in a sufficiently long-lived process, even if your program doesn't use much ram.

what you can do is set a ram value that's higher than what you'll need, wait for it to do a long garbage collection cycle, see how much memory it uses after that, and then set your max heap size to that + a little wiggle room.

-XX:-OmitStackTraceInFastThrow <-- set this only in dev

sometimes for NullPointer and ClassCast Exceptions the jvm throws away the stack trace. that option preserves the stacktrace

for clojure deps would that look like this? :jvm-opts ["-XX:-OmitStackTraceInFastThrow"]

yes, in a :dev alias or similar

Although for myself I usually just put it in the cider global options for my dir-locals in emacs

And then what you using to "see how much memory" the jvm is using and that a garbage collection has run?

learn how to use JFR

Java Flight Recorder. It is an efficient ring buffer deeply hooked into the JVM

Data captured by JFR can be processed by tools, including "Java Mission Control" a nice free GUI

it will show you memory, gc, locks, IO, all sorts of stuff

you can also trigger a JVM to record a JFR session from outside a running JVM

awesome, i'll look into it.

jcmd is the swiss army knife

type jcmd $pid_of_some_jvm and it will show you a bunch of diagnostic things you can do to the jvm

show a class histogram, start / stop / configure JFR, get the VM settings, dump thread stacks, etc.

The error might be misleading, but \uFFFF syntax literal stops there, it doesn't support to have 5 entries, because it is actualy the literal for Java Char types, which are unsigned 16 bit integers. In fact, its better to think of Char as uint16 really.

So unicode codepoints above that don't fit a Char, so they'll be represented in UTF16 style as two chars in a char array. Unfortunately, there's no good literal support for those. The easier way is this:

(Character/toChars 0x30EDD)

But, the str function does not convert a char-array into its unicode representation as a string. It prints the array memory location instead. So you'll need to first convert the char-array into a string representation.

(str "我们去西安吃" (String. (Character/toChars 0x30EDD)) (String. (Character/toChars 0x30EDD)) "面")
"我们去西安吃𰻝𰻝面"

But you can make yourself a super simple util function, and it'll be super nice again like so:

(defn u
  [codepoint]
  (String. (Character/toChars codepoint)))

(str "我们去西安吃" (u 0x30EDD) (u 0x30EDD) "面")