Fork me on GitHub

are there any libraries that offer the same bitwise ops as clojure.core without extending the result type?


What do you mean by extending? If you mean sign extending, clojure has unsigned-bit-shift-right, which should be all you need


sorry, extending as in all the results are longs. I'm trying to do something with byte arrays and currently having to do the 2's complement conversion back to bytes myself, which is no big deal, but also seemed like the sort of thing someone else might've already done.



Muhammad Hamza Chippa09:12:48

I have vector of maps something like this (def data [{:19960102 ["1996/01/02" 13 13 12.375]} {:19960103 ["1996/01/03" 12.3334 12.6666 11.9166]} {:19960104 ["1996/01/04" 11.875 11.9584 10.9584]} {:19960105 ["1996/01/05" 11.0416 11.25 10.7916]} {:19960108 ["1996/01/08" 11.2084 11.25 11]} {:19960109 ["1996/01/09" 11.0416 11.0834 9.6666]}) and dates in another vector like ["19960109" "19960104"] how can I iterate through dates and access it from the data?


First of all,, so you need to choose another construct to store your "dates" in (I'm going to assume they're strings) Second of all, that data structure is not a good fit for your problem. You have a vector of single entry maps which defeats the purpose of having the maps. If the keys in data are unique, run apply merge on data to get a single map and then run something like (select-keys data ["19960109" "19960104"]) If the keys are not unique, try to formulate a more accurate problem statement and ask again. edit: if the keys are not unique, you could probably overcome the problem with apply merge-with concat but I'm not sure if that's an option for you


Why use a list for your (def data)? It can just as well be a map if I understand correctly. And the keys to that map should be the strings in your dates vector. Then the iteration is simple, something like:

(map #(get data %) dates)


Right, yeah, if you want just the values or if you care about order then you need to do it with map like @U01M742UT8F suggested, instead of select-keys

Muhammad Hamza Chippa10:12:28

@UEQPKG7HQ following you valuable advice I converted this absurd data into the maps only something like this {:19960102 ["1996/01/02" 13 13 12.375] :19960103 ["1996/01/03" 12.3334 12.6666 11.9166] :19960104 ["1996/01/04" 11.875 11.9584 10.9584] :19960105 ["1996/01/05" 11.0416 11.25 10.7916]} (contains data for every date from 1996 to 2021) now I have a vector which contains some dates [1996/11/29 1997/11/28 .. 2021/11/28] so I wanted to access the data for every date in dates vector. maybe now I can do it


Hey folks. Is there any prior art I should investigate that might help in the task of building high-level operators for transforming trees (and in turn, building pipelines of tree transformers). I’m aware of specter and malli, and enlive. Is there anything else I can look at for inspiration? There’s not as much written about this subject as I’d have expected. Or at least I can’t find it.


Zippers often very helpful for such operations

👍 1

Is there a counterside to *1 that is bound to the most recent value read, rather than printed? Something like a REPL input history..


No but that’s an interesting idea. Are you typing into your repl and want to reclaim that form?


Well, not typing into the repl directly, just evaling forms through my editor and would like to see exactly what was read.


this was my primary motivation for migrating away from deep editor tooling, and switching to a flow where my code gets pasted into a repl window (in vim it's clj running inside a terminal emulator inside a buffer)


Funny, I feel like this is one of the main things that made me fall in love with Clojure after years of mostly sticking to Python. I always tried to get Python to play nicely with a side-by-side REPL of its own, but found the experience always a bit lacking. When I first got vim-fireplace up and running for Clojure, it was a very liberating experience. I do suppose that being a lisp makes it much easier to manage and reason about scope, but I think the deep editor tooling is a bigger part of it. Do you use


I use the emulator built into nvim


oh wait - yeah I use neoterm (which wraps that)


I did some edits to make it work with clj (supports lein out of the box)


YMMV but I find that clojure.repl (dir, doc, find-doc, apropos) gives me most of what I need - and importantly for me it means I can offer generic assistance to others without making assumptions about what tooling they use


interesting. The reader is fully exposed to you though. (read-string "(+ 1 1)") will return what the reader read


so you can throw quotes around whatever you have and read it. In emacs when you do that it will automatically smart quote any quotes in the form itself


Nice, read-string pretty much does the job.


Would you recommend this book? Why or why not? For search: The book is called Design Patterns: Elements of Reusable Object-Oriented Software.

Alex Miller (Clojure team)19:12:31

Mostly not. You can mostly replace that with “use functions” in Clojure


That's what I thought, but I just wanted confirmation from someone who knew more.

Alex Miller (Clojure team)19:12:08

Probably the most valuable thing about it is that it introduced a lot of vocabulary people still use (decorators, flyweights, etc)

👍 2
Alex Miller (Clojure team)19:12:37

I took a senior project class in college with Ralph Johnson and learned a lot from him. Certainly I found the book and process valuable in my formative Java years


Not for clojure, but if you're ever forced to interact with legacy codebases (that use OOP) it might give some insight/perspective into why they might've done stuff that way?


I think it's useful from the point of view of helping you spot patterns and abstractions in code in general but it is heavily OO focused. Of the various OO patterns books, I tend to guide people to Kerievsky's "Refactoring to Patterns" and, perhaps, Fowler's "Patterns of Enterprise Application Architecture". Some of the "patterns" literature is interesting, in and of itself, but as Alex says, in Clojure most of the patterns break down to "use (higher-order) functions".


The stack of books next to my desk 😁


(the 12 CDs to the left are all albums by The Fall 🙂 )


Mildy useful fact: Refactoring got a 2nd edition in 2018 or so, with the examples in Javascript.


For the subject the book covers, it is an excellent book. The specific design patterns covered are not directly applicable to Clojure. All the patterns are pretty much implemented by the humble Clojure function


You can replace majority of OOP patterns with a few guidelines: “Use pure functions” “Use values/data” “1 data structure and 100 functions is better than 10 data structures with 10 functions each”

Drew Verlee05:12:19

@U01KQ9EGU79 I did some posts on these patterns a couple years back. I put more time into the earlier ones. my experience was that the ROI wasn't there to memorize the idea's as they were largely a natural part of clojure. Though I often found it hard to read into what they were suggesting with the language barrier (java or c++).

👀 1

Wow! Awesome resource! @U0DJ4T5U1

Drew Verlee06:12:26

I wouldnt stretch to awesome here, there are a lot of better minds on this chat then me who can weigh in. I just wouldn't get into the weeds of reading design books. The authors tend to over state their cases.

Drew Verlee06:12:33

Martin kleepmens book on designing data intensive applications, my discrete math books, 3 blue 1 brown, are some good resources...

Drew Verlee06:12:04

the standford class on algorithms, the one on discrete optimization (though its brutal)


Hi, if I may, I found this article some time ago. It helped me a lot! When I started clojure, I had the feeling to understand what I read, but, when I was starting to design, I was constantly thinking to traditional design pattern. This article help me to understand how not to need them! I'm not sure it's 100% accurate, but the spirit is there:

💯 1
👀 1

@U018QDQGZ9Q Excellent resource as well! Thank you for sharing.

Drew Verlee03:12:36

West, i read the same blog post. I didn't really agree with a lot of their conclusions. But its been a while, i might not agree with my past self.


but, what I find useful is the mechanism. How to un-build what we learned with design patterns. And it is illustrated in many examples