[ANN] clafka 0.2.2
A new version of https://github.com/mixradio/clafka has been released. clafka is a library providing an idiomatic clojure api for kafka's SimpleConsumer and KafkaProducer. It is intended to be used as the basis for consumers whose needs are not met by the zookeeper consumer that is included with kafka itself. Since the last announcement: - A pooled client has been added so you can worry less about finding partition leaders. - publish! and publish-ack! allow you to specify the partition to publish to. - The consumer api is now based on a protocol (IBrokerClient). Both the SimpleConsumer and the PooledClient implement this interface. As always, contributions are very welcome! Cheers! Dan -- 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.
[ANN] clafka 0.1.0 - a clojure kafka client focusing on the SimpleConsumer and KafkaProducer.
I am pleased to announce the release of the initial version of our new kafka library! I see this library as useful for people that want to... a. Read some data from their kafka logs worry free (no consumer groups, no state etc) b. Implement a new kind of consumer, as their needs are not met by the default zookeeper consumer in kafka (like us!) c. Use a clojure wrapper for the new KafkaProducer api (including broker acknowledgement) Source and docs here: https://github.com/mixradio/clafka Questions, comments and contributions very welcome! Regards, Dan -- 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: [ANN] silc - a tiny entity database for clojure (games)
Yes I should probably not be using BigDecimals :) I'll fix this as soon as I can. On Wednesday, December 3, 2014 2:10:53 AM UTC, Atamert Ölçgen wrote: Why are you using BigDecimal's for indices? If you want to go big, isn't BigInt a better choice? Actually, I would just use Long's. (MAX_VALUE = 9223372036854775807) On Wed, Dec 3, 2014 at 10:04 AM, Atamert Ölçgen mu...@muhuk.com javascript: wrote: This is a very nice example of abstraction. Using a hash-map is just an implementation detail. However I'd be very interested to hear if there are any other compelling use cases for this. Sparsely populated tables, unstructured anything... We used an EAV abstraction (over SQL) to build a product database. Different product types have very different fields, even same types of product might have different fields sometimes. In hindsight normalized relational tables would have been a better fit (the decision was made before I joined). In your README, the change and delete examples give the impression that they're mutating the db, but they actually return an updated db if I'm not mistaken. On Wed, Dec 3, 2014 at 6:37 AM, dan.sto...@gmail.com javascript: wrote: I have put together a quick library http://github.com/danstone/silc that allows you to manage many entities and their attributes in a pure way with indexing for performance, include composite indexes. The intention of the library is certainly as the basis for an entity component system for games, that is how I am using it. However I'd be very interested to hear if there are any other compelling use cases for this. Pull requests welcome! Thanks, Dan -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.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. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] silc - a tiny entity database for clojure (games)
Is it possible to retrieve all entities with a set of attributes, regardless of the attribute values? Not yet, I haven't indexed for it. You could approximate it using the ave index if you just concat any set of entities under any value. However it would require the attributes you are interested in participating in the ave index. It would be a worthy edition though so I'll look at it unless somebody wants to submit a pull request. Cool project! Did you try using the pldb built into core.logic? I have a similar system built atop pldb backing one of my side projects and I'm very happy with it. I do like pldb and core.logic and have used them in the past - I would very much like to introduce an optional core.logic front-end to this, however it was important to me that the primary interface was perhaps less declarative but with stronger performance guarantees as my use case for this is for game development. -- 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: [ANN] silc - a tiny entity database for clojure (games)
I have released an update to the lib with a new index the `attribute-entity` index, and improved the readme (I hope). Check it out! Regards, Dan -- 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.
[ANN] silc - a tiny entity database for clojure (games)
I have put together a quick library http://github.com/danstone/silc that allows you to manage many entities and their attributes in a pure way with indexing for performance, include composite indexes. The intention of the library is certainly as the basis for an entity component system for games, that is how I am using it. However I'd be very interested to hear if there are any other compelling use cases for this. Pull requests welcome! Thanks, Dan -- 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.
Hierarchical data core.logic
I think this is a dummy question, but wondering whether this is possible in
core.logic?
Lets say I have a set of relations
(db-rel foo p)
(db-rel bar p)
(db-rel fooz p p2)
and facts
[foo 1]
[bar 2]
[fooz 2 1]
[bar 3]
[fooz 3 1]
See that the fooz relation is potentially describing bar as children of
foo's. (like a foreign key)
and I want to unify with all the `bar`s for a given `foo` like so:
(run* [?q]
(fresh [?foo ?bars]
(bars-for-foo ?foo ?bars)
(l/== {:foo ?foo
:bars ?bars}
?q)))
=
({:foo 1, :bar (2 3)})
Is it possible to define bars-for-foo?
--
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: Weird data reader issue (clj-time)
Thats it! Thanks for the great explanation.
On Wednesday, August 20, 2014 5:55:18 PM UTC+1, Marshall
Bockrath-Vandegrift wrote:
What's your `print-dup` for instants print them as? The way compilation
for these expressions is going to work is:
(a) The initial form will be read using the configured *data-readers*,
handing the compiler a form with a literal instance object.
(b) The compiler will generate code to create that literal; when the
literal value isn't of a type the compiler knows how to emit directly, it
emits code to round-trip back through the reader at run-time, embedding the
`print-dup` representation of the object as a string.
If `print-dup` prints in such a way as to discard the offset, away it goes.
-Marshall
On Wednesday, August 20, 2014 10:29:15 AM UTC-4, dan.sto...@gmail.com
wrote:
Maybe I am missing something obvious -
I am using custom data readers for joda-time instants. time/inst strings
are coerced into utc date times, time/insto keep the offset around.
Using the exact same function to parse the string via the data-reader,
and just calling the function - I get different results. The function is
pure...
*data-readers*
= {time/insto (var corp-pure.time/parse-with-offset),
time/inst (var corp-pure.time/parse)}
(.getChronology (corp-pure-time/parse-with-offset
2014-05-03T23:00:00+0100))
(.getChronology #time/insto 2014-05-03T23:00:00+0100)
= #ISOChronology ISOChronology[+01:00]
= #ISOChronology ISOChronology[UTC]
To prove there are no obvious side-effects here:
(.getChronology (corp-pure.time/parse-with-offset
2014-05-03T23:00:00+0100))
(.getChronology (corp-pure.time/parse-with-offset
2014-05-03T23:00:00+0100))
= #ISOChronology ISOChronology[+01:00]
= #ISOChronology ISOChronology[+01:00]
(.getChronology #time/insto 2014-05-03T23:00:00+0100)
(.getChronology #time/insto 2014-05-03T23:00:00+0100)
= #ISOChronology ISOChronology[UTC]
= #ISOChronology ISOChronology[UTC]
Has anyone seen anything like this?
--
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.
Weird data reader issue (clj-time)
Maybe I am missing something obvious -
I am using custom data readers for joda-time instants. time/inst strings
are coerced into utc date times, time/insto keep the offset around.
Using the exact same function to parse the string via the data-reader, and
just calling the function - I get different results. The function is
pure...
*data-readers*
= {time/insto (var corp-pure.time/parse-with-offset),
time/inst (var corp-pure.time/parse)}
(.getChronology (corp-pure-time/parse-with-offset
2014-05-03T23:00:00+0100))
(.getChronology #time/insto 2014-05-03T23:00:00+0100)
= #ISOChronology ISOChronology[+01:00]
= #ISOChronology ISOChronology[UTC]
To prove there are no obvious side-effects here:
(.getChronology (corp-pure.time/parse-with-offset
2014-05-03T23:00:00+0100))
(.getChronology (corp-pure.time/parse-with-offset
2014-05-03T23:00:00+0100))
= #ISOChronology ISOChronology[+01:00]
= #ISOChronology ISOChronology[+01:00]
(.getChronology #time/insto 2014-05-03T23:00:00+0100)
(.getChronology #time/insto 2014-05-03T23:00:00+0100)
= #ISOChronology ISOChronology[UTC]
= #ISOChronology ISOChronology[UTC]
Has anyone seen anything like this?
--
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: core.cache strange behaviour for short ttl
In case anyone was wondering I worked out what was going on and it makes
perfect sense. I was being stupid :)
If you ask for a value via 'lookup' expired values will not be returned at
this point as 'has?' is called internally.
I made a quick and dirty library to reflect the behaviour I want for my
particular use case: https://github.com/danstone/clj-refresh-cache
On Friday, February 28, 2014 9:47:14 PM UTC, dan.sto...@gmail.com wrote:
Taking the code below, if I repeatedly read from a cache I will
occasionally get nil back from the cache. This seems to happen on my
machine for ttl's under 5 ms.
Although I'm sure I would never use such a short TTL in the wild, I would
like to know why I am seeing this... Has anybody else noticed this issue?
(ns cache-test.core
(:require [clojure.core.cache :as cache]))
(def data (atom foo))
(def ttl
(atom (cache/ttl-cache-factory {} :ttl 1)))
(defn get-data
[]
(let [c @ttl
nc (if (cache/has? c {})
(cache/hit c {})
(cache/miss c {} @data))]
(reset! ttl nc)
(cache/lookup nc {})))
(def results (atom '()))
;; there will *sometimes* be
;; nil elements in the seq, seems dependent on cpu speed, which would make
sense due to side effect of taking system/currentTimeMillis internally.
(set (map (fn [_] (get-data)) (range 1)))
--
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/groups/opt_out.
core.cache strange behaviour for short ttl
Taking the code below, if I repeatedly read from a cache I will
occasionally get nil back from the cache. This seems to happen on my
machine for ttl's under 5 ms.
Although I'm sure I would never use such a short TTL in the wild, I would
like to know why I am seeing this... Has anybody else noticed this issue?
(ns cache-test.core
(:require [clojure.core.cache :as cache]))
(def data (atom foo))
(def ttl
(atom (cache/ttl-cache-factory {} :ttl 1)))
(defn get-data
[]
(let [c @ttl
nc (if (cache/has? c {})
(cache/hit c {})
(cache/miss c {} @data))]
(reset! ttl nc)
(cache/lookup nc {})))
(def results (atom '()))
;; there will *sometimes* be
;; nil elements in the seq, seems dependent on cpu speed, which would make
sense due to side effect of taking system/currentTimeMillis internally.
(set (map (fn [_] (get-data)) (range 1)))
--
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/groups/opt_out.
