Re: soft question: should remote channels appear like local channels

[t x]

I agree, besides potential connection loss, I no longer see the
distinction between "local async channel" and "remote async channel."

Thanks to everyone for clarifications / help.

On Fri, Jan 31, 2014 at 6:51 PM, Sean Corfield  wrote:
> I like that way of thinking, Timothy!
>
> Thomas: it's very specifically two separate channels; on the client
> side, code puts data on a channel and additional client code (in a
> library) takes data off the channel and handles the client/server
> communication; on the server side, a library reads data from the
> client/server connection and puts it on a channel, and your own server
> side code takes data from that channel. And the same thing in reverse.
>
> The point is that each side is isolated and core.async is used as a
> way to interact with a library that consumes data (and sends it
> somewhere) and produces data (that it reads from somewhere). The
> application code "doesn't care" about the client/server bridge -
> that's the library's problem. Cedric's right about connection loss etc
> but that's all part of what the library deals with - if it can't
> consume from a channel (because it can't send data over the wire),
> that's the same as any other consumer failing to take data from a
> channel that you supply.
>
> Sean
>
> On Fri, Jan 31, 2014 at 7:59 AM, Timothy Baldridge  
> wrote:
>> A quick thought...there really isn't much of a difference between a failing
>> network connection and a (chan (dropping-buffer 1024))
>>
>> Both may (or may not) drop information that you put into them, but also,
>> both can be expected to work "normally" as long as certain conditions hold.
>> Namely, the net connection doesn't die, or the consumer can keep up with the
>> data being put into the dropping buffer.
>>
>> So that's my advice, if you can't guarantee the data will reach the remote
>> end, or you can't perfectly match core.async back pressure semantics, simply
>> use a dropping buffer at the edges and code to those semantics.
>>
>> Timothy
>>
>> Timothy
>>
>>
>> On Fri, Jan 31, 2014 at 3:37 AM, Thomas Heller  wrote:
>>>
>>> Hi,
>>>
>>> only advice I can give is: no or don't.
>>>
>>> In the many years I have done web development one of the most important
>>> things I have learned is to keep the server as stateless as possible. Data
>>> is easily kept externally while channels are not. Channels also aren't
>>> exactly simple state since they are usually also attached to some go-blocks
>>> and the like. While its very common the handle disconnects of the client on
>>> the server und not as common to handle disconnects of the server on the
>>> client.
>>>
>>> Disconnects are very frequent so you need to respect them, machines go to
>>> sleep, wireless goes away, servers get restarted, jvms crash, etc.
>>>
>>> Never assume that a "remote" channel actually exist when writing to it,
>>> unless you have some really solid error recovery (which probably is more
>>> work than using traditional approaches).
>>>
>>> Just my 2 cents.
>>>
>>> /thomas
>>>
>>>
>>> On Friday, January 31, 2014 6:43:14 AM UTC+1, t x wrote:

 Hi,

 With apologies for a soft question:

 This question is NOT:

   I'm in a situation where client = cljs, server = clj, and I want to
 figure out how to setup a core.async channel, using pr-str and
 edn/read-string, where I can seamlessly push data back and forth
 between client and server.

 This question is:

   Should I do the above?

   The pro being: yay, channels everywhere, everything looks the same.

   The con being: a local core.async channel and a remote core.async
 channel over a websocket are _NOT_ the same thing, and thus should not
 appear to be the same thing.

 ## Responses:

 Although detailed responses are always appreciated, given the nature
 of this "soft" question, responses of "go read _link_" are perfectly
 welcome too.

 I suspect someone in this world has thought deeply about the question,
 written up their insights, and pointing me at this primary resource
 (rather than trying to summarize it in a three paragraph email) is
 perfectly fine too.

 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 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.
>>
>>

(async/map identity []) blocks

[Phlex]

async/map is supposed to close its output channel when one of the 
channels in the collection signals that it is closed.
I had assumed that it would do the same when the collection is empty, 
but it blocks (i witnessed that on clojurescript)


Now it's easy to work around that but not very nice to look at :

my nice function

(defn check-preds[router funcs]
  (->> funcs
   (map (partial check-pred router)) ; an array of chans
   (a/map identity)  ; a chan of maybe routers
   (a/reduce >> (just router ; a chan with a single maybe 
router


now looks like this :

(defn check-preds [router funcs]
  (if (seq funcs)
(->> funcs
 (map (partial check-pred router))
 (a/map identity)
 (a/reduce >> (just router)))
(a/to-chan [(just router)])))

Which is way uglier !

I make the case to fix this.
The cost would be low : add a seq test inside async/map
The impact would be low : if anyone is risking to wait on an empty 
channel collection, they would have the check demonstrated above, and 
the change would not affect them. And I can't see why anyone would rely 
on the current behavior.
The benefit : The library user's code looks nicer, and more 
compositional, reducing the risks for errors and increasing readability.


I hope I haven't overlooked something obvious.

Sacha De Vos

--
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.

Re: soft question: should remote channels appear like local channels

[Thomas Heller]

I guess the comparison to dropping-buffer is fair, but remember that
disconnects are actually quite more common than usually expected (esp. on
mobile). So plan on dropping messages and test accordingly, but remember
most messages will originate from something the user did on the client. Its
incredibly frustrating for users to not see an expected result to their
action (button clicks, lost input, out of order results, etc.).

Just my 2 cents of course, if dropping is ok for your app I guess you are
good to go.

Cheers
/thomas


On Sat, Feb 1, 2014 at 10:32 AM, t x  wrote:

> I agree, besides potential connection loss, I no longer see the
> distinction between "local async channel" and "remote async channel."
>
> Thanks to everyone for clarifications / help.
>
> On Fri, Jan 31, 2014 at 6:51 PM, Sean Corfield  wrote:
> > I like that way of thinking, Timothy!
> >
> > Thomas: it's very specifically two separate channels; on the client
> > side, code puts data on a channel and additional client code (in a
> > library) takes data off the channel and handles the client/server
> > communication; on the server side, a library reads data from the
> > client/server connection and puts it on a channel, and your own server
> > side code takes data from that channel. And the same thing in reverse.
> >
> > The point is that each side is isolated and core.async is used as a
> > way to interact with a library that consumes data (and sends it
> > somewhere) and produces data (that it reads from somewhere). The
> > application code "doesn't care" about the client/server bridge -
> > that's the library's problem. Cedric's right about connection loss etc
> > but that's all part of what the library deals with - if it can't
> > consume from a channel (because it can't send data over the wire),
> > that's the same as any other consumer failing to take data from a
> > channel that you supply.
> >
> > Sean
> >
> > On Fri, Jan 31, 2014 at 7:59 AM, Timothy Baldridge 
> wrote:
> >> A quick thought...there really isn't much of a difference between a
> failing
> >> network connection and a (chan (dropping-buffer 1024))
> >>
> >> Both may (or may not) drop information that you put into them, but also,
> >> both can be expected to work "normally" as long as certain conditions
> hold.
> >> Namely, the net connection doesn't die, or the consumer can keep up
> with the
> >> data being put into the dropping buffer.
> >>
> >> So that's my advice, if you can't guarantee the data will reach the
> remote
> >> end, or you can't perfectly match core.async back pressure semantics,
> simply
> >> use a dropping buffer at the edges and code to those semantics.
> >>
> >> Timothy
> >>
> >> Timothy
> >>
> >>
> >> On Fri, Jan 31, 2014 at 3:37 AM, Thomas Heller 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> only advice I can give is: no or don't.
> >>>
> >>> In the many years I have done web development one of the most important
> >>> things I have learned is to keep the server as stateless as possible.
> Data
> >>> is easily kept externally while channels are not. Channels also aren't
> >>> exactly simple state since they are usually also attached to some
> go-blocks
> >>> and the like. While its very common the handle disconnects of the
> client on
> >>> the server und not as common to handle disconnects of the server on the
> >>> client.
> >>>
> >>> Disconnects are very frequent so you need to respect them, machines go
> to
> >>> sleep, wireless goes away, servers get restarted, jvms crash, etc.
> >>>
> >>> Never assume that a "remote" channel actually exist when writing to it,
> >>> unless you have some really solid error recovery (which probably is
> more
> >>> work than using traditional approaches).
> >>>
> >>> Just my 2 cents.
> >>>
> >>> /thomas
> >>>
> >>>
> >>> On Friday, January 31, 2014 6:43:14 AM UTC+1, t x wrote:
> 
>  Hi,
> 
>  With apologies for a soft question:
> 
>  This question is NOT:
> 
>    I'm in a situation where client = cljs, server = clj, and I want to
>  figure out how to setup a core.async channel, using pr-str and
>  edn/read-string, where I can seamlessly push data back and forth
>  between client and server.
> 
>  This question is:
> 
>    Should I do the above?
> 
>    The pro being: yay, channels everywhere, everything looks the same.
> 
>    The con being: a local core.async channel and a remote core.async
>  channel over a websocket are _NOT_ the same thing, and thus should not
>  appear to be the same thing.
> 
>  ## Responses:
> 
>  Although detailed responses are always appreciated, given the nature
>  of this "soft" question, responses of "go read _link_" are perfectly
>  welcome too.
> 
>  I suspect someone in this world has thought deeply about the question,
>  written up their insights, and pointing me at this primary resource
>  (rather than trying to summarize it in a three paragraph email) is
> >>>

data-readers, spyscope

[Dave Tenny]

Java 1.7.0.45
Lein 2.3.4
Clojure 1.5.1

I'm trying to use https://github.com/dgrnbrg/spyscope and have put the 
documented bits in my ~/.lein/profiles.clj
but cannot get it to work.

{:user {:dependencies [...  [spyscope "0.1.4"] ...]
:injections [(require 'spyscope.core)
 ]}}

But when I do 'lein repl'
*data-readers* doesn't contain the required mappings to the spy definitions.

If at the REPL I try something like

(set! *data-readers* '{spy/p spyscope.core/print-log})

and then

#spy/p "abc"

I get 

RuntimeException No dispatch macro for: s 
 clojure.lang.Util.runtimeException (Util.java:219)


What's the proper way to make spyscope work for all lein user profiles?



-- 
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.

dynalint, lein-dynalint 0.1.2 - Warn on (zipmap (keys m) (vals m))

[Ambrose Bonnaire-Sergeant]

Hi,

If you're interested in refactoring out instances of (zipmap (keys m) (vals
m)),
then dynalint 0.1.2 may help.

[com.ambrosebs/dynalint "0.1.2"]


I've added a simplistic case that warns if a
clojure.lang.APersistentMap$KeysSeq or ValsSeq is passed to zipmap.

user=> (require '[dynalint.lint :as dyn])
nil
user=> (dyn/lint)
:ok
user=> (let [m {1 2 3 4}
  #_=>   ks (keys m)
  #_=>   vs (vals m)]
  #_=>   (zipmap ks vs))
WARNING (Dynalint id 1):  Should not pass result of clojure.core/keys to
zipmap
WARNING (Dynalint id 2):  Should not pass result of clojure.core/vals to
zipmap
{3 4, 1 2}
user=>

Note: dynalint only supports Clojure 1.5.1.

dynalint README 
dynalint CHANGELOG 

lein-dynalint README 

Thanks,
Ambrose

-- 
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.

Re: dynalint, lein-dynalint 0.1.2 - Warn on (zipmap (keys m) (vals m))

[Sam Ritchie]

I added this to the :injections vector of my lein project; it looks 
really helpful, but when compiling in emacs via nRepl, without the line 
number, it's really hard to track down these errors. Is there any way 
that dynalint could (optionally) output more info about where the 
infraction takes place?



Ambrose Bonnaire-Sergeant 
February 1, 2014 6:38 AM
Hi,

If you're interested in refactoring out instances of (zipmap (keys m) 
(vals m)),

then dynalint 0.1.2 may help.


|[com.ambrosebs/dynalint "0.1.2"]|

I've added a simplistic case that warns if a 
clojure.lang.APersistentMap$KeysSeq or ValsSeq is passed to zipmap.


user=> (require '[dynalint.lint :as dyn])
nil
user=> (dyn/lint)
:ok
user=> (let [m {1 2 3 4}
  #_=>   ks (keys m)
  #_=>   vs (vals m)]
  #_=>   (zipmap ks vs))
WARNING (Dynalint id 1):  Should not pass result of clojure.core/keys 
to zipmap
WARNING (Dynalint id 2):  Should not pass result of clojure.core/vals 
to zipmap

{3 4, 1 2}
user=>

Note: dynalint only supports Clojure 1.5.1.

dynalint README 
dynalint CHANGELOG 

lein-dynalint README 

Thanks,
Ambrose
--
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.


--
Sam Ritchie (@sritchie)
Paddleguru Co-Founder
703.863.8561
www.paddleguru.com 
Twitter // Facebook 



--
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.
<>

Re: dynalint, lein-dynalint 0.1.2 - Warn on (zipmap (keys m) (vals m))

[Ambrose Bonnaire-Sergeant]

Hi Sam,

Are you familiar of dynalint.lint/print-warning?

That's really the best idea I've come up with.

Thanks,
Ambrose


On Sat, Feb 1, 2014 at 9:54 PM, Sam Ritchie  wrote:

> I added this to the :injections vector of my lein project; it looks really
> helpful, but when compiling in emacs via nRepl, without the line number,
> it's really hard to track down these errors. Is there any way that dynalint
> could (optionally) output more info about where the infraction takes place?
>
>   Ambrose Bonnaire-Sergeant 
>  February 1, 2014 6:38 AM
> Hi,
>
> If you're interested in refactoring out instances of (zipmap (keys m)
> (vals m)),
> then dynalint 0.1.2 may help.
>
>
> [com.ambrosebs/dynalint "0.1.2"]
>
> I've added a simplistic case that warns if a
> clojure.lang.APersistentMap$KeysSeq or ValsSeq is passed to zipmap.
>
> user=> (require '[dynalint.lint :as dyn])
> nil
> user=> (dyn/lint)
> :ok
> user=> (let [m {1 2 3 4}
>   #_=>   ks (keys m)
>   #_=>   vs (vals m)]
>   #_=>   (zipmap ks vs))
> WARNING (Dynalint id 1):  Should not pass result of clojure.core/keys to
> zipmap
> WARNING (Dynalint id 2):  Should not pass result of clojure.core/vals to
> zipmap
> {3 4, 1 2}
> user=>
>
> Note: dynalint only supports Clojure 1.5.1.
>
> dynalint README 
> dynalint CHANGELOG 
>
> lein-dynalint README 
>
> Thanks,
> Ambrose
> --
> 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.
>
>
> --
> Sam Ritchie (@sritchie)
>  Paddleguru Co-Founder
> 703.863.8561
> www.paddleguru.com
> Twitter  // 
> Facebook
>
> --
> 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.
>

-- 
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.
<>

Re: dynalint, lein-dynalint 0.1.2 - Warn on (zipmap (keys m) (vals m))

[Sam Ritchie]

Let me see how I can work that into the flow. Thanks!


Ambrose Bonnaire-Sergeant 
February 1, 2014 6:58 AM
Hi Sam,

Are you familiar of dynalint.lint/print-warning?

That's really the best idea I've come up with.

Thanks,
Ambrose



--
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.
Sam Ritchie 
February 1, 2014 6:54 AM
I added this to the :injections vector of my lein project; it looks 
really helpful, but when compiling in emacs via nRepl, without the 
line number, it's really hard to track down these errors. Is there any 
way that dynalint could (optionally) output more info about where the 
infraction takes place?



Ambrose Bonnaire-Sergeant 
February 1, 2014 6:38 AM
Hi,

If you're interested in refactoring out instances of (zipmap (keys m) 
(vals m)),

then dynalint 0.1.2 may help.


|[com.ambrosebs/dynalint "0.1.2"]|

I've added a simplistic case that warns if a 
clojure.lang.APersistentMap$KeysSeq or ValsSeq is passed to zipmap.


user=> (require '[dynalint.lint :as dyn])
nil
user=> (dyn/lint)
:ok
user=> (let [m {1 2 3 4}
  #_=>   ks (keys m)
  #_=>   vs (vals m)]
  #_=>   (zipmap ks vs))
WARNING (Dynalint id 1):  Should not pass result of clojure.core/keys 
to zipmap
WARNING (Dynalint id 2):  Should not pass result of clojure.core/vals 
to zipmap

{3 4, 1 2}
user=>

Note: dynalint only supports Clojure 1.5.1.

dynalint README 
dynalint CHANGELOG 

lein-dynalint README 

Thanks,
Ambrose
--
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.


--
Sam Ritchie (@sritchie)
Paddleguru Co-Founder
703.863.8561
www.paddleguru.com 
Twitter // Facebook 



--
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.
<><>

Re: dynalint, lein-dynalint 0.1.2 - Warn on (zipmap (keys m) (vals m))

[Ambrose Bonnaire-Sergeant]

I just realised it's undocumented.

(print-warning) prints the latest warning.

(print-warning id) prints the dynalint warning with the corresponding id

(print-warning id depth) also has depth like clojure.repl/pst.

Ditto with print-error.

Thanks,
Ambrose


On Sat, Feb 1, 2014 at 10:14 PM, Sam Ritchie  wrote:

> Let me see how I can work that into the flow. Thanks!
>
>   Ambrose Bonnaire-Sergeant 
>  February 1, 2014 6:58 AM
> Hi Sam,
>
> Are you familiar of dynalint.lint/print-warning?
>
> That's really the best idea I've come up with.
>
> Thanks,
> Ambrose
>
>
>
> --
> 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.
>   Sam Ritchie 
>  February 1, 2014 6:54 AM
>  I added this to the :injections vector of my lein project; it looks
> really helpful, but when compiling in emacs via nRepl, without the line
> number, it's really hard to track down these errors. Is there any way that
> dynalint could (optionally) output more info about where the infraction
> takes place?
>
>
>   Ambrose Bonnaire-Sergeant 
>  February 1, 2014 6:38 AM
> Hi,
>
> If you're interested in refactoring out instances of (zipmap (keys m)
> (vals m)),
> then dynalint 0.1.2 may help.
>
>
> [com.ambrosebs/dynalint "0.1.2"]
>
> I've added a simplistic case that warns if a
> clojure.lang.APersistentMap$KeysSeq or ValsSeq is passed to zipmap.
>
> user=> (require '[dynalint.lint :as dyn])
> nil
> user=> (dyn/lint)
> :ok
> user=> (let [m {1 2 3 4}
>   #_=>   ks (keys m)
>   #_=>   vs (vals m)]
>   #_=>   (zipmap ks vs))
> WARNING (Dynalint id 1):  Should not pass result of clojure.core/keys to
> zipmap
> WARNING (Dynalint id 2):  Should not pass result of clojure.core/vals to
> zipmap
> {3 4, 1 2}
> user=>
>
> Note: dynalint only supports Clojure 1.5.1.
>
> dynalint README 
> dynalint CHANGELOG 
>
> lein-dynalint README 
>
> Thanks,
> Ambrose
> --
> 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.
>
>
> --
> Sam Ritchie (@sritchie)
>  Paddleguru Co-Founder
> 703.863.8561
> www.paddleguru.com
> Twitter  // 
> Facebook
>
> --
> 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.
>

-- 
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.
<><>

Re: dynalint, lein-dynalint 0.1.2 - Warn on (zipmap (keys m) (vals m))

[Sam Ritchie]

Thanks for the help! This is great.


Ambrose Bonnaire-Sergeant 
February 1, 2014 7:16 AM
I just realised it's undocumented.

(print-warning) prints the latest warning.

(print-warning id) prints the dynalint warning with the corresponding id

(print-warning id depth) also has depth like clojure.repl/pst.

Ditto with print-error.

Thanks,
Ambrose



--
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.
Sam Ritchie 
February 1, 2014 7:14 AM
Let me see how I can work that into the flow. Thanks!


Ambrose Bonnaire-Sergeant 
February 1, 2014 6:58 AM
Hi Sam,

Are you familiar of dynalint.lint/print-warning?

That's really the best idea I've come up with.

Thanks,
Ambrose



--
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.
Sam Ritchie 
February 1, 2014 6:54 AM
I added this to the :injections vector of my lein project; it looks 
really helpful, but when compiling in emacs via nRepl, without the 
line number, it's really hard to track down these errors. Is there any 
way that dynalint could (optionally) output more info about where the 
infraction takes place?



Ambrose Bonnaire-Sergeant 
February 1, 2014 6:38 AM
Hi,

If you're interested in refactoring out instances of (zipmap (keys m) 
(vals m)),

then dynalint 0.1.2 may help.


|[com.ambrosebs/dynalint "0.1.2"]|

I've added a simplistic case that warns if a 
clojure.lang.APersistentMap$KeysSeq or ValsSeq is passed to zipmap.


user=> (require '[dynalint.lint :as dyn])
nil
user=> (dyn/lint)
:ok
user=> (let [m {1 2 3 4}
  #_=>   ks (keys m)
  #_=>   vs (vals m)]
  #_=>   (zipmap ks vs))
WARNING (Dynalint id 1):  Should not pass result of clojure.core/keys 
to zipmap
WARNING (Dynalint id 2):  Should not pass result of clojure.core/vals 
to zipmap

{3 4, 1 2}
user=>

Note: dynalint only supports Clojure 1.5.1.

dynalint README 
dynalint CHANGELOG 

lein-dynalint README 

Thanks,
Ambrose
--
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.


--
Sam Ritchie (@sritchie)
Paddleguru Co-Founder
703.863.8561
www.paddleguru.com 
Twitter // Facebook 



--
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 option

Re: dynalint, lein-dynalint 0.1.2 - Warn on (zipmap (keys m) (vals m))

[Sam Ritchie]

ah, nice. Yeah, that should work.


Ambrose Bonnaire-Sergeant 
February 1, 2014 7:16 AM
I just realised it's undocumented.

(print-warning) prints the latest warning.

(print-warning id) prints the dynalint warning with the corresponding id

(print-warning id depth) also has depth like clojure.repl/pst.

Ditto with print-error.

Thanks,
Ambrose



--
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.
Sam Ritchie 
February 1, 2014 7:14 AM
Let me see how I can work that into the flow. Thanks!


Ambrose Bonnaire-Sergeant 
February 1, 2014 6:58 AM
Hi Sam,

Are you familiar of dynalint.lint/print-warning?

That's really the best idea I've come up with.

Thanks,
Ambrose



--
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.
Sam Ritchie 
February 1, 2014 6:54 AM
I added this to the :injections vector of my lein project; it looks 
really helpful, but when compiling in emacs via nRepl, without the 
line number, it's really hard to track down these errors. Is there any 
way that dynalint could (optionally) output more info about where the 
infraction takes place?



Ambrose Bonnaire-Sergeant 
February 1, 2014 6:38 AM
Hi,

If you're interested in refactoring out instances of (zipmap (keys m) 
(vals m)),

then dynalint 0.1.2 may help.


|[com.ambrosebs/dynalint "0.1.2"]|

I've added a simplistic case that warns if a 
clojure.lang.APersistentMap$KeysSeq or ValsSeq is passed to zipmap.


user=> (require '[dynalint.lint :as dyn])
nil
user=> (dyn/lint)
:ok
user=> (let [m {1 2 3 4}
  #_=>   ks (keys m)
  #_=>   vs (vals m)]
  #_=>   (zipmap ks vs))
WARNING (Dynalint id 1):  Should not pass result of clojure.core/keys 
to zipmap
WARNING (Dynalint id 2):  Should not pass result of clojure.core/vals 
to zipmap

{3 4, 1 2}
user=>

Note: dynalint only supports Clojure 1.5.1.

dynalint README 
dynalint CHANGELOG 

lein-dynalint README 

Thanks,
Ambrose
--
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.


--
Sam Ritchie (@sritchie)
Paddleguru Co-Founder
703.863.8561
www.paddleguru.com 
Twitter // Facebook 



--
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,

Re: dynalint, lein-dynalint 0.1.2 - Warn on (zipmap (keys m) (vals m))

[Ambrose Bonnaire-Sergeant]

For those playing along, it seems (= m (zipmap (keys m) (vals m))) *is*
a valid property to rely on.

http://dev.clojure.org/jira/browse/CLJ-1302?focusedCommentId=33627&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-33627

Thanks,
Ambrose


On Sat, Feb 1, 2014 at 10:22 PM, Sam Ritchie  wrote:

> Thanks for the help! This is great.
>
>   Ambrose Bonnaire-Sergeant 
>  February 1, 2014 7:16 AM
> I just realised it's undocumented.
>
> (print-warning) prints the latest warning.
>
> (print-warning id) prints the dynalint warning with the corresponding id
>
> (print-warning id depth) also has depth like clojure.repl/pst.
>
> Ditto with print-error.
>
> Thanks,
> Ambrose
>
>
>
> --
> 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.
>   Sam Ritchie 
>  February 1, 2014 7:14 AM
>  Let me see how I can work that into the flow. Thanks!
>
>
>   Ambrose Bonnaire-Sergeant 
>  February 1, 2014 6:58 AM
> Hi Sam,
>
> Are you familiar of dynalint.lint/print-warning?
>
> That's really the best idea I've come up with.
>
> Thanks,
> Ambrose
>
>
>
> --
> 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.
>   Sam Ritchie 
>  February 1, 2014 6:54 AM
>  I added this to the :injections vector of my lein project; it looks
> really helpful, but when compiling in emacs via nRepl, without the line
> number, it's really hard to track down these errors. Is there any way that
> dynalint could (optionally) output more info about where the infraction
> takes place?
>
>
>   Ambrose Bonnaire-Sergeant 
>  February 1, 2014 6:38 AM
> Hi,
>
> If you're interested in refactoring out instances of (zipmap (keys m)
> (vals m)),
> then dynalint 0.1.2 may help.
>
>
> [com.ambrosebs/dynalint "0.1.2"]
>
> I've added a simplistic case that warns if a
> clojure.lang.APersistentMap$KeysSeq or ValsSeq is passed to zipmap.
>
> user=> (require '[dynalint.lint :as dyn])
> nil
> user=> (dyn/lint)
> :ok
> user=> (let [m {1 2 3 4}
>   #_=>   ks (keys m)
>   #_=>   vs (vals m)]
>   #_=>   (zipmap ks vs))
> WARNING (Dynalint id 1):  Should not pass result of clojure.core/keys to
> zipmap
> WARNING (Dynalint id 2):  Should not pass result of clojure.core/vals to
> zipmap
> {3 4, 1 2}
> user=>
>
> Note: dynalint only supports Clojure 1.5.1.
>
> dynalint README 
> dynalint CHANGELOG 
>
> lein-dynalint README 
>
> Thanks,
> Ambrose
> --
> 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.
>
>
> --
> Sam Ritchie (@sritchie)
>  Paddleguru Co-Founder
> 703.863.8561
> www.paddleguru.com
> Twitter  // 
> Facebook
>
> --
> 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 fr

Re: order of returned values from keys and vals

[Sam Ritchie]

Looks like Rich just chimed in with:

"keys order == vals order == seq order "


Matching Socks 
January 31, 2014 7:31 PM
Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and vals 
consistency not mentioned in docstring" was declined, with the comment 
"The absence of this property in the docs is correct. You should not 
rely on this."




On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
--
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.


--
Sam Ritchie (@sritchie)
Paddleguru Co-Founder
703.863.8561
www.paddleguru.com 
Twitter // Facebook 



--
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.
<>

Re: [ANN] clj-refactor.el 0.10.0

[adrians]

Really cool stuff, guys. Are you considering a Light Table version as well?

-- 
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.

Re: [ANN] clj-refactor.el 0.10.0

[Alex Baranosky]

adrians,

Personally, for my part in clj-refactor.el, I don't have any interest in
porting it to Light Table. The project depends pretty heavily on other
Emacs packages such as paredit, multiple-cursors, and yas-snippets, so it's
not trivial to port.


On Sat, Feb 1, 2014 at 11:22 AM, adrians  wrote:

> Really cool stuff, guys. Are you considering a Light Table version as well?
>
> --
> 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.
>

-- 
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.

Re: [ANN] clj-refactor.el 0.10.0

[Magnar Sveen]

Sorry, mate. It's not about cornering the market in clojure refactorings - 
it's just scratching our own itch, and hopefully other people find it 
useful too.

I'm a little surprised Light Table doesn't offer these things already. 
Isn't it a Clojure-centric editor?

On Saturday, February 1, 2014 8:22:53 PM UTC+1, adrians wrote:
>
> Really cool stuff, guys. Are you considering a Light Table version as well?
>

-- 
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.

Re: data-readers, spyscope

[dgrnbrg]

I have reproduced your issue--it is very strange, as on some of my machines 
spyscope works, and others, it fails the same as it does for you. This 
makes me think I am inadvertently relying on an unknown implementation 
detail. I have now observed that even when spyscope gets loaded into 
*data-readers* and is required, it still complains:

user=> (require 'spyscope.core)
nil
user=> *data-readers*
{base64 #'datomic.codec/base-64-literal, db/fn 
#'datomic.function/construct, db/id #'datomic.db/id-literal, spy/t 
#'spyscope.core/trace, spy/d #'spyscope.core/print-log-detailed, spy/p 
#'spyscope.core/print-log}
user=> #spy/d (println "hi")
#

On Saturday, February 1, 2014 8:12:53 AM UTC-5, Dave Tenny wrote:
>
> Java 1.7.0.45
> Lein 2.3.4
> Clojure 1.5.1
>
> I'm trying to use https://github.com/dgrnbrg/spyscope and have put the 
> documented bits in my ~/.lein/profiles.clj
> but cannot get it to work.
>
> {:user {:dependencies [...  [spyscope "0.1.4"] ...]
> :injections [(require 'spyscope.core)
>  ]}}
>
> But when I do 'lein repl'
> *data-readers* doesn't contain the required mappings to the spy 
> definitions.
>
> If at the REPL I try something like
>
> (set! *data-readers* '{spy/p spyscope.core/print-log})
>
> and then
>
> #spy/p "abc"
>
> I get 
>
> RuntimeException No dispatch macro for: s 
>  clojure.lang.Util.runtimeException (Util.java:219)
>
>
> What's the proper way to make spyscope work for all lein user profiles?
>
>
>
>

-- 
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.

Re: order of returned values from keys and vals

[Justin Smith]

Realistically, how many situations are there where running keys and vals 
independently is preferable to running seq once and using the two element 
vectors that returns?

Usually this way one can avoid walking the whole thing twice.

(into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is representative of 
the idiom I usually use. As a bonus, into uses transients, which can create 
the resulting structure in fewer cycles / less time.

On Saturday, February 1, 2014 10:00:33 AM UTC-8, Sam Ritchie wrote:
>
> Looks like Rich just chimed in with:
>
> "keys order == vals order == seq order "
>
>   Matching Socks 
>  January 31, 2014 7:31 PM
> Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and vals 
> consistency not mentioned in docstring" was declined, with the comment "The 
> absence of this property in the docs is correct. You should not rely on 
> this."
>
>
>
> On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
> -- 
> 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 
> 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 
> 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 .
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>
> -- 
> Sam Ritchie (@sritchie)
> Paddleguru Co-Founder
> 703.863.8561
> www.paddleguru.com
> Twitter  // 
> Facebook
>  

-- 
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.

Re: order of returned values from keys and vals

[Ambrose Bonnaire-Sergeant]

zipmap could also potentially use transients (which would be a nice
addition).

keys/vals are also lazy, so I would be surprised if there was any
performance
difference with walking the seq "twice".

Thanks,
Ambrose

On Sun, Feb 2, 2014 at 11:35 AM, Justin Smith  wrote:

> Realistically, how many situations are there where running keys and vals
> independently is preferable to running seq once and using the two element
> vectors that returns?
>
> Usually this way one can avoid walking the whole thing twice.
>
> (into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is representative of
> the idiom I usually use. As a bonus, into uses transients, which can create
> the resulting structure in fewer cycles / less time.
>
>
> On Saturday, February 1, 2014 10:00:33 AM UTC-8, Sam Ritchie wrote:
>
>> Looks like Rich just chimed in with:
>>
>> "keys order == vals order == seq order "
>>
>>   Matching Socks
>>  January 31, 2014 7:31 PM
>> Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and vals
>> consistency not mentioned in docstring" was declined, with the comment "The
>> absence of this property in the docs is correct. You should not rely on
>> this."
>>
>>
>>
>> On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
>> --
>> 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
>>
>> 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
>>
>> 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.
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>> --
>> Sam Ritchie (@sritchie)
>>  Paddleguru Co-Founder
>> 703.863.8561
>> www.paddleguru.com
>> Twitter  // 
>> Facebook
>>
>  --
> 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.
>

-- 
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.

Re: order of returned values from keys and vals

[Michał Marczyk]

On 2 February 2014 04:54, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:

> zipmap could also potentially use transients (which would be a nice
> addition).
>

My patch for this has been waiting in JIRA since end of May 2012:

http://dev.clojure.org/jira/browse/CLJ-1005

Cheers,
Michał


>
> keys/vals are also lazy, so I would be surprised if there was any
> performance
> difference with walking the seq "twice".
>
> Thanks,
> Ambrose
>
>
> On Sun, Feb 2, 2014 at 11:35 AM, Justin Smith wrote:
>
>> Realistically, how many situations are there where running keys and vals
>> independently is preferable to running seq once and using the two element
>> vectors that returns?
>>
>> Usually this way one can avoid walking the whole thing twice.
>>
>> (into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is representative of
>> the idiom I usually use. As a bonus, into uses transients, which can create
>> the resulting structure in fewer cycles / less time.
>>
>>
>> On Saturday, February 1, 2014 10:00:33 AM UTC-8, Sam Ritchie wrote:
>>
>>> Looks like Rich just chimed in with:
>>>
>>> "keys order == vals order == seq order "
>>>
>>>   Matching Socks
>>>  January 31, 2014 7:31 PM
>>> Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and vals
>>> consistency not mentioned in docstring" was declined, with the comment "The
>>> absence of this property in the docs is correct. You should not rely on
>>> this."
>>>
>>>
>>>
>>> On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
>>> --
>>> 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
>>>
>>> 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
>>>
>>> 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.
>>>
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>> --
>>> Sam Ritchie (@sritchie)
>>>  Paddleguru Co-Founder
>>> 703.863.8561
>>> www.paddleguru.com
>>> Twitter  // 
>>> Facebook
>>>
>>  --
>> 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.
>>
>
>  --
> 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.
>

-- 
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.

Re: order of returned values from keys and vals

[Justin Smith]

user> (class (keys {:a 0 :b 1}))
clojure.lang.APersistentMap$KeySeq

Are you sure PersistentMap$KeySeq is lazy? I don't really get how a lazy 
sequence over an associative would work in Clojure (at least as clojure 
exists now).

Pardon my ignorance but if this is producing a lazy result, how is it doing 
so?
https://github.com/clojure/clojure/blob/dff9600387b962f16fc78e6477e10e34651fd366/src/jvm/clojure/lang/APersistentMap.java#L134

On Saturday, February 1, 2014 7:54:32 PM UTC-8, Ambrose Bonnaire-Sergeant 
wrote:
>
> zipmap could also potentially use transients (which would be a nice 
> addition).
>
> keys/vals are also lazy, so I would be surprised if there was any 
> performance
> difference with walking the seq "twice".
>
> Thanks,
> Ambrose
>
> On Sun, Feb 2, 2014 at 11:35 AM, Justin Smith 
> > wrote:
>
>> Realistically, how many situations are there where running keys and vals 
>> independently is preferable to running seq once and using the two element 
>> vectors that returns?
>>
>> Usually this way one can avoid walking the whole thing twice.
>>
>> (into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is representative of 
>> the idiom I usually use. As a bonus, into uses transients, which can create 
>> the resulting structure in fewer cycles / less time.
>>
>>
>> On Saturday, February 1, 2014 10:00:33 AM UTC-8, Sam Ritchie wrote:
>>
>>> Looks like Rich just chimed in with:
>>>
>>> "keys order == vals order == seq order "
>>>
>>>   Matching Socks
>>>  January 31, 2014 7:31 PM
>>> Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and vals 
>>> consistency not mentioned in docstring" was declined, with the comment "The 
>>> absence of this property in the docs is correct. You should not rely on 
>>> this."
>>>
>>>
>>>
>>> On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
>>> -- 
>>> 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
>>>
>>> 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
>>>
>>> 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.
>>>
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>
>>> -- 
>>> Sam Ritchie (@sritchie)
>>>  Paddleguru Co-Founder
>>> 703.863.8561
>>> www.paddleguru.com
>>> Twitter  // 
>>> Facebook
>>>  
>>  -- 
>> 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
>> 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 
>> 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 .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
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.

Re: order of returned values from keys and vals

[Michał Marczyk]

On 2 February 2014 05:14, Justin Smith  wrote:

> Pardon my ignorance but if this is producing a lazy result, how is it
> doing so?
>
> https://github.com/clojure/clojure/blob/dff9600387b962f16fc78e6477e10e34651fd366/src/jvm/clojure/lang/APersistentMap.java#L134
>

APersistentMap's KeySeq.create and ValSeq.create are pretty much equivalent
to (map key entry-seq) and (map val entry-seq). The logic producing
entry-seq lives in the individual map types and is indeed lazy.

Cheers,
Michał


>
> On Saturday, February 1, 2014 7:54:32 PM UTC-8, Ambrose Bonnaire-Sergeant
> wrote:
>
>> zipmap could also potentially use transients (which would be a nice
>> addition).
>>
>> keys/vals are also lazy, so I would be surprised if there was any
>> performance
>> difference with walking the seq "twice".
>>
>> Thanks,
>> Ambrose
>>
>>
>> On Sun, Feb 2, 2014 at 11:35 AM, Justin Smith  wrote:
>>
>>> Realistically, how many situations are there where running keys and vals
>>> independently is preferable to running seq once and using the two element
>>> vectors that returns?
>>>
>>> Usually this way one can avoid walking the whole thing twice.
>>>
>>> (into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is representative
>>> of the idiom I usually use. As a bonus, into uses transients, which can
>>> create the resulting structure in fewer cycles / less time.
>>>
>>>
>>> On Saturday, February 1, 2014 10:00:33 AM UTC-8, Sam Ritchie wrote:
>>>
 Looks like Rich just chimed in with:

 "keys order == vals order == seq order "

   Matching Socks
  January 31, 2014 7:31 PM
 Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and vals
 consistency not mentioned in docstring" was declined, with the comment "The
 absence of this property in the docs is correct. You should not rely on
 this."



 On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
 --
 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

 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

 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.

 For more options, visit https://groups.google.com/groups/opt_out.


 --
 Sam Ritchie (@sritchie)
  Paddleguru Co-Founder
 703.863.8561
 www.paddleguru.com
 Twitter  // 
 Facebook

>>>  --
>>> 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
>>> 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
>>> 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.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>  --
> 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.
>

-- 
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+unsubsc

Re: order of returned values from keys and vals

[Ambrose Bonnaire-Sergeant]

Thanks Michał, voted.

Ambrose


On Sun, Feb 2, 2014 at 12:13 PM, Michał Marczyk wrote:

> On 2 February 2014 04:54, Ambrose Bonnaire-Sergeant <
> abonnaireserge...@gmail.com> wrote:
>
>> zipmap could also potentially use transients (which would be a nice
>> addition).
>>
>
> My patch for this has been waiting in JIRA since end of May 2012:
>
> http://dev.clojure.org/jira/browse/CLJ-1005
>
> Cheers,
> Michał
>
>
>>
>> keys/vals are also lazy, so I would be surprised if there was any
>> performance
>> difference with walking the seq "twice".
>>
>> Thanks,
>> Ambrose
>>
>>
>> On Sun, Feb 2, 2014 at 11:35 AM, Justin Smith wrote:
>>
>>> Realistically, how many situations are there where running keys and vals
>>> independently is preferable to running seq once and using the two element
>>> vectors that returns?
>>>
>>> Usually this way one can avoid walking the whole thing twice.
>>>
>>> (into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is representative
>>> of the idiom I usually use. As a bonus, into uses transients, which can
>>> create the resulting structure in fewer cycles / less time.
>>>
>>>
>>> On Saturday, February 1, 2014 10:00:33 AM UTC-8, Sam Ritchie wrote:
>>>
 Looks like Rich just chimed in with:

 "keys order == vals order == seq order "

Matching Socks
  January 31, 2014 7:31 PM
 Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and vals
 consistency not mentioned in docstring" was declined, with the comment "The
 absence of this property in the docs is correct. You should not rely on
 this."



 On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
 --
 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

 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

 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.

 For more options, visit https://groups.google.com/groups/opt_out.


 --
 Sam Ritchie (@sritchie)
  Paddleguru Co-Founder
 703.863.8561
 www.paddleguru.com
 Twitter  // 
 Facebook

>>>  --
>>> 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.
>>>
>>
>>  --
>> 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.
>>
>
>  --
> 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.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To 

Re: order of returned values from keys and vals

[Ambrose Bonnaire-Sergeant]

It also might help to notice KeySeq defines first/next, but never
explicitly walks the seq.

That's left to the user of the KeySeq.

Thanks,
Ambrose


On Sun, Feb 2, 2014 at 12:18 PM, Michał Marczyk wrote:

> On 2 February 2014 05:14, Justin Smith  wrote:
>
>> Pardon my ignorance but if this is producing a lazy result, how is it
>> doing so?
>>
>> https://github.com/clojure/clojure/blob/dff9600387b962f16fc78e6477e10e34651fd366/src/jvm/clojure/lang/APersistentMap.java#L134
>>
>
> APersistentMap's KeySeq.create and ValSeq.create are pretty much
> equivalent to (map key entry-seq) and (map val entry-seq). The logic
> producing entry-seq lives in the individual map types and is indeed lazy.
>
> Cheers,
> Michał
>
>
>>
>> On Saturday, February 1, 2014 7:54:32 PM UTC-8, Ambrose Bonnaire-Sergeant
>> wrote:
>>
>>> zipmap could also potentially use transients (which would be a nice
>>> addition).
>>>
>>> keys/vals are also lazy, so I would be surprised if there was any
>>> performance
>>> difference with walking the seq "twice".
>>>
>>> Thanks,
>>> Ambrose
>>>
>>>
>>> On Sun, Feb 2, 2014 at 11:35 AM, Justin Smith wrote:
>>>
 Realistically, how many situations are there where running keys and
 vals independently is preferable to running seq once and using the two
 element vectors that returns?

 Usually this way one can avoid walking the whole thing twice.

 (into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is representative
 of the idiom I usually use. As a bonus, into uses transients, which can
 create the resulting structure in fewer cycles / less time.


 On Saturday, February 1, 2014 10:00:33 AM UTC-8, Sam Ritchie wrote:

> Looks like Rich just chimed in with:
>
> "keys order == vals order == seq order "
>
>   Matching Socks
>  January 31, 2014 7:31 PM
> Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and vals
> consistency not mentioned in docstring" was declined, with the comment 
> "The
> absence of this property in the docs is correct. You should not rely on
> this."
>
>
>
> On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
> --
> 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
>
> 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
>
> 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.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> Sam Ritchie (@sritchie)
>  Paddleguru Co-Founder
> 703.863.8561
> www.paddleguru.com
> Twitter  // 
> Facebook
>
  --
 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
 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
 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.
 For more options, visit https://groups.google.com/groups/opt_out.

>>>
>>>  --
>> 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.
>>
>
>  --
> 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 un

Re: order of returned values from keys and vals

[Chouser]

There's no substitute for measurement.

(defn maptest [f]
  (let [m (apply hash-map (range 40))]
(time (dotimes [_ 10] (f m)))
(f m)))

(maptest #(zipmap (keys %) (map inc (vals %
; "Elapsed time: 1405.890766 msecs"
;=> {0 2, 32 34, 2 4, 34 36, 4 6, 36 38, 6 8, 38 40, 8 10, 10 12, 12 14, 14
16, 16 18, 18 20, 20 22, 22 24, 24 26, 26 28, 28 30, 30 32}

(maptest #(into {} (map (fn [[k v]] [k (inc v)]) %)))
; "Elapsed time: 1433.270362 msecs"
;=> {0 2, 32 34, 2 4, 34 36, 4 6, 36 38, 6 8, 38 40, 8 10, 10 12, 12 14, 14
16, 16 18, 18 20, 20 22, 22 24, 24 26, 26 28, 28 30, 30 32}

(maptest #(reduce-kv (fn [m k v] (assoc m k (inc v))) {} %))
; "Elapsed time: 649.452695 msecs"
;=> {0 2, 32 34, 2 4, 34 36, 4 6, 36 38, 6 8, 38 40, 8 10, 10 12, 12 14, 14
16, 16 18, 18 20, 20 22, 22 24, 24 26, 26 28, 28 30, 30 32}

These results are fairly robust in relation to each other for other sizes
of smallish maps.

--Chouser


On Sat, Feb 1, 2014 at 10:35 PM, Justin Smith  wrote:

> Realistically, how many situations are there where running keys and vals
> independently is preferable to running seq once and using the two element
> vectors that returns?
>
> Usually this way one can avoid walking the whole thing twice.
>
> (into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is representative of
> the idiom I usually use. As a bonus, into uses transients, which can create
> the resulting structure in fewer cycles / less time.
>
>
> On Saturday, February 1, 2014 10:00:33 AM UTC-8, Sam Ritchie wrote:
>
>> Looks like Rich just chimed in with:
>>
>> "keys order == vals order == seq order "
>>
>>   Matching Socks
>>  January 31, 2014 7:31 PM
>> Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and vals
>> consistency not mentioned in docstring" was declined, with the comment "The
>> absence of this property in the docs is correct. You should not rely on
>> this."
>>
>>
>>
>> On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
>> --
>> 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
>>
>> 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
>>
>> 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.
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>> --
>> Sam Ritchie (@sritchie)
>> Paddleguru Co-Founder
>> 703.863.8561
>> www.paddleguru.com
>> Twitter  // 
>> Facebook
>>
>


-- 
--Chouser

-- 
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.

Re: order of returned values from keys and vals

[Michał Marczyk]

That doesn't mean that we're not walking the seq twice, however. keys and
vals work off of separate calls to seq on the map, which of necessity
produce distinct seq objects (otherwise traversing a seq over a map would
permanently increase its memory consumption).


On 2 February 2014 05:18, Michał Marczyk  wrote:

> On 2 February 2014 05:14, Justin Smith  wrote:
>
>> Pardon my ignorance but if this is producing a lazy result, how is it
>> doing so?
>>
>> https://github.com/clojure/clojure/blob/dff9600387b962f16fc78e6477e10e34651fd366/src/jvm/clojure/lang/APersistentMap.java#L134
>>
>
> APersistentMap's KeySeq.create and ValSeq.create are pretty much
> equivalent to (map key entry-seq) and (map val entry-seq). The logic
> producing entry-seq lives in the individual map types and is indeed lazy.
>
> Cheers,
> Michał
>
>
>>
>> On Saturday, February 1, 2014 7:54:32 PM UTC-8, Ambrose Bonnaire-Sergeant
>> wrote:
>>
>>> zipmap could also potentially use transients (which would be a nice
>>> addition).
>>>
>>> keys/vals are also lazy, so I would be surprised if there was any
>>> performance
>>> difference with walking the seq "twice".
>>>
>>> Thanks,
>>> Ambrose
>>>
>>>
>>> On Sun, Feb 2, 2014 at 11:35 AM, Justin Smith wrote:
>>>
 Realistically, how many situations are there where running keys and
 vals independently is preferable to running seq once and using the two
 element vectors that returns?

 Usually this way one can avoid walking the whole thing twice.

 (into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is representative
 of the idiom I usually use. As a bonus, into uses transients, which can
 create the resulting structure in fewer cycles / less time.


 On Saturday, February 1, 2014 10:00:33 AM UTC-8, Sam Ritchie wrote:

> Looks like Rich just chimed in with:
>
> "keys order == vals order == seq order "
>
>   Matching Socks
>  January 31, 2014 7:31 PM
> Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and vals
> consistency not mentioned in docstring" was declined, with the comment 
> "The
> absence of this property in the docs is correct. You should not rely on
> this."
>
>
>
> On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
> --
> 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
>
> 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
>
> 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.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> Sam Ritchie (@sritchie)
>  Paddleguru Co-Founder
> 703.863.8561
> www.paddleguru.com
> Twitter  // 
> Facebook
>
  --
 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
 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
 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.
 For more options, visit https://groups.google.com/groups/opt_out.

>>>
>>>  --
>> 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.
>>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.

Re: order of returned values from keys and vals

[Justin Smith]

Excellent, thanks for the information.

I just did a benchmark of zipmap over keys and vals vs. into {} over a map, 
and despite my intuition, they are actually nearly identical in 
performance. So if zipmap were using transients zipmap with keys and vals 
would actually be the better performing option here.

user> (def testmap (zipmap (range 1000) (range 2000 3000)))
user> (crit/bench (zipmap (keys testmap) (map inc (vals testmap
Evaluation count : 150900 in 60 samples of 2515 calls.
 Execution time mean : 401.458681 µs
Execution time std-deviation : 4.912358 µs
   Execution time lower quantile : 393.882254 µs ( 2.5%)
   Execution time upper quantile : 409.534676 µs (97.5%)
   Overhead used : 2.203076 ns

Found 1 outliers in 60 samples (1.6667 %)
low-severe 1 (1.6667 %)
 Variance from outliers : 1.6389 % Variance is slightly inflated by outliers
nil
user> (crit/bench (into {} (map (fn [[k v]] [k (inc v)]) testmap)))
Evaluation count : 150060 in 60 samples of 2501 calls.
 Execution time mean : 400.684810 µs
Execution time std-deviation : 3.489015 µs
   Execution time lower quantile : 395.127605 µs ( 2.5%)
   Execution time upper quantile : 407.132405 µs (97.5%)
   Overhead used : 2.203076 ns
nil


On Saturday, February 1, 2014 8:22:28 PM UTC-8, Ambrose Bonnaire-Sergeant 
wrote:
>
> It also might help to notice KeySeq defines first/next, but never 
> explicitly walks the seq.
>
> That's left to the user of the KeySeq.
>
> Thanks,
> Ambrose
>
>
> On Sun, Feb 2, 2014 at 12:18 PM, Michał Marczyk 
> 
> > wrote:
>
>> On 2 February 2014 05:14, Justin Smith > >wrote:
>>
>>> Pardon my ignorance but if this is producing a lazy result, how is it 
>>> doing so?
>>>
>>> https://github.com/clojure/clojure/blob/dff9600387b962f16fc78e6477e10e34651fd366/src/jvm/clojure/lang/APersistentMap.java#L134
>>>
>>
>> APersistentMap's KeySeq.create and ValSeq.create are pretty much 
>> equivalent to (map key entry-seq) and (map val entry-seq). The logic 
>> producing entry-seq lives in the individual map types and is indeed lazy.
>>
>> Cheers,
>> Michał
>>  
>>
>>>
>>> On Saturday, February 1, 2014 7:54:32 PM UTC-8, Ambrose 
>>> Bonnaire-Sergeant wrote:
>>>
 zipmap could also potentially use transients (which would be a nice 
 addition).

 keys/vals are also lazy, so I would be surprised if there was any 
 performance
 difference with walking the seq "twice".

 Thanks,
 Ambrose


 On Sun, Feb 2, 2014 at 11:35 AM, Justin Smith wrote:

> Realistically, how many situations are there where running keys and 
> vals independently is preferable to running seq once and using the two 
> element vectors that returns?
>
> Usually this way one can avoid walking the whole thing twice.
>
> (into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is representative 
> of the idiom I usually use. As a bonus, into uses transients, which can 
> create the resulting structure in fewer cycles / less time.
>
>
> On Saturday, February 1, 2014 10:00:33 AM UTC-8, Sam Ritchie wrote:
>
>> Looks like Rich just chimed in with:
>>
>> "keys order == vals order == seq order "
>>
>>   Matching Socks
>>  January 31, 2014 7:31 PM
>> Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and vals 
>> consistency not mentioned in docstring" was declined, with the comment 
>> "The 
>> absence of this property in the docs is correct. You should not rely on 
>> this."
>>
>>
>>
>> On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
>> -- 
>> 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
>>
>> 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
>>
>> 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.
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>
>> -- 
>> Sam Ritchie (@sritchie)
>>  Paddleguru Co-Founder
>> 703.863.8561
>> www.paddleguru.com
>> Twitter  // 
>> Facebook
>>  
>  -- 
> 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
> Note that posts from new members are moderated - please be patient 
> with you

Re: order of returned values from keys and vals

[Michał Marczyk]

I'd expect

(persistent!
  (reduce-kv (fn [acc k v] (assoc! acc k (inc v)))
(transient {})
input-map))

to be the fastest solution.

Cheers,
Michał


On 2 February 2014 05:30, Justin Smith  wrote:

> Excellent, thanks for the information.
>
> I just did a benchmark of zipmap over keys and vals vs. into {} over a
> map, and despite my intuition, they are actually nearly identical in
> performance. So if zipmap were using transients zipmap with keys and vals
> would actually be the better performing option here.
>
> user> (def testmap (zipmap (range 1000) (range 2000 3000)))
> user> (crit/bench (zipmap (keys testmap) (map inc (vals testmap
> Evaluation count : 150900 in 60 samples of 2515 calls.
>  Execution time mean : 401.458681 µs
> Execution time std-deviation : 4.912358 µs
>Execution time lower quantile : 393.882254 µs ( 2.5%)
>Execution time upper quantile : 409.534676 µs (97.5%)
>Overhead used : 2.203076 ns
>
> Found 1 outliers in 60 samples (1.6667 %)
> low-severe 1 (1.6667 %)
>  Variance from outliers : 1.6389 % Variance is slightly inflated by
> outliers
> nil
> user> (crit/bench (into {} (map (fn [[k v]] [k (inc v)]) testmap)))
> Evaluation count : 150060 in 60 samples of 2501 calls.
>  Execution time mean : 400.684810 µs
> Execution time std-deviation : 3.489015 µs
>Execution time lower quantile : 395.127605 µs ( 2.5%)
>Execution time upper quantile : 407.132405 µs (97.5%)
>Overhead used : 2.203076 ns
> nil
>
>
> On Saturday, February 1, 2014 8:22:28 PM UTC-8, Ambrose Bonnaire-Sergeant
> wrote:
>
>> It also might help to notice KeySeq defines first/next, but never
>> explicitly walks the seq.
>>
>> That's left to the user of the KeySeq.
>>
>> Thanks,
>> Ambrose
>>
>>
>> On Sun, Feb 2, 2014 at 12:18 PM, Michał Marczyk wrote:
>>
>> On 2 February 2014 05:14, Justin Smith  wrote:
>>>
 Pardon my ignorance but if this is producing a lazy result, how is it
 doing so?
 https://github.com/clojure/clojure/blob/dff9600387b962f16fc78e6477e10e
 34651fd366/src/jvm/clojure/lang/APersistentMap.java#L134

>>>
>>> APersistentMap's KeySeq.create and ValSeq.create are pretty much
>>> equivalent to (map key entry-seq) and (map val entry-seq). The logic
>>> producing entry-seq lives in the individual map types and is indeed lazy.
>>>
>>> Cheers,
>>> Michał
>>>
>>>

 On Saturday, February 1, 2014 7:54:32 PM UTC-8, Ambrose
 Bonnaire-Sergeant wrote:

> zipmap could also potentially use transients (which would be a nice
> addition).
>
> keys/vals are also lazy, so I would be surprised if there was any
> performance
> difference with walking the seq "twice".
>
> Thanks,
> Ambrose
>
>
> On Sun, Feb 2, 2014 at 11:35 AM, Justin Smith wrote:
>
>> Realistically, how many situations are there where running keys and
>> vals independently is preferable to running seq once and using the two
>> element vectors that returns?
>>
>> Usually this way one can avoid walking the whole thing twice.
>>
>> (into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is
>> representative of the idiom I usually use. As a bonus, into uses
>> transients, which can create the resulting structure in fewer cycles / 
>> less
>> time.
>>
>>
>> On Saturday, February 1, 2014 10:00:33 AM UTC-8, Sam Ritchie wrote:
>>
>>> Looks like Rich just chimed in with:
>>>
>>> "keys order == vals order == seq order "
>>>
>>>   Matching Socks
>>>  January 31, 2014 7:31 PM
>>> Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and
>>> vals consistency not mentioned in docstring" was declined, with the 
>>> comment
>>> "The absence of this property in the docs is correct. You should not 
>>> rely
>>> on this."
>>>
>>>
>>>
>>> On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
>>> --
>>> 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
>>>
>>> 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
>>>
>>> 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.
>>>
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>> --
>>> Sam Ritchie (@sritchie)
>>>  Paddleguru Co-Founder
>>> 703.863.8561
>>> www.paddleguru.com
>>> Twitter 

Re: order of returned values from keys and vals

[Michał Marczyk]

Oh, sorry, for some reason Gmail didn't alert me to some of the recent
messages coming in while I was viewing this thread.


On 2 February 2014 05:32, Michał Marczyk  wrote:

> I'd expect
>
> (persistent!
>   (reduce-kv (fn [acc k v] (assoc! acc k (inc v)))
> (transient {})
> input-map))
>
> to be the fastest solution.
>
> Cheers,
> Michał
>
>
> On 2 February 2014 05:30, Justin Smith  wrote:
>
>> Excellent, thanks for the information.
>>
>> I just did a benchmark of zipmap over keys and vals vs. into {} over a
>> map, and despite my intuition, they are actually nearly identical in
>> performance. So if zipmap were using transients zipmap with keys and vals
>> would actually be the better performing option here.
>>
>> user> (def testmap (zipmap (range 1000) (range 2000 3000)))
>> user> (crit/bench (zipmap (keys testmap) (map inc (vals testmap
>> Evaluation count : 150900 in 60 samples of 2515 calls.
>>  Execution time mean : 401.458681 µs
>> Execution time std-deviation : 4.912358 µs
>>Execution time lower quantile : 393.882254 µs ( 2.5%)
>>Execution time upper quantile : 409.534676 µs (97.5%)
>>Overhead used : 2.203076 ns
>>
>> Found 1 outliers in 60 samples (1.6667 %)
>> low-severe 1 (1.6667 %)
>>  Variance from outliers : 1.6389 % Variance is slightly inflated by
>> outliers
>> nil
>> user> (crit/bench (into {} (map (fn [[k v]] [k (inc v)]) testmap)))
>> Evaluation count : 150060 in 60 samples of 2501 calls.
>>  Execution time mean : 400.684810 µs
>> Execution time std-deviation : 3.489015 µs
>>Execution time lower quantile : 395.127605 µs ( 2.5%)
>>Execution time upper quantile : 407.132405 µs (97.5%)
>>Overhead used : 2.203076 ns
>> nil
>>
>>
>> On Saturday, February 1, 2014 8:22:28 PM UTC-8, Ambrose Bonnaire-Sergeant
>> wrote:
>>
>>> It also might help to notice KeySeq defines first/next, but never
>>> explicitly walks the seq.
>>>
>>> That's left to the user of the KeySeq.
>>>
>>> Thanks,
>>> Ambrose
>>>
>>>
>>> On Sun, Feb 2, 2014 at 12:18 PM, Michał Marczyk wrote:
>>>
>>> On 2 February 2014 05:14, Justin Smith  wrote:

> Pardon my ignorance but if this is producing a lazy result, how is it
> doing so?
> https://github.com/clojure/clojure/blob/dff9600387b962f16fc78e6477e10e
> 34651fd366/src/jvm/clojure/lang/APersistentMap.java#L134
>

 APersistentMap's KeySeq.create and ValSeq.create are pretty much
 equivalent to (map key entry-seq) and (map val entry-seq). The logic
 producing entry-seq lives in the individual map types and is indeed lazy.

 Cheers,
 Michał


>
> On Saturday, February 1, 2014 7:54:32 PM UTC-8, Ambrose
> Bonnaire-Sergeant wrote:
>
>> zipmap could also potentially use transients (which would be a nice
>> addition).
>>
>> keys/vals are also lazy, so I would be surprised if there was any
>> performance
>> difference with walking the seq "twice".
>>
>> Thanks,
>> Ambrose
>>
>>
>> On Sun, Feb 2, 2014 at 11:35 AM, Justin Smith wrote:
>>
>>> Realistically, how many situations are there where running keys and
>>> vals independently is preferable to running seq once and using the two
>>> element vectors that returns?
>>>
>>> Usually this way one can avoid walking the whole thing twice.
>>>
>>> (into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is
>>> representative of the idiom I usually use. As a bonus, into uses
>>> transients, which can create the resulting structure in fewer cycles / 
>>> less
>>> time.
>>>
>>>
>>> On Saturday, February 1, 2014 10:00:33 AM UTC-8, Sam Ritchie wrote:
>>>
 Looks like Rich just chimed in with:

 "keys order == vals order == seq order "

   Matching Socks
  January 31, 2014 7:31 PM
 Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and
 vals consistency not mentioned in docstring" was declined, with the 
 comment
 "The absence of this property in the docs is correct. You should not 
 rely
 on this."



 On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
 --
 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

 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

 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 rece

Re: order of returned values from keys and vals

[Justin Smith]

In the same repl as the above benchmarks, and yes, this is definitely the 
best so far. I'll have to remember reduce-kv for future usage.

user> (crit/bench (persistent!
   (reduce-kv (fn [acc k v] (assoc! acc k (inc v)))
  (transient {})
  testmap)))
Evaluation count : 369540 in 60 samples of 6159 calls.
 Execution time mean : 163.806692 µs
Execution time std-deviation : 1.090315 µs
   Execution time lower quantile : 162.145827 µs ( 2.5%)
   Execution time upper quantile : 165.628330 µs (97.5%)
   Overhead used : 2.203076 ns
nil


On Saturday, February 1, 2014 8:34:52 PM UTC-8, Michał Marczyk wrote:
>
> Oh, sorry, for some reason Gmail didn't alert me to some of the recent 
> messages coming in while I was viewing this thread.
>
>
> On 2 February 2014 05:32, Michał Marczyk 
> > wrote:
>
>> I'd expect
>>
>> (persistent!
>>   (reduce-kv (fn [acc k v] (assoc! acc k (inc v)))
>> (transient {})
>> input-map))
>>
>> to be the fastest solution.
>>
>> Cheers,
>> Michał
>>
>>
>> On 2 February 2014 05:30, Justin Smith > >wrote:
>>
>>> Excellent, thanks for the information.
>>>
>>> I just did a benchmark of zipmap over keys and vals vs. into {} over a 
>>> map, and despite my intuition, they are actually nearly identical in 
>>> performance. So if zipmap were using transients zipmap with keys and vals 
>>> would actually be the better performing option here.
>>>
>>> user> (def testmap (zipmap (range 1000) (range 2000 3000)))
>>> user> (crit/bench (zipmap (keys testmap) (map inc (vals testmap
>>> Evaluation count : 150900 in 60 samples of 2515 calls.
>>>  Execution time mean : 401.458681 µs
>>> Execution time std-deviation : 4.912358 µs
>>>Execution time lower quantile : 393.882254 µs ( 2.5%)
>>>Execution time upper quantile : 409.534676 µs (97.5%)
>>>Overhead used : 2.203076 ns
>>>
>>> Found 1 outliers in 60 samples (1.6667 %)
>>> low-severe 1 (1.6667 %)
>>>  Variance from outliers : 1.6389 % Variance is slightly inflated by 
>>> outliers
>>> nil
>>> user> (crit/bench (into {} (map (fn [[k v]] [k (inc v)]) testmap)))
>>> Evaluation count : 150060 in 60 samples of 2501 calls.
>>>  Execution time mean : 400.684810 µs
>>> Execution time std-deviation : 3.489015 µs
>>>Execution time lower quantile : 395.127605 µs ( 2.5%)
>>>Execution time upper quantile : 407.132405 µs (97.5%)
>>>Overhead used : 2.203076 ns
>>> nil
>>>
>>>
>>> On Saturday, February 1, 2014 8:22:28 PM UTC-8, Ambrose 
>>> Bonnaire-Sergeant wrote:
>>>
 It also might help to notice KeySeq defines first/next, but never 
 explicitly walks the seq.

 That's left to the user of the KeySeq.

 Thanks,
 Ambrose


 On Sun, Feb 2, 2014 at 12:18 PM, Michał Marczyk 
 wrote:

 On 2 February 2014 05:14, Justin Smith  wrote:
>
>> Pardon my ignorance but if this is producing a lazy result, how is it 
>> doing so?
>> https://github.com/clojure/clojure/blob/
>> dff9600387b962f16fc78e6477e10e34651fd366/src/jvm/clojure/
>> lang/APersistentMap.java#L134
>>
>
> APersistentMap's KeySeq.create and ValSeq.create are pretty much 
> equivalent to (map key entry-seq) and (map val entry-seq). The logic 
> producing entry-seq lives in the individual map types and is indeed lazy.
>
> Cheers,
> Michał
>  
>
>>
>> On Saturday, February 1, 2014 7:54:32 PM UTC-8, Ambrose 
>> Bonnaire-Sergeant wrote:
>>
>>> zipmap could also potentially use transients (which would be a nice 
>>> addition).
>>>
>>> keys/vals are also lazy, so I would be surprised if there was any 
>>> performance
>>> difference with walking the seq "twice".
>>>
>>> Thanks,
>>> Ambrose
>>>
>>>
>>> On Sun, Feb 2, 2014 at 11:35 AM, Justin Smith wrote:
>>>
 Realistically, how many situations are there where running keys and 
 vals independently is preferable to running seq once and using the two 
 element vectors that returns?

 Usually this way one can avoid walking the whole thing twice.

 (into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is 
 representative of the idiom I usually use. As a bonus, into uses 
 transients, which can create the resulting structure in fewer cycles / 
 less 
 time.


 On Saturday, February 1, 2014 10:00:33 AM UTC-8, Sam Ritchie wrote:

> Looks like Rich just chimed in with:
>
> "keys order == vals order == seq order "
>
>   Matching Socks
>  January 31, 2014 7:31 PM
> Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and 
> vals consistency not mentioned in docstring" was declined, with the 
> comment 
> "The 

webgl and reagent(cljs wrapper for reactjs)

[Sunil S Nandihalli]

Hi Everybody,
 I am new to web-programming but have done some stuff with clojurescript.
Now I was looking add an webgl based canvas to render a cube. I am using
reagent  which is a cljs-wrapper
around reactjs. I am unable to decide, due to my inexperience in both webgl
and web-programming, if I should continue using reagent to add this new
webgl-enabled-canvas or are they fundamentally different in how they handle
things. Any input is very much appreciated.
Thanks
Sunil.

-- 
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.