Re: [ANN] psq.clj 0.0.2 – Persistent Priority Search Queues

I am pleased to announce the 0.0.2 release of psq.clj, a Clojure > priority search queue library based on Ralf Hinze's priority search > pennants (see Ralf Hinze, "A Simple Implementation Technique for > Priority Search Queues"): > > https://github.com/michalmarczyk

[ANN] maxiphobe 0.0.1 – Persistent Meldable Priority Queues

Hi, I am pleased to announce the initial release of maxiphobe, a meldable priority queue library based on Okasaki's maxiphobic heaps (see Okasaki, "Alternatives to Two Classic Data Structures"). Maxiphobic heaps are a strikingly simple purely functional approach to implementing

[ANN] psq.clj 0.0.2 – Persistent Priority Search Queues

Hi, I am pleased to announce the 0.0.2 release of psq.clj, a Clojure priority search queue library based on Ralf Hinze's priority search pennants (see Ralf Hinze, "A Simple Implementation Technique for Priority Search Queues"): https://github.com/michalmarczyk/psq.clj http

Re: What are favored Redis-backed queues?

Also, I should mention that Ruby doesn't have very good built in parallelism support (no true threads when I was using, though this might have changed). As such, I've seen a fair bit of usage of Resque running on a single machine. This would be an insane overcomplication in Clojure given all it

Re: What are favored Redis-backed queues?

I think you mean to be asking specifically about *job* queuing using Redis. You don't need anything other than Redis + Carmine to create queues. But obviously, the value of Resque (note spelling) is that it *uses* Redis in a number of non-trivial ways, such that all of the features abov

What are favored Redis-backed queues?

try failed jobs - Don't "release" failed jobs https://github.com/blog/542-introducing-resque They ended up creating Rescue, and using Redis in the background. Lately I've been looking at Carmine, but I'm wondering, what are some of the queues that people are using with Cl

Re: STM history queues, when is a snapshot pushed

Having learned a little more about refs and transactions from M. Fogus and C. Houser "The Joy of Clojure, Second Edition", I altered the stress-ref function from 10.2.4. Using Clojure 1.5.1: (defn stress-ref [r] (let [slow-tries (atom 0)] (future (dosyn

STM history queues, when is a snapshot pushed

Is a new snapshot pushed onto the history queue of a ref when 1. every time the ref is a target of alter, commute, ref-set, reset, alter-meta!, or reset-meta!, or 2. only when the committed value for the ref is not identical to the value at the end of the history queue? When chec

Re: what is a good book about Java queues?

ised that it says fairly little about working > with queues. I am curious if anyone would recommend a book for learning > more about working with Java queues? > > I suffer the problem that I learned Clojure without first learning Java, > and Clojure leans on Java rathe

Re: what is a good book about Java queues?

Two queues cover the 80% case: an implementation of BlockingQueue (array, linked list backed), and clojure.lang.PersistentQueue. The former provides concurrency semantics: there are no 'stale values' issues associated to mutation, and you can choose whether your reads/writes ar

Re: what is a good book about Java queues?

> So I read it, but I am surprised that it says fairly little about working > with queues. I am curious if anyone would recommend a book for learning > more about working with Java queues? > > I suffer the problem that I learned Clojure without first learning Java, > and Clojure le

what is a good book about Java queues?

+in+practice So I read it, but I am surprised that it says fairly little about working with queues. I am curious if anyone would recommend a book for learning more about working with Java queues? I suffer the problem that I learned Clojure without first learning Java, and Clojure leans on

Re: Queues in Clojure

2010/12/3 Andreas Kostler : > Hi All, > May I cite an Author of a populer Clojure book: > > "If you find yourself wishing yourself to repeatedly check a work queue to > see if there's an item of work to be popped off, > or if you want to use a queue to send a task to another thread, you do *not*

Queues in Clojure

Hi All, May I cite an Author of a populer Clojure book: "If you find yourself wishing yourself to repeatedly check a work queue to see if there's an item of work to be popped off, or if you want to use a queue to send a task to another thread, you do *not* want the PersistenQueue discussed in t

Re: Queues

On Tue, Feb 3, 2009 at 2:35 PM, Konrad Hinsen wrote: > For queues you need to add > at one end and remove from the other, so one of the two operations is > necessarily expensive. No. Look here for hints: <http://www.cs.bu.edu/teaching/c/queue/array/types.html> http://www.cs.bu

Re: Queues

On Feb 3, 2009, at 14:57, Christophe Grand wrote: > If you haven't tried it yet, there's clojure.lang.PersistentQueue: I didn't, since it's well hidden - you can even search for PersistentQueue on the Clojure web site without finding anything. But it looks like just what I want - thanks! Ko

Re: Queues

Lauri Pesonen a écrit : > You can use a pair of lists to implement a queue where the first list > is used to dequeue items from and the second list is used to enqueue > items to. When the first queue is empty, you replace it with a > reversed version of the second queue. > Or you can use a seq

Re: Queues

I don't know which of these two options are best in general, but I wonder; are persistance and immutability valuable properties of queues? Safe and cheap snap-shotting might be a nice feature of a queue but I (generally) wouldn't want it at the cost of more expensive "put" a

Re: Queues

2009/2/3 Konrad Hinsen : > > Is there any reason to prefer lists over vectors or vice versa for > implementing queues? It seems that for both lists and vectors, adding > and removing at one end (front for lists, end for vectors) is cheap, > whereas it is expensive at the other end.

Re: Queues

Konrad Hinsen a écrit : > Is there any reason to prefer lists over vectors or vice versa for > implementing queues? It seems that for both lists and vectors, adding > and removing at one end (front for lists, end for vectors) is cheap, > whereas it is expensive at the other end

Queues

Is there any reason to prefer lists over vectors or vice versa for implementing queues? It seems that for both lists and vectors, adding and removing at one end (front for lists, end for vectors) is cheap, whereas it is expensive at the other end. For queues you need to add at one end and