Jan-Paul, Laurent- That's great. Thanks.
--
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 unsub
Solved:
(g/header
(g/repeated :ubyte :prefix :ubyte)
(fn [h]
(g/finite-block (apply + h)))
(fn [b]
...))
That did it.
On Fri, Oct 10, 2014 at 10:32:59AM -0700, john walker wrote:
> What information do you want after this is decoded?
Correction: this actually is what I'm trying to do:
(defn get-payload-from-recursive-header-frame
[[hlenlen & raw-bytes]]
(let [hlen (apply + (take hlenlen raw-bytes))]
(take hlen (drop hlenlen raw-bytes
Or with the headers preserved:
(defn get-payload-from-recursive-header-f
Hey Michael,
Since your eval solution essentially "cookie-cutters" out maps, each with
the same keys, as fast as it can, I was playing around with what would
happen if you used records, and I cobbled together something that appears
to run twice as fast as the eval approach:
(defn read-to-struc
Thanks for taking the time for the (detailed) clarification. I understand what
you were saying now.
:)
--
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 ar
+1 for changing the name to something which people won't confuse with the
"blessed" library.
On Saturday, October 11, 2014 3:39:43 PM UTC-5, James Reeves wrote:
>
> The name of this library is *really* close to the "clojure.java.jdbc"
> contrib library. You may want to consider changing the name
The common case in hash map lookup for keywords _that finds a matching key
in the map_ is:
(a) hash the keyword (fast, because it is cached)
(b) use the hash code value to walk one or more nodes in a tree to reach a
leaf, where there can be a single value, or a linked list of multiple
colliding va
Hi Zach,
Thanks for the clarity of thought that went into this post.
Perhaps it is obvious to everyone but me, but I saw this post by Christophe
Grande yesterday that appears to address these concerns:
"Back-pressurized interop for
core.async" https://twitter.com/cgrand/status/520566182194450
After this is decoded, I want the the payload, and it'd be nice to have the
length too but not necessary.
Described in clojure instead of prose:
(defn get-payload-from-recursive-header-frame
[[hlenlen & raw-bytes]]
(let [hlen (apply + (take hlenlen raw-bytes))]
(drop hlenlen raw-bytes)))
To the point (b) it seems that this posts is saying the clj's = will not be
faster for keyword than string since the runtime type checking overhead is
where most time is spent. So the identity part of keyword equals doesn't show
its benefit here (unless these were long strings vs long keywords I
To the point (b) it seems that this posts is saying the clj's = will not be
faster for keyword than string since the runtime type checking overhead is
where most time is spent. So the identity part of keyword equals doesn't show
its benefit here (unless these were long strings vs long keywords I
To the point (b) it seems that this posts is saying the clj's = will not be
faster for keyword than string since the runtime type checking overhead is
where most time is spent. So the identity part of keyword equals doesn't show
its benefit here (unless these were long strings vs long keywords I
Advantages exist, ClojureScript and Clojure both use the most efficient
equality check during key lookup in maps.
On Saturday, October 11, 2014, Colin Fleming
wrote:
> Does this mean that keywords don't have any efficiency advantages over
> strings when used as map keys?
>
> On 12 October 2014 0
I haven't taken the time to verify these statements with microbenchmarks,
but there are 2 reasons why keywords should have efficiency advantages over
strings when used as hash map keys:
(a) For keywords, hash values are calculated and cached when the keyword is
first constructed. When looking up
Thank you very much to both for the feedback.
I was considered different names in the past (I don't like much clj.jdbc
name :( ) and the current name was the election.
Changing the name again also can get confuse people, because of it, I
thinking maybe better keep the current name as is.
Thanks a
Does this mean that keywords don't have any efficiency advantages over
strings when used as map keys?
On 12 October 2014 02:25, David Nolen wrote:
> As already mentioned use identical? In ClojureScript you must use
> keyword-identical? for fast comparisons.
>
>
> On Friday, October 10, 2014, Jon
Le samedi 11 octobre 2014, Jan-Paul Bultmann
a écrit :
> Yes you are right, currently a lot of stuff is seq only.
> I think that reducers provide a lot of eager operations, but not
> everything.
>
> So yeah, transducers are exactly what you are looking for.
>
> If you call `sequence` with the tra
On 12 October 2014 at 00:39:40, James Reeves (ja...@booleanknot.com) wrote:
> The name of this library is really close to the "clojure.java.jdbc"
> contrib library. You may want to consider changing the name so
> people don't get confused.
…and IMO clj.jdbc was significantly easier to tell fr
The name of this library is *really* close to the "clojure.java.jdbc"
contrib library. You may want to consider changing the name so people don't
get confused.
- James
On 11 October 2014 21:01, Andrey Antukh wrote:
> A JDBC library for clojure.
>
> Previously: clj.jdbc
>
> Summary of changes fr
A JDBC library for clojure.
Previously: clj.jdbc
Summary of changes from 0.2.2 to 0.3.0:
- Minor code reorganization (split protocols from implementation)
- Normalize connection pool parameters make them more plugable.
- Type hints for almost all code.
- Documentation improvements.
Summary of c
Just released v0.1.0 of ike.tk.http which provides a Trapperkeeper service
that starts http-kit. The http-kit-service expects another service
implementing the HandlerService protocol to provide the Ring handler.
This is my very first Clojure experience, so any feedback is welcome.
More details, i
Yes you are right, currently a lot of stuff is seq only.
I think that reducers provide a lot of eager operations, but not everything.
So yeah, transducers are exactly what you are looking for.
If you call `sequence` with the transducer you get laziness, if you call `into`
with a collection and a
I don't think I have any misconceptions. I probably haven't expressed
myself clearly. Clojure has many very useful functions that return lazy
sequences. Analogous functions in other languages perform what are exactly
the same operations, except for the fact that what's returned is not a lazy
I don't think I have any misconceptions. I probably haven't expressed
myself clearly. Clojure has many very useful functions that return lazy
sequences. Analogous functions in other languages perform what are exactly
the same operations, but for the fact that what's returned is not a lazy
se
On Oct 11, 2014, at 1:00 PM, Jan-Paul Bultmann
wrote:
>
> Therefor "turning of laziness" makes no real sense. You could say "disable
> the laziness of seqs",
> but that doesn't really make sense either. It's like disabling the FIFO
> nature of a queue or a channel.
> If you don't want the pro
I feel that there are some misconceptions here,
Clojure is not a language that has lazy evaluation,
but is instead completely eager.
Macros are the closest thing that come to laziness, but they are still
different.
However, Clojure has a data structure, that also serves as an abstraction layer,
th
Hello all,
New version 5.2.0 of rete4frames CLIPS-like expert system shell published
on https://github.com/rururu/rete4frames.
News:
1. Tests can be used in negative condition
2. Because of this CLIPS examples reducted to canonical form
3. Several bug fixes including logical
4. Lot of code opti
you can do some pretty powerful things using update-in and merge-with,
especially if combined with protocols or multimethods that determine
behavior. Can you give a more specific example of what you're trying to do?
deep-merge and deep-merge-with are also useful here. There are a lot of
nearly
Thanks Jan-Paul. That's helpful. I wonder whether, if all lazy functions
were rewritten in terms of transducers, it would then be easy to turn
laziness on and off. (I am not suggesting that this should be done. No
doubt it would entail a lot of work, and performance tradeoffs. I'm quite
ha
On Oct 11, 2014, at 10:59 AM, Jony Hudson wrote:
> But if any of these Keyword objects were garbage-collected, I think it would
> break the parity between identical? and =.
The Keyword construction and interning mechanism ensures that whenever there
exists at least once (strong) reference to
Thanks all, that makes a lot of sense.
To summarise, if I understand correctly, (on the JVM) comparing with = :
- first checks if the objects are one and the same, returns true if so
- if not, checks whether they are numbers or persistent collections, which
have special-case checks
- if neither o
Thanks all!
FWIW, the snake game in Programming Clojure has an example (where refs are
conditionally updated) which is consistent with the advice given here.
Two nice things I noticed in that example:
1. The first form inside do is kept on the same line (a small but nice
improvement reducing
As already mentioned use identical? In ClojureScript you must use
keyword-identical? for fast comparisons.
On Friday, October 10, 2014, Jony Hudson wrote:
> Hi All,
>
> I've been optimising a piece of code lately, and have come to wonder
> about the performance of keyword comparison. Specifical
Just done some of my own quick benchmarking on this.
(= :foo :bar) ;; 21.7 ns
(.equals :foo :bar);; 3.0 ns
(identical? :foo :bar) ;; 3.0 ns
(.equals "foo" "bar") ;; 5.6 ns
(= "foo" "bar");; 24.4 ns
This seems to support my suspicion that the overhead is in the extra
ove
I believe this is a symptom of the fact that the Clojure compiler isn't
very type aware, and = inserts a bunch of redundant runtime type checks
(see clojure.lang.Util.equiv(Object, Object) )
In particular, it always checks for whether the arguments are instances of
Number or IPersistentCollecti
Transducers build up transformation steps, with new generic operations like
single arg `map` and `filter`, and then apply these transformations to a
collection using an evaluation function.
This function decides if operations are done lazily, eagerly, or on a channel.
Note that while this makes
36 matches
Mail list logo
