user=> (meta (first (:arglists (meta #'foo)))) {:tag java.lang.Number} user=> (meta (first (first (:arglists (meta #'foo))))) {:tag Integer} user=>

(if I understand the question correctly)

(defn foo [^Integer a] a)
(meta (ffirst (:arglists (meta #'foo))))
;;=> {:tag Integer}

And:

(meta (first (:arglists (meta #'foo))))

For the return if you care

@U0K064KQV not reading previous replies, huh? 🙂

(defn foo ^Long [^Integer a] (long a))
(meta (ffirst (:arglists (meta #'foo))))
;;=> {:tag Integer}
(meta (first (:arglists (meta #'foo))))
;;=> {:tag java.lang.Long}

nope hadn't

Great, thanks!!

Those work in Joker, too. I’m looking into enhancing Joker documentation generation to include those tags in the docs.

Here’s the result of that work: https://burleyarch.com/joker/docs/amd64-darwin/joker.core.html#_functions This reflects a merge of a pending PR for Joker, plus pending further changes waiting for that first PR to go in, to my own fork/branch. The main change I made, in relation to the discussion on this thread, was to produce “usage” examples that look like this:

^Number (* ^Number x ^Number y)

Thanks again for the help!

That sounds like you want your listener on the queue itself. You can add watches to ref types: https://clojuredocs.org/clojure.core/add-watch. That help?

I think so. Let me read this. Thanks 🙂

Not abandoned

looks like nothing happening...

What else is needed?

PRs and issues to be worked on. People does contribute but nothing is merged

It's a year old now, but this was from the author after a similar question: https://github.com/ptaoussanis/timbre/issues/279#issuecomment-467422874

So at a guess, it's not considered abandoned by the author but hasn't had the time to dedicate to it for a while.

But there doesn't seem to be a huge amount of activity. Having said that, reading through some of the issues leads me to think that the core functionality itself is actually pretty solid. That's certainly my experience of using timbre over the last few months having switched from a slf4j+logback+tools.logging setup.

The last update includes comments on issues. Not the same thing

The page is not publicly available.

ugh, fixed, thanks!

You will probably get a better answer and leave something easily searchable if you open an issue in the transit-clj repo. I couldn't find anything that mentions metadata on keys.

it also works in transit-cljs so I think it’s unintended

will open an issue

If something works somewhere, it doesn't mean that it should work. :)

clojure.set is a great example. Functions from there will work on a great variety of collection types combinations. But they're intended to be used only with sets.

well I believe transit is supposed to be able to encode clojure data structures

BTW it seems that it's not just a metadata issue. It's an issue of using a symbol with metadata. Try using a map with metadata as a key, for example. Judging by the code, it should work just fine.

what do you mean with metadata as the key?

> a map with metadata as a key

hmm, can metadata be a key? Doesn’t it have to be on something?

A map with metadata. :)

oh sure, that works

we are using that

So it's a problem with just symbols with metadata used as keys then. A bit narrower.

oh, you mean a map as key in a map… let me try

Ooh, interesting - I can write it but it doesn't read it back.

you need to pass the meta transform function

For writer - yes, I do that. But for reader?

Ah, my bad - I was writing to the same buffer multiple times. It is read back, with the metadata.

yep

seems like transit doesn’t use a cmap for the symbol with meta case

if I add a second key {} to the map it works

(write w {(with-meta 'key {:foo 'bar}) 'val {} 'val2})

https://github.com/cognitect/transit-clj/issues/47

thanks for your help looking into this!

Transit isn't meant to encode Clojure data though. It is meant to encode EDN. And EDN doesn't know metadata.

Transit doesn't have to do anything with EDN. Those are completely different formats.

But to be fair, it also doesn't have to do anything with Clojure - there are many implementations for different languages.

transit-clj added support for metadata in https://github.com/cognitect/transit-clj/commit/a823f3b418e535232fa48f0b73ac8e32c4818863 and I believe people are using it to encode Clojure data. I don’t get your point.

It was added for some ad-hoc case. There's no metadata in the spec, there's no metadata support in transit-python, for example.

yes, it was added for Clojure metadata in transit-clj and it’s using a tagged array as a base type.

My point is that Transit is not about Clojure, that's all.

*sinking

IMO this belongs in #off-topic, not #clojure

Agree. I can't move it though.

So on that plot, what's on the Y axis?

And it seems that there's no way to get my hands on the original data. Which already makes me want to throw that "study" into a garbage bin.

it requires higher CPU utilization (which drives up hiring and operating costs) - what does this even mean?

Operating cost - well, you now have to pay more for electricity. Hiring cost - uhm... well, maybe your hiring software is written in Clojure, and then it still makes you pay more for electricity. :)

I am more confused by the higher CPU utilization bit.

And how it affects the two costs.

Well, I'd argue that Clojure should indeed have higher CPU utilization than Java simply because it's mostly an abstraction on top of it. And regarding how affects - the electricity thing is true. Anything else - assuming proper maintenance schedule, no idea. Nothing else should really change.

Hiring costs refers to steep learning curve.

Y-axis seems to be number of job ads.

> Hiring costs refers to steep learning curve Ah, right. The phrasing is a bit off. And I'd argue that the learning curve is much less steep than with Java or even Python. > Y-axis seems to be number of job ads. It displays values between 0 and 1. And the current job number is in the hundreds. So it should be something else.

These might be mere perceptions or tentative, and wrong, explanations. Y-axis could be normalised.

The very first plot has "percentage of all job posts" as its Y axis. So that's probably that. And if that's indeed the case, then they just measured relative popularity on a single platform. Good job 👏 throws the study into the garbage bin

garbage article

The chart also exaggerates the decline by not using an absolute scale (0 to 100). Some tech is just not mainstream and it's likely never going to be. Doesn't mean you can't or shouldn't do it. The ship is certainly not "sinking" where I work and I think it is a mischaracterization to say that it is in general.

Are there any published metrics illustrating this? It'd be good to share them with the engineering teams where I work. It sounds like they're likely internal to Cognitect though, right?

nothing I can easily share

:thumbsup:

unique ips downloading clojure artifact over the last year

50% increase

Thanks!

It's going up where I work!

do you mean https://github.com/clojure/tools.deps.alpha/?

This: https://github.com/clojure/homebrew-tools/tree/master/Formula

which ultimately calls "

etc..

Got it, sort of. Are you looking for changes in clojure between those jars or the diff in tools.deps.alpha?

No easy answer in either case, but that'll help me help you get your answer.

Sure, I appreciate it. What I'm trying to do is to understand what has changed between 507 and the latest 536 - only to understand whether it's worthwhile to open a "outdated" ticket on Arch to request an update.

The latest on arch is 1.10.1-507.

I understand that 507 and 536 is the number of commits

but from where? 🙂

Exactly!

🙂

In cognitect-labs repos that's based on something documented in the repo, but I don't see anything the clojure repo.

Still looking

https://github.com/clojure/brew-install/blob/1.10.1/CHANGELOG.md

Ah!

Thanks @U064X3EF3

also often relevant: https://github.com/clojure/tools.deps.alpha/blob/master/CHANGELOG.md

w000hoooo!

thanks alex 🙂

@U11EL3P9U that give you the detail you need?

absolutely

if there's someplace you looked that that link could have existed, let me know so I can update

@U064X3EF3 part of the challenge is tying the clojure version to the tools.deps.alpha version

or vice versa, rather

In the arch repo, it downloads from here source=(""

@U064X3EF3 maybe on https://clojure.org/guides/getting_started?

so I went a-hunting to try and find out where I could find out information on that

I naturally googled clojure tools

Heh, that's interesting how the Linux script has versioning that depends on the Brew script but at the same time it itself doesn't depends on Brew at all.

well, it's just all released together, windows too

but that ended up at tools.deps.alpha, but with the changelog at a different version number

so I thought that couldn't be it

gotcha, I'll see if I can add some links in a few more places

: 0.8.677 != 1.10.1.536

So then I went to the clojure github

the brew-install repo is poorly named but I've been too lazy to change it and fix all the build automation

but that totally didn't fit

so I got lost where to find out

thx, that helps

The second face of "naming is hard" - you also have to change all the references if you change the name.

but now I know where it links the homebrew install script (called clojure-tools!) (references (indirectly) to clojure.tools

(not that I use homebrew - I'm 100% arch :))

I can raise an outdated on arch now, since 0.8.677 (which is in 1.10.1.536) contains some fixes

links added

(into {} (map-indexed vector [:a :b :c]))
=> {0 :a, 1 :b, 2 :c}

You could use (zipmap (range) [:a :b :c])

user=> (zipmap (range) [:a :b :c])
{0 :a, 1 :b, 2 :c}

Oh, probably zipmap was what I was looking for

Thank you!

map-indexed with into also works but probably zipmap is better.

FWIW I meant to use a transform above like this:

(into {} (map-indexed vector) [:a :b :c])

So I can just extend Iterable, right?

correct

Great! Thank you very much

There are example implementations of new data types that do this I could point you at the source code of, but there is nothing I am aware of that says: "to implement a new kind of map, here are the 11 interfaces you should implement"

@U0CMVHBL2 something is better than nothing. Could you please point out to example

As a couple of example, there are these libraries: https://github.com/clojure/data.priority-map implements a new kind of map, and https://github.com/clojure/core.rrb-vector implements a new kind of vector. The code for the first is significantly shorter.

for a macro to use your datatype, you'd need a datareader (and the macro would use the data that the reader emits) - otherwise you'd just use a macro to emit the code which uses your data structure

Note: Depending on what you want to do, implementing a new data type may be more work than you need to go to.

Not many Clojure developers do that.

there is of course defrecord which just does the right thing for the use case of "a hash map with behaviors"

This just a learning thing. I want to work out Sedgewick’s “Algorithms” book, but with Clojure

Here is a toy bag/multiset implementation I did while trying to learn the exact same thing as you are. https://gist.github.com/Hindol/c92a768f7f784379dc8bcd546a60fa42

There is a nice little scaffold generator linked in the comments (not mine).

Great! Thanks @UJRDALZA5

I've got an example project that makes Java from Clojure. There's a relevant file here https://github.com/markbastian/clojure-makes-java/blob/master/src/interop/core.clj. Basically, reify makes it pretty trivial to implement interfaces on the fly.

I want to implement stack, queue, binary tree, 2-3 tree, red-black tree and a lot of other crazy things. And this is just a learning exercise, so I want to do it low level and all by myself (no libraries)

oh -- that's good to know your use case

https://github.com/clojure/data.avl/blob/master/src/main/clojure/clojure/data/avl.clj#L175

look at something like that

working from a traditional algorithms book where mutability is assumed this is going to be fun in clj 🙂

that one is not simple -- it uses a lot of interfaces 🙂

Yes, a lot of fun 😂

Thanks a lot @U050ECB92

This file contains a mutable implementation of Tarjan's algorithm for finding strongly connected components in a graph, using mutability for trying to maximize efficiency. At least the primary result of the components is returned as an immutable Clojure vector, but it also returns some intermediate results as mutable Java arrays. Even the original pseudocode on this one wasn't easy to follow, since it creates explicit stacks to avoid recursion in the function calls: https://github.com/jafingerhut/cljol/blob/master/src/clj/cljol/ubergraph_extras.clj#L460-L674

Good to know! For pure curiosity, any known history as to why it evolved to have both?

separate design decisions at different times, I don't know the details

Alright, thanks!

user=> (set/rename-keys m (zipmap (keys m) (map #(keyword (name %)) (keys m))))
{:a "a"}

user=> m
#:user{:a "a"}

😞

if you are traversing the map, just traverse it once

meh

that works too

traversing it twice to build the map to pass rename-keys, only to have rename keys traverse it again

@U0NCTKEV8 what would traversing once look like? So I can compare with what @bfabry shared.

in the world I work in that will never ever matter, but yes it is slower than

(into {} (map (fn [[k v]] [(keyword (name k)) v]) m))

I’m working with a couple million maps. So the faster one makes sense :P

and even that's slower than

(into {} (map (fn [[k v]] [(keyword (name k)) v])) m)

better even to not have to remove the namespace

or for example, if you are serving data as json do the namespace removal as part of the json encoding since that has to traverse the map anyway

I’m considering that doing vals could be sufficient if I approach this problem the right way. The output is CSV. But I’m looking for a first pass atm and my CSV function works with maps for now.

writing csvs you shouldn't have to care about the keys

if you are already aware of the bounds of your problem ignore me, but fwiw CSV is actually a way more complicated spec than you'd think and if you have to interface with something I'd use data.csv

For context. I’ve taken messy data. Performed transforms on them with Meander applying namespaced keywords. Transact them to datahike because it’s too much data for memory. Then use datahike for joining data together. Now I just want to do final cleanups before export.

you take the first map, write the columns out from there, and then rest just write the values in the same order without having to do anything to the keys

so for any N of maps, the column munging should happen once

Hmm I guess I’m doing double steps here.

(defn generate-csv
  [data]
  (let [columns (-> data first keys)
        headers (map name columns)
        rows (map vals data)
        writer (.StringWriter.)]
    (csv/write-csv writer (cons headers rows))
    (.toString writer)))

But I’m okay with this for now. My concern was that maps are not ordered? Or is this just sets?

maps are not ordered

So I can’t guarantee that if I do a vals on it. The result with line up with a pre-defined “header list” I create.

but it is very likely (not guaranteed) that maps that contain the same keys will be iterated in the same order

I mean my generate CSV function kind of depends on that behaviour of it being consistent.

store the first set of keys, do (map (fn [row] (map #(% row) header-keys)) data) instead

you can just map row

ah, yes

@bfabry that looks more like going from CSV to maps?

nope. given a list of keys called header-keys and a list of maps called data that returns a list of lists with the values of data in the order of header-keys

Hmm must be time for bed for me then haha.

it's clearer broken down

(map (fn [map-row]
  (map #(get map-row %) header-keys))

well, reformatted

and missing the last parameter :face_with_rolling_eyes: but hopefully you get me

I’m pretty tired. I will have to throw some sample data at it in the repl.

So simple and I don’t get it. Definitely tired haha.

I’m not convinced that code actually works lol

Oh I see. It’s a seq of maps being passed in.

So you destructure a seq of maps using a vector of header keys which ensures they are placed in the right order.

correct

(let [header-keys (keys (first [m]))]
  (map (fn [map-row]
  (map #(get map-row %) header-keys)) [m]))
(("a"))

replace [m] with data

(-> (clojure.walk/stringify-keys m)
      (clojure.walk/keywordize-keys))

@kwladyka magic