Re: [ANN] com.dean.interval-tree
Very cool, thanks for sharing! This looks like it would be perfect for Advent of Code puzzles. Out of curiosity, what are real-life problems that benefit from the use of an interval map? On Tue, Apr 6, 2021 at 2:04 PM danle...@gmail.com wrote: > > > https://github.com/dco-dev/interval-tree > > I’m pleased to announce that my company has released our first modest > contribution back to the Clojure community. > > In brief, this library provides “interval map”, “interval set”, > “ordered-set”, and “ordered-map” collections, but more fundamentally we use > this as a library for building efficient, ordered collection types on an > extensible weight-balanced tree. > > This code has been in production for a few years now, however it is still > young in terms of a publicly released data-structure library. Comments and > suggestions are, of course, very much welcome! > > Best, > > Dan Lentz > Dean & Company > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clojure/f5b4a13c-e5df-4fcc-957c-aaebeb715fabn%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/CAG4Uonks8ZCu_zbtHAKKiCzYdhg9P3gT-YLG7JWEHh%2B%2BXxHO9w%40mail.gmail.com.
Re: Releasing scope-capture, a library for easing REPL-based debugging
This looks great, thanks for publishing this, Val! On Sun, Oct 8, 2017 at 9:09 AM, Val Waeselynckwrote: > Hi, I'm happy to release a tiny Clojure/Script library called scope-capture. > > https://github.com/alvalval/scope-capture > > Loosely speaking, scope-capture makes it trivial to reproduce from the REPL > the context of a piece of code after it executed. > > It was inspired by Stuart Halloway's article REPL Debugging: no stacktrace > required. Thanks Stu! > > I've been using it professionally for a few weeks now, and it's been a > significant productivity boost for me. In my view the benefits are: > > easier debugging > making Clojure code / projects more accessible to beginners > easier ad-hoc exploration > > Please let me know what you think! > > Valentin Waeselynck > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: "GC overhead limit exceeded": Deceptive message?
For background on "holding onto the head of a sequence" type problems, see https://stuartsierra.com/2015/04/26/clojure-donts-concat and https://stackoverflow.com/questions/15994316/clojure-head-retention On Tue, Aug 8, 2017 at 6:19 PM, Nathan Smutzwrote: > The one thing I'm aware of holding on to is a filtered file-seq: > (def the-files (filter #(s/ends-with? (.getName %) ".xml" ) (rest (file-seq > (io/file dw-path) > There are 7,000+ files; but I'm assuming the elements there are just > file-references and shouldn't take much space. > > The rest of the process is a transducer sequence: > (def requirement-seq (sequence > (comp >(map xml-zip-from-file) >(remove degree-complete?) >(map student-and-requirements)) > the-files)) > > Those functions are admittedly space inefficient (lots of work with > zippers); but are pure. What comes out the other end is a sequence of > Clojure maps. Could holding on to the file references prevent all that > processing effluvia from being collected? > > The original files add up to 1.3 gigs altogether. I'd expect the gleaned > data to be significantly smaller; but I'd better check into how close that's > getting to the default heap-size. > > Best, > Nathan > > On Tuesday, August 8, 2017 at 1:20:21 AM UTC-7, Peter Hull wrote: >> >> >> On Tuesday, 8 August 2017 06:20:56 UTC+1, Nathan Smutz wrote: >>> >>> Does this message sometimes present because the non-garbage data is >>> getting too big? >> >> Yes, it's when most of your heap is non-garbage, so the GC has to keep >> running but doesn't succeed in freeing much memory each time. >> See >> https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/memleaks002.html >> >> You can increases the heap but that might only defer the problem. >> >> As you process all your files, are you holding on to references to objects >> that you don't need any more? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: potential bug with pr-str+print
Looks like a bug to me. ClojureScript doesn't seem to have this problem. On Tue, May 2, 2017 at 7:50 AM, Jenny Finkelwrote: > Hello! > > I think I may have found a bug in clojure. When pr-str is called from within > print, it doesn't produce a read-string-able string. Here is a simple > example: > > user> (let [xs (doall (map #(pr-str %) ["a" "b"]))] (print xs)) > ("a" "b") > user> (let [xs (map #(pr-str %) ["a" "b"])] (print xs)) > (a b) > > The reason is that print binds *print-readably* to nil, whereas pr-str does > not bind it to true, even though I believe it should. If this really is a > bug, I'd be happy to submit a patch for it. > > Thanks, Jenny > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Diffing clojure data structures faster
Great work, Dan! I think adding a way to diff standard clojure data structures efficiently would open up very interesting possibilities. Two examples: - log changes in reagent's state-atom (clojurescript) - build a simple durable "database" atom (persistent across process restarts) using a diff-based write-ahead log (clojure) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Multiple key-value pairs in assoc-in (old issue)
Just this week I have wished for an extended version of `assoc-in` more than once. The reason is convenience, e.g. in the context of a ring middleware: (assoc-in response [:headers "Location"] "/homepage" [:session :user-id] user-id) Extending `assoc-in` would also achieve parity with `assoc`, which does accept multiple kv pairs. On Wed, Aug 17, 2016 at 8:59 PM, Timothy Baldridgewrote: > When I see mailing list posts like this I like to play the devil's advocate > a bit (at least in my own mind) and try to find problems with including a > given patch in Clojure. > > A few things to consider: > 1) There are really three answers to patches: "yes", "no" and "not now". > That is to say, because a patch hasn't been accepted doesn't mean it's bad, > it just means that it may not be the right time for the patch or perhaps > there are other tickets more pressing for the version of Clojure under > development. So don't let the time since patch creation disappoint you, it > doesn't mean all hope is lost. > > 2) Now I ask myself: "Why would this be in core?" Looking at this function I > see something interesting, there's nothing about this patch that couldn't be > added as a utility function in some separate project. So why would I want to > force the maintainers of Clojure, now and in the future, to support some > extra logic? The best reason I can come up with is that it saves me > copy-and-pasting some util function around, or perhaps it keeps me from > including another util dependency in my projects. Is that convenience worth > the cost? I don't know, and that's not my job, thankfully :) . > > 3) Now I ask my self: "When have I needed this feature?" And sadly, I can't > think of a case. That's not to say I haven't needed to call assoc-in on many > path/value pairs, but when I do I often use a construct like this: > > (reduce-kv assoc-in {} > {[:a :b] 42 > [:c :d] 43 > [:d] 11}) > > In fact, I've been thinking about this for several days, and I have yet to > think of a situation where I'd prefer 'apply' over reduce. And I can't think > of a situation where I've need multiple hand-written arguments to assoc-in. > > I also think I haven't needed this functionality because I tend to prefer > namespaced keywords and flat maps. Or when I do have nested maps, I use > something like prewalk to do my work. This is anecdotal evidence, but it's > my experience. > > None of these things are huge, but that's my thought process when reading > about patches. > > Timothy > > On Mon, Aug 15, 2016 at 6:53 PM, Łukasz Kożuchowski > wrote: >> >> Thanks for the tip. I imagine the patch author is much more sad (it's been >> one year...). >> >> Łukasz Kożuchowski >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to
Re: ClojureScript and React-native?
Also give boot-react-native a try (https://github.com/mjmeintjes/boot-react-native). It's a admittedly bit rough to get started, but when set up offers a powerful interactive working environment. On Sun, May 29, 2016 at 4:12 PM, Mark Stangwrote: > Well, Re-natal seems to build and run. I am still going through the > exercises in the README. > > On Sat, May 28, 2016 at 7:16 PM, Mark Stang wrote: >> >> Has anyone gotten it to work lately by building it from scratch? And by >> from scratch, I mean using the instructions on cljsrn.org? >> >> The natal how-to's end up with an error. >> >> And the Awesome project references a missing .h file, so it doesn't build. >> >> So, does anyone have a tutorial that works? >> >> thanks, >> >> Mark > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Processing an array
Here's how I would do it: ``` (defn to-timed-events [events] (->> events (reduce (fn [[acc-events acc-time] {:keys [duration], :as event}] [(conj acc-events (assoc event :time acc-time)) (+ acc-time duration)]) [[] 0]) first)) ``` A few comments: 1. Usually, if you're reaching for explicit recursion in Clojure, consider using `reduce` instead. It's rare to find a problem that can't be expressed more succinctly with `reduce`. 2. As another rule of thumb, if you're unsure how to model a sequence transformation in Clojure, chances are that `reduce` is what you're looking for. This is especially true if you're coming from an imperative background, where people are not used to think in terms of reduce/fold. 3. The step function needs to keep track of both the events seen so far and the time of all previous events added together. This "accumultator" value -- the first argument to the step function -- holds the intermediate result of the computation so far. 4. Because we need to keep track of two things (events and accumulated time), the initial value passed to `reduce` is a pair (vector with two elements). We use sequence destructuring to access both elements easily in the step function. 5. We don't care about the accumulated time at the end. So we discard it in the final step by extracting the events from the result using `first`. On Sun, Apr 24, 2016 at 12:01 PM, Olivier Scalbertwrote: > Hi all, > > I am a Clojure beginner > And I have an advice to ask ! > > I have an array of events: > > (def events [ > {:id "1" :duration 100} > {:id "2" :duration 200} > {:id "3" :duration 300} > ]) > > I wanted to transform this array into: > [ > {:id 1, :duration 100, :time 0} ; event 1 starts at 0 > {:id 2, :duration 200, :time 100} ; event 2 starts when event 1 is > finished, so at 100 > {:id 3, :duration 300, :time 300} ; event 3 starts when event 2 is > finished, so at 100 + 200 > ] > > Here is the function code: > > (defn to-timed-events > ([time events] (to-timed-events time [] events)) > ([time timed-events events] > (if (empty? events) > timed-events > (let [current (first events) > next-time (+ (:duration current) time)] > (recur next-time (conj timed-events (assoc current :time time)) > (rest events)) > > > It seems to work, but it looks a bit long for what it is doing. Is it > possible to improve it ? > > Thanks for your help, > > Olivier > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.