Re: weird bug with cljs.core.async + macros

[Adam Clements]

I have had a similar thing happen with the core.match/match macro - a lot
of examples simply break when put inside a go block. I thought it might
have been something to do with aot compilation but I'm not sure.

Adam
On 18 Feb 2014 05:33, "t x"  wrote:

> Building on Michal's example, here is a "more minimal example" --
> which also "fails" in Clojure:
>
>
> (ns test
>   (:require [clojure.core.async :as async]))
>
>
> (defmacro silly [obj pat1 body1 other]
>   `(case ~obj
>  ~pat1 ~body1
>  ~other))
>
> (let []
>
>   (def out (java.io.StringWriter.))
>
>   (defn log [& args]
> (doseq [arg args]
>   (.write out (str arg))
>   (.write out "\n")))
>
>
>   (async/   (silly :dog
>  :dog (log "with-go: woof woof")
>  (log "with-go: other"
>
>   (str out))
>
> On Mon, Feb 17, 2014 at 5:14 PM, t x  wrote:
> > Hi Michal,
> >
> >   Does this mean:
> >
> >   (a) the reported behavior is normal (and my bug report is invalid) or
> >
> >   (b) this error happens in both cljs + clojure ?
> >
> > Thanks!
> >
> > On Mon, Feb 17, 2014 at 4:33 PM, Michał Marczyk
> >  wrote:
> >> Just to be clear, the above is a version of t x's bug-report modified
> >> to use a StringWriter instead of console.log.
> >>
> >> Cheers,
> >> Michał
> >>
> >>
> >> On 18 February 2014 01:25, Michał Marczyk 
> wrote:
> >>> The same thing happens in Clojure:
> >>>
> >>> (defmacro silly [object pat1 body1 pat2 body2]
> >>>   `(case (:tag ~object)
> >>>  ~pat1 ~body1
> >>>  ~body2))
> >>>
> >>> (def out (java.io.StringWriter.))
> >>>
> >>> (defn log [& args]
> >>>   (doseq [arg args]
> >>> (.write out (str arg))
> >>> (.write out "\n")))
> >>>
> >>> (defn init []
> >>>   (silly {:tag :dog}
> >>>  :dog (log "without-go: woof woof")
> >>>  cat (log "without-go: unrecognized"))
> >>>   (async/go
> >>>(silly {:tag :dog}
> >>>   :dog (log "with-go: woof woof")
> >>>   cat (log "with-go: unrecognized"
> >>>
> >>> (init)
> >>>
> >>> (print (str out))
> >>> without-go: woof woof
> >>> with-go: woof woof
> >>> with-go: unrecognized
> >>> nil
> >>>
> >>> Cheers,
> >>> Michał
> >>>
> >>>
> >>> On 18 February 2014 01:01, t x  wrote:
>  Thanks for verifying!
> 
>  @tbaldridge: can you enlighten us on if:
> 
>    * I'm doing something stupid or
>    * this is an actual bug in cljs/core.async?
> 
>  Thanks!
> 
>  On Mon, Feb 17, 2014 at 2:10 PM, Manuel Paccagnella
>   wrote:
> > Tested on Linux x64, Chromium 31.0.1650.63 and Firefox 26.0. Same
> behaviour
> > that you have seen. However, I haven't looked at the code yet.
> >
> > Il giorno lunedì 17 febbraio 2014 20:34:22 UTC+1, t x ha scritto:
> >>
> >> Can anyone verify whether this bug is reproducible?
> >>
> >> On Mon, Feb 17, 2014 at 12:28 AM, t x  wrote:
> >> > Hi,
> >> >
> >> >   repo: https://github.com/txrev319/bug-report
> >> >
> >> >   I have a really weird bug where:
> >> >
> >> >   * (my-macro ...) ==> everything works
> >> >
> >> >   * (async/go (my-macro ...)) ==> something weird happens
> >> >
> >> >
> >> >   A minimal failure case is documented at:
> >> > https://github.com/txrev319/bug-report/blob/master/src/app.cljx
> >> >
> >> >   It depends on the macro defined in:
> >> >
> https://github.com/txrev319/bug-report/blob/master/src/macros.cljx
> >> >
> >> >   The bug can be replicated by following the instructions at:
> >> > https://github.com/txrev319/bug-report/blob/master/README.md
> >> >
> >> >   I *believe* I have included everything required to replicate the
> >> > bug. If I am missing anything, please let me know.
> >> >
> >> >
> >> > Extra info:
> >> >
> >> > $ lein --version
> >> > Leiningen 2.2.0 on Java 1.7.0_45 Java HotSpot(TM) 64-Bit Server VM
> >> >
> >> > I'm on 64-bit OSX.
> >> >
> >> >
> >> > 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.
> 
>  --
>  You received this message because you are subscribed to the Google
>  Groups "Clojure" group.
>  To p

call clojure from java

[sorin cristea]

Hi 

do you know how I can call a clojure script from a java method ?


Thanks,
Sorin.

-- 
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: weird bug with cljs.core.async + macros

[Michał Marczyk]

On 18 February 2014 02:14, t x  wrote:
>   Does this mean:
>   (a) the reported behavior is normal (and my bug report is invalid) or
>   (b) this error happens in both cljs + clojure ?

I'd say (b).

-- 
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: call clojure from java

[Sunil S Nandihalli]

You can't call a clojurescript function from java. However you can call
clojure-code from Java and clojurescript code from javascript.


On Tue, Feb 18, 2014 at 5:09 PM, sorin cristea  wrote:

> Hi
>
> do you know how I can call a clojure script from a java method ?
>
>
> Thanks,
> Sorin.
>
> --
> 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: call clojure from java

[Shantanu Kumar]

Hi Sorin,

Are you looking for something like 
load-file: http://clojuredocs.org/clojure_core/clojure.core/load-file

Shantanu

On Tuesday, 18 February 2014 17:09:20 UTC+5:30, sorin cristea wrote:
>
> Hi 
>
> do you know how I can call a clojure script from a java method ?
>
>
> Thanks,
> Sorin.
>

-- 
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: Looking for advice to fine tune a simple function

[Philipp Meier]

Hi,

Am Sonntag, 16. Februar 2014 23:31:46 UTC+1 schrieb Laurent Droin:
>
> Here is a function that I came up with that takes  a bpm (heart beats per 
> minute) value, as well as a sequence of 4 values that represent the 
> boundaries defining the 5 different heart rate zones for a particular 
> person.
> The function needs to finds out in what heart zone the bpm value falls 
> into and return that zone (as a keyword - I later use that keyword in a 
> map).
>
>
I'd go with something like this:


   1. (defn r [x ps]
   2.   (some (fn [[p e]]
   3.   (when (>= x p) e))
   4. (reverse ps)))
   5.  
   6. (r 7 [[0 :a] [5 :b] [10 :c]]) ;; => :b
   

-billy
 

-- 
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: call clojure from java

[Michael Klishin]

2014-02-18 16:00 GMT+04:00 Sunil S Nandihalli :

> You can't call a clojurescript function from java. However you can call
> clojure-code from Java and clojurescript code from javascript.


I think the idea is to call a Clojure script (with a space) from Java.

Use clojure.lang.RT#var and clojure.lang.IFn#invoke to call
clojure.core/load-file
and similar clojure.core functions:

http://en.wikibooks.org/wiki/Clojure_Programming/Tutorials_and_Tips#Invoking_Clojure_from_Java
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
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: call clojure from java

[Sunil S Nandihalli]

sorry I misread the email!


On Tue, Feb 18, 2014 at 6:17 PM, Michael Klishin <
michael.s.klis...@gmail.com> wrote:

>
> 2014-02-18 16:00 GMT+04:00 Sunil S Nandihalli 
> :
>
> You can't call a clojurescript function from java. However you can call
>> clojure-code from Java and clojurescript code from javascript.
>
>
> I think the idea is to call a Clojure script (with a space) from Java.
>
> Use clojure.lang.RT#var and clojure.lang.IFn#invoke to call
> clojure.core/load-file
> and similar clojure.core functions:
>
>
> http://en.wikibooks.org/wiki/Clojure_Programming/Tutorials_and_Tips#Invoking_Clojure_from_Java
> --
> MK
>
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
>
> --
> 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: call clojure from java

[Stathis Sideris]

I think you're looking for this method here:

https://skillsmatter.com/skillscasts/3864-impromptu-rich-hickey-lightning-talk

(you need to register to see the video)

On Tuesday, 18 February 2014 11:39:20 UTC, sorin cristea wrote:
>
> Hi 
>
> do you know how I can call a clojure script from a java method ?
>
>
> Thanks,
> Sorin.
>

-- 
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: Lein, Speclj & clojure 1.6.0-beta1

[Stathis Sideris]

Leiningen can exclude certain dependencies of your dependencies, see here:

https://github.com/technomancy/leiningen/blob/master/sample.project.clj#L48

Whether Speclj will work with Clojure 1.6 is something you'll have to 
test...

On Monday, 17 February 2014 12:09:13 UTC, Karsten Schmidt wrote:
>
> Hi all, am trying to test out the new hashing approach for my datatypes in 
> 1.6 but it seems that even though I'm referring to the latest beta in my 
> project.clj, Speclj is overriding that dependency with 1.5.1 and I can't 
> run my tests. How can I force it to honor my setting and use 1.6.0-beta1? I 
> guess that's a more general question about leiningen's dep resolution for 
> plugins...
>
> 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.

Re: call clojure from java

[sorin cristea]

Hi guys,

Thanks for your information. I would take the advantage of concurrency in 
clojure and implement a concurrent scenario in clojure and call it from 
java code. For example I want to read/modify the content of file from many 
threads, this scenario I want to implement in clojure, and call this from 
java, in order to avoid the implementation of this scenario in java to put 
locks on file when it's modify by one thread.

Sorin

On Tuesday, February 18, 2014 3:10:18 PM UTC+2, Stathis Sideris wrote:
>
> I think you're looking for this method here:
>
>
> https://skillsmatter.com/skillscasts/3864-impromptu-rich-hickey-lightning-talk
>
> (you need to register to see the video)
>
> On Tuesday, 18 February 2014 11:39:20 UTC, sorin cristea wrote:
>>
>> Hi 
>>
>> do you know how I can call a clojure script from a java method ?
>>
>>
>> Thanks,
>> Sorin.
>>
>

-- 
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: call clojure from java

[Alex Miller]

FYI, as of Clojure 1.6, you will use the clojure.java.api.Clojure class to 
obtain vars instead of RT.

http://clojure.github.io/clojure/javadoc/clojure/java/api/Clojure.html

But I would actually recommend creating a Java interface that looks just 
how want it, and then implement that interface in Clojure (via reify, 
extending a defrecord, etc). 


On Tuesday, February 18, 2014 6:47:38 AM UTC-6, Michael Klishin wrote:
>
>
> 2014-02-18 16:00 GMT+04:00 Sunil S Nandihalli 
> 
> >:
>
>> You can't call a clojurescript function from java. However you can call 
>> clojure-code from Java and clojurescript code from javascript.
>
>
> I think the idea is to call a Clojure script (with a space) from Java.
>
> Use clojure.lang.RT#var and clojure.lang.IFn#invoke to call 
> clojure.core/load-file
> and similar clojure.core functions:
>
>
> http://en.wikibooks.org/wiki/Clojure_Programming/Tutorials_and_Tips#Invoking_Clojure_from_Java
> -- 
> MK
>
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
>  

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

[ANN] Clojure/West Schedule - San Francisco, Mar 24-26

[Alex Miller]

The Clojure/West schedule is now available:
- Main: http://www.clojurewest.org/
- Speakers: http://www.clojurewest.org/speakers
- Schedule: http://www.clojurewest.org/schedule
- Register:
https://www.eventbrite.com/e/clojurewest-2014-tickets-10153269703

This Friday (Feb 21) is the last day for regular registration rates ($415)
- after that rates go up to $495. This Friday is also the last day to
register in the hotel block at the Palace Hotel ($199/night).

Prior to Clojure/West, training in Clojure (Friday-Sunday), ClojureScript
(Saturday), and Datomic (Sunday) is available - see
https://www.eventbrite.com/e/sf-clojure-training-intro-to-clojure-datomic-clojurescript-tickets-10165560465

We are still seeking sponsors for the conference - if you're interested in
hiring Clojure devs, this is a great opportunity to get your name out
there. More info: http://www.clojurewest.org/sponsorship-prospectus.pdf

Hope to see you all there!
Alex Miller and Lynn Grogan
clojure-w...@cognitect.com

--
List of talks on Mon 3/24 and Tues 3/25:
- Instaparse - Mark Engelberg
- How Clojure Works: Understanding the Clojure Runtime - Daniel Solano Gómez
- clojure.web/with-security - Aaron Bedra
- Extending leiningen to make it do what you want - Nelson Morris
- Data all the ASTs - Timothy Baldridge
- DevOps Done Right: Room Key's Datomic Deployment in AWS - Vincent
Rivellino
- ClojureBridge - Bridget Hillyer
- Apprenticeships - Jennifer Eliuk
- Healthcare "big" Data -from Data Management to Web Apps - Andrew Nguyen
- Predictably Fast Clojure - Zach Tellman
- lein-voom: Projects Want to be Values - Aaron Brooks
- Components: Just Enough Structure - Stuart Sierra
- PigPen: Map-Reduce for Clojure - Matt Bossenbroek
- The Functional Final Frontier - David Nolen
- Targeting Clojure & ClojureScript from a Single Codebase - Chas Emerick
- Loom and Graphs in Clojure - Aysylu Greenberg
- Probe: Program Traces as First Class State - Ian Eslick
- Bring core.typed into your codebase - Ryan Macy
- Building Interactive Query Tools on Datomic - David Greenberg
- cljs All The Things: Full Stack Apps with ClojureScript - Travis Vachon
- Beginner's Luck - Daniel Glauser & Denise Zimmerman
- The Poem as Value - Priyatam Mudivarti
- Web Programming with Hoplon - Alan Dipert & Micha Niskin
- How to grow your own distributed array database - Alice Liang
- Powerful testing with simple-check - Reid Draper
- Wiring Prismatic's API with fnHouse and Coax - Dave Golland

On Wed Mar 26 we will have space available to do what we all love - hacking
on Clojure from 9 am - 2 pm! We'll be soliciting specific project ideas for
this in a couple weeks.

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

Is ^{:once true} still necessary for lazy-seqs?

[pron]

lazy-seq marks it's supplied lambdata with ^{:once true} to prevent the 
memory leak described at the bottom of this page .
However, while going over the code for clojure.lang.LazySeq, I noticed that 
ever since this commit by 
Rich,
 
LazySeq doesn't extend AFn, but rather contains a reference to the lambda, 
fn, which it nullifies immediately after the first use, supposedly 
preventing any leaks caused by closed locals.
So my question is, is ^{:once true} still necessary for lazy-seqs, or does 
this (pretty old) change to LazySeq make it redundant?

Ron

-- 
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] Clojure 1.6.0-beta1

[Alex Miller]

Re the discussion around some?/if-some/when-some...

Summarizing feedback here:
1) "some?" has a confusion with "some" (but some congruence with some->, 
some->>)
2) other names might be better (not-nil?, nnil?, exists?, value?)
3) if-some and when-some lack the word "let" to clue you into their binding 
nature

Regarding 1 and 2, all of these factors were discussed prior to selecting 
the current names, so I don't think there was any new compelling 
information. All of these names (including the ones chosen) have downsides 
(double negatives, possible collisions with existing non-core code, etc). 
The current names will remain as is.

Regarding 3, "let" was omitted in the name due to length but we are going 
to tweak the docstring to signal more strongly the relationship to if-let 
and when-let.

Alex

-- 
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: Looking for advice to fine tune a simple function

[Johanna Belanger]

You can use the *pad* argument in *partition* to add x as the value of 
:zone-5, like *(partition 2 2 [x] params)*. (Note you have to supply *step* if 
you supply *pad*.) Then you don't need the *or* or the *(last params)*.

Also, like Billy did, you can use *some* instead of (*first (filter 
(complement nil?)...* The confusing thing about *some* is that it doesn't 
return the first value for which the predicate is true, it returns the 
value of the predicate the first time it is truthy. So using it to return 
the first one that isn't nil works perfectly.

And the partial function doesn't really help you here because you already 
have access to x where you need to call your function.

If you make those 3 changes, you'll have:

(defn quantize
   [x params]
 (some (fn [[b c]] (if (<= x c) b)) (partition 2 2 [x] params)))




On Monday, February 17, 2014 9:04:22 PM UTC-8, Laurent Droin wrote:
>
> Hmmm, looks like I can replace
>
> #(not (nil? %))
>
> by
> (complement nil?)
>
> which seems more elegant.
>
> Also, it looks like I don't need that (into [] ), which will keep the code 
> cleaner.
>
> I think I could also get rid of the (or) by always adding "(last params)" 
> at the end of the sequence from which I pick the first non null element. 
> The problem with this is that I need to make sure I add this element at the 
> end of the collection, and map returns a list, which means that I would 
> need to convert it into a vector if I want to use conj.
> Or maybe there's a way to guarantee that I can add an element at the end 
> of the list.  I know it's not cheap but I'm not sure if it will make a 
> significant difference for what I'm doing. 
> I think I could really abuse the "into" function and that doesn't seem 
> quite right.
>

-- 
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: Latex style file for formatting/coloring clojure code?

[Tassilo Horn]

Jean Niklas L'orange  writes:

>> I am unable to find a style file that supports clojure code in LaTeX.
>> Can anyone point me in the right direction?
>
> I always use Minted for this kind of stuff: See 
> https://code.google.com/p/minted/

I just want to second that.  Minted is excellent.  The only downside is
that compiling the document takes some time if you have lots of
listings.  But the most recent git version has a cache option which
won't call pygments only on listings that have changed.

BTW, minted is now on github:

  https://github.com/gpoore/minted

Bye,
Tassilo

-- 
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: Is ^{:once true} still necessary for lazy-seqs?

[pron]

The same goes for delay (where the lambda reference is nullified), which 
leaves future-call, and even there :once is not really necessary.

A cursory benchmark indicated that lazy-seq does not, in fact, leak memory 
on long sequences, even without the :once flag. Am I missing anything?

BTW, the :once mechanism isn't (if I'm not mistaken) thread-safe. That's 
why LazySeq and Delay had to use synchronized blocks even when they relied 
on :once (again, if I'm correct in the assessment that they no longer do).



On Tuesday, February 18, 2014 7:39:06 PM UTC+2, pron wrote:
>
> lazy-seq marks it's supplied lambdata with ^{:once true} to prevent the 
> memory leak described at the bottom of this page 
> .
> However, while going over the code for clojure.lang.LazySeq, I noticed 
> that ever since this commit by 
> Rich,
>  
> LazySeq doesn't extend AFn, but rather contains a reference to the lambda, 
> fn, which it nullifies immediately after the first use, supposedly 
> preventing any leaks caused by closed locals.
> So my question is, is ^{:once true} still necessary for lazy-seqs, or does 
> this (pretty old) change to LazySeq make it redundant?
>
> Ron
>
>

-- 
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: weird bug with cljs.core.async + macros

[Thomas Heller]

While I haven't tested the code, I can see one "obvious" mistake.

https://github.com/txrev319/bug-report/blob/master/src/app.cljx#L20

"cat" is undefined?

Also why is it macros.cljX? Not sure what happens when cljs encounters a 
defmacro but it should throw an error no?

HTH,
/thomas

On Monday, February 17, 2014 9:28:29 AM UTC+1, t x wrote:
>
> Hi, 
>
>   repo: https://github.com/txrev319/bug-report 
>
>   I have a really weird bug where: 
>
>   * (my-macro ...) ==> everything works 
>
>   * (async/go (my-macro ...)) ==> something weird happens 
>
>
>   A minimal failure case is documented at: 
> https://github.com/txrev319/bug-report/blob/master/src/app.cljx 
>
>   It depends on the macro defined in: 
> https://github.com/txrev319/bug-report/blob/master/src/macros.cljx 
>
>   The bug can be replicated by following the instructions at: 
> https://github.com/txrev319/bug-report/blob/master/README.md 
>
>   I *believe* I have included everything required to replicate the 
> bug. If I am missing anything, please let me know. 
>
>
> Extra info: 
>
> $ lein --version 
> Leiningen 2.2.0 on Java 1.7.0_45 Java HotSpot(TM) 64-Bit Server VM 
>
> I'm on 64-bit OSX. 
>
>
> 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.

Re: weird bug with cljs.core.async + macros

[Ben Wolfson]

On Tue, Feb 18, 2014 at 11:18 AM, Thomas Heller  wrote:

> While I haven't tested the code, I can see one "obvious" mistake.
>
> https://github.com/txrev319/bug-report/blob/master/src/app.cljx#L20
>
> "cat" is undefined?
>
>
That isn't a mistake. `silly` expands into a case, which expects bare
symbols.

-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure."
[Larousse, "Drink" entry]

-- 
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: weird bug with cljs.core.async + macros

[Timothy Baldridge]

I'm unable to decipher from these examples exactly what is expected and
what is going on. Can someone write me a concise 1 paragraph description of
the problem. Something like:

"When a case is emitted from a macro into the body of a go, . happens"

I think it's probably something related to how case is handled in gos. Try
switching to a condp and see how that works.

I'm in the process of rewriting the go macro to use the tools.analyzer
code. The CLJ side of things is done, and I just need to port to CLJS.
Already this has solved many bugs with symbol resolution and special forms.

Timothy


On Tue, Feb 18, 2014 at 12:20 PM, Ben Wolfson  wrote:

> On Tue, Feb 18, 2014 at 11:18 AM, Thomas Heller wrote:
>
>> While I haven't tested the code, I can see one "obvious" mistake.
>>
>> https://github.com/txrev319/bug-report/blob/master/src/app.cljx#L20
>>
>> "cat" is undefined?
>>
>>
> That isn't a mistake. `silly` expands into a case, which expects bare
> symbols.
>
> --
> Ben Wolfson
> "Human kind has used its intelligence to vary the flavour of drinks, which
> may be sweet, aromatic, fermented or spirit-based. ... Family and social
> life also offer numerous other occasions to consume drinks for pleasure."
> [Larousse, "Drink" entry]
>
>  --
> 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.
>



-- 
"One of the main causes of the fall of the Roman Empire was that-lacking
zero-they had no way to indicate successful termination of their C
programs."
(Robert Firth)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Looking for advice to fine tune a simple function

[Laurent Droin]

Wow, that's amazing. Thanks Billy and Johanna. I'm going to try all this 
tonight.

What I'm not sure of (I don't have a good understanding yet about lazy 
sequences) is whether or not the sequence given to "some" is lazy or not.
For example, if I have thousands of parameters but x is <= the first 
boundary value (i.e. the first element in the sequence), I don't really 
want to test x against all the other boundary values in the sequence since 
I already know it's not nil.
Otherwise, I was thinking I could use recursion, take the two first 
elements of the sequence, and see if I could conclude. If not, I would call 
the function again against the rest of the sequence.

-- 
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: weird bug with cljs.core.async + macros

[Thomas Heller]

Well, while case allows for symbols it still doesn't make sense to use it 
except :tag switches between keywords and symbols to. Apart from that cat 
"pat2" is never actually used.

(defmacro silly [object pat1 body1 pat2 body2]
  `(case (:tag ~object)
 ~pat1 ~body1
 ~body2))



But as Timothy said its probably related to case, so I'll shut up.

On Tuesday, February 18, 2014 8:20:07 PM UTC+1, Ben wrote:
>
> On Tue, Feb 18, 2014 at 11:18 AM, Thomas Heller 
> 
> > wrote:
>
>> While I haven't tested the code, I can see one "obvious" mistake.
>>
>> https://github.com/txrev319/bug-report/blob/master/src/app.cljx#L20
>>
>> "cat" is undefined?
>>
>>
> That isn't a mistake. `silly` expands into a case, which expects bare 
> symbols.
>
> -- 
> Ben Wolfson
> "Human kind has used its intelligence to vary the flavour of drinks, which 
> may be sweet, aromatic, fermented or spirit-based. ... Family and social 
> life also offer numerous other occasions to consume drinks for pleasure." 
> [Larousse, "Drink" entry]
>
>  

-- 
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: weird bug with cljs.core.async + macros

[t x]

Hi Timothy,

One paragraph summary:

  When a macro expands to case inside of a go-block, it appears that
the _ELSE_ clause of the case is always run. (Even after a previous
clause has matched.)

Slightly longer summary:


  In these lines:
https://github.com/txrev319/bug-report/blob/master/src/app.cljx#L11-L20

  The macro is supposed to expand into:

  (case (:tag {:tag :dog})
:dog "woof woof"
"unrecognized")


  When we do not use go, we get the result as expected.


  When we put it into a go-block, it appears that both the

  :dog "woof woof" branch

and the

  "unrecognized" branch

  are _BOTH_ being executed -- when only one should be executed.




On Tue, Feb 18, 2014 at 12:09 PM, Thomas Heller  wrote:
> Well, while case allows for symbols it still doesn't make sense to use it
> except :tag switches between keywords and symbols to. Apart from that cat
> "pat2" is never actually used.
>
> (defmacro silly [object pat1 body1 pat2 body2]
>   `(case (:tag ~object)
>  ~pat1 ~body1
>  ~body2))
>
>
>
> But as Timothy said its probably related to case, so I'll shut up.
>
> On Tuesday, February 18, 2014 8:20:07 PM UTC+1, Ben wrote:
>>
>> On Tue, Feb 18, 2014 at 11:18 AM, Thomas Heller  wrote:
>>>
>>> While I haven't tested the code, I can see one "obvious" mistake.
>>>
>>> https://github.com/txrev319/bug-report/blob/master/src/app.cljx#L20
>>>
>>> "cat" is undefined?
>>>
>>
>> That isn't a mistake. `silly` expands into a case, which expects bare
>> symbols.
>>
>> --
>> Ben Wolfson
>> "Human kind has used its intelligence to vary the flavour of drinks, which
>> may be sweet, aromatic, fermented or spirit-based. ... Family and social
>> life also offer numerous other occasions to consume drinks for pleasure."
>> [Larousse, "Drink" entry]
>>
> --
> 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: weird bug with cljs.core.async + macros

[t x]

@Thomas:
(this is completely unrelated to the actual bug)

  This particular code was "simplified" from a more complicated macro
-- where for the else clause, I want to capture the original value, so
it would be something like:


  (silly obj
:dog dog-line
cat cat-line) ==>

  (case (:tag obj)
 :dog dog-line
  (let [cat obj] cat-line ))

  However, in "simplifying" the example, parts of the macro was
removed, and thus it appears that we have this dangling cat symbol.





On Tue, Feb 18, 2014 at 12:09 PM, Thomas Heller  wrote:
> Well, while case allows for symbols it still doesn't make sense to use it
> except :tag switches between keywords and symbols to. Apart from that cat
> "pat2" is never actually used.
>
> (defmacro silly [object pat1 body1 pat2 body2]
>   `(case (:tag ~object)
>  ~pat1 ~body1
>  ~body2))
>
>
>
> But as Timothy said its probably related to case, so I'll shut up.
>
> On Tuesday, February 18, 2014 8:20:07 PM UTC+1, Ben wrote:
>>
>> On Tue, Feb 18, 2014 at 11:18 AM, Thomas Heller  wrote:
>>>
>>> While I haven't tested the code, I can see one "obvious" mistake.
>>>
>>> https://github.com/txrev319/bug-report/blob/master/src/app.cljx#L20
>>>
>>> "cat" is undefined?
>>>
>>
>> That isn't a mistake. `silly` expands into a case, which expects bare
>> symbols.
>>
>> --
>> Ben Wolfson
>> "Human kind has used its intelligence to vary the flavour of drinks, which
>> may be sweet, aromatic, fermented or spirit-based. ... Family and social
>> life also offer numerous other occasions to consume drinks for pleasure."
>> [Larousse, "Drink" entry]
>>
> --
> 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: weird bug with cljs.core.async + macros

[Timothy Baldridge]

"When a macro expands to case inside of a go-block, it appears that
the _ELSE_ clause of the case is always run. (Even after a previous
clause has matched.)"

Thanks, I'll get a test in the project for this, it'll probably be fixed in
the next alpha release. Until then, cond or condp might work?

Timothy


On Tue, Feb 18, 2014 at 1:40 PM, t x  wrote:

> @Thomas:
> (this is completely unrelated to the actual bug)
>
>   This particular code was "simplified" from a more complicated macro
> -- where for the else clause, I want to capture the original value, so
> it would be something like:
>
>
>   (silly obj
> :dog dog-line
> cat cat-line) ==>
>
>   (case (:tag obj)
>  :dog dog-line
>   (let [cat obj] cat-line ))
>
>   However, in "simplifying" the example, parts of the macro was
> removed, and thus it appears that we have this dangling cat symbol.
>
>
>
>
>
> On Tue, Feb 18, 2014 at 12:09 PM, Thomas Heller 
> wrote:
> > Well, while case allows for symbols it still doesn't make sense to use it
> > except :tag switches between keywords and symbols to. Apart from that cat
> > "pat2" is never actually used.
> >
> > (defmacro silly [object pat1 body1 pat2 body2]
> >   `(case (:tag ~object)
> >  ~pat1 ~body1
> >  ~body2))
> >
> >
> >
> > But as Timothy said its probably related to case, so I'll shut up.
> >
> > On Tuesday, February 18, 2014 8:20:07 PM UTC+1, Ben wrote:
> >>
> >> On Tue, Feb 18, 2014 at 11:18 AM, Thomas Heller 
> wrote:
> >>>
> >>> While I haven't tested the code, I can see one "obvious" mistake.
> >>>
> >>> https://github.com/txrev319/bug-report/blob/master/src/app.cljx#L20
> >>>
> >>> "cat" is undefined?
> >>>
> >>
> >> That isn't a mistake. `silly` expands into a case, which expects bare
> >> symbols.
> >>
> >> --
> >> Ben Wolfson
> >> "Human kind has used its intelligence to vary the flavour of drinks,
> which
> >> may be sweet, aromatic, fermented or spirit-based. ... Family and social
> >> life also offer numerous other occasions to consume drinks for
> pleasure."
> >> [Larousse, "Drink" entry]
> >>
> > --
> > 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.
>



-- 
"One of the main causes of the fall of the Roman Empire was that-lacking
zero-they had no way to indicate successful termination of their C
programs."
(Robert Firth)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: weird bug with cljs.core.async + macros

[t x]

Hi Timothy,

  I've picked case over cond/condp because I want a O(1) dispatch
rather than linear execution since there are many patterns [though I'm
probably guilty of premature optimization here].

  I've currently been working around it via two techniques:

** Refactoring it into a function.

  i.e.

  (defn some-func [msg]
(hmatch msg ... )) ;; silly is called hmatch

  (async/go
(loop [msg ( wrote:
> "When a macro expands to case inside of a go-block, it appears that
> the _ELSE_ clause of the case is always run. (Even after a previous
> clause has matched.)"
>
> Thanks, I'll get a test in the project for this, it'll probably be fixed in
> the next alpha release. Until then, cond or condp might work?
>
> Timothy
>
>
> On Tue, Feb 18, 2014 at 1:40 PM, t x  wrote:
>>
>> @Thomas:
>> (this is completely unrelated to the actual bug)
>>
>>   This particular code was "simplified" from a more complicated macro
>> -- where for the else clause, I want to capture the original value, so
>> it would be something like:
>>
>>
>>   (silly obj
>> :dog dog-line
>> cat cat-line) ==>
>>
>>   (case (:tag obj)
>>  :dog dog-line
>>   (let [cat obj] cat-line ))
>>
>>   However, in "simplifying" the example, parts of the macro was
>> removed, and thus it appears that we have this dangling cat symbol.
>>
>>
>>
>>
>>
>> On Tue, Feb 18, 2014 at 12:09 PM, Thomas Heller 
>> wrote:
>> > Well, while case allows for symbols it still doesn't make sense to use
>> > it
>> > except :tag switches between keywords and symbols to. Apart from that
>> > cat
>> > "pat2" is never actually used.
>> >
>> > (defmacro silly [object pat1 body1 pat2 body2]
>> >   `(case (:tag ~object)
>> >  ~pat1 ~body1
>> >  ~body2))
>> >
>> >
>> >
>> > But as Timothy said its probably related to case, so I'll shut up.
>> >
>> > On Tuesday, February 18, 2014 8:20:07 PM UTC+1, Ben wrote:
>> >>
>> >> On Tue, Feb 18, 2014 at 11:18 AM, Thomas Heller 
>> >> wrote:
>> >>>
>> >>> While I haven't tested the code, I can see one "obvious" mistake.
>> >>>
>> >>> https://github.com/txrev319/bug-report/blob/master/src/app.cljx#L20
>> >>>
>> >>> "cat" is undefined?
>> >>>
>> >>
>> >> That isn't a mistake. `silly` expands into a case, which expects bare
>> >> symbols.
>> >>
>> >> --
>> >> Ben Wolfson
>> >> "Human kind has used its intelligence to vary the flavour of drinks,
>> >> which
>> >> may be sweet, aromatic, fermented or spirit-based. ... Family and
>> >> social
>> >> life also offer numerous other occasions to consume drinks for
>> >> pleasure."
>> >> [Larousse, "Drink" entry]
>> >>
>> > --
>> > 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.
>
>
>
>
> --
> "One of the main causes of the fall of the Roman Empire was that-lacking
> zero-they had no way to indicate successful termination of their C
> programs."
> (Robert Firth)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit h

Re: weird bug with cljs.core.async + macros

[Michał Marczyk]

On 18 February 2014 22:15, t x  wrote:
>   I've picked case over cond/condp because I want a O(1) dispatch
> rather than linear execution since there are many patterns [though I'm
> probably guilty of premature optimization here].

Actually in ClojureScript case dispatch is O(n), since it's
implemented as a macro expanding to cond.

Cheers,
Michał

-- 
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: weird bug with cljs.core.async + macros

[Michał Marczyk]

On 18 February 2014 22:31, Michał Marczyk  wrote:
> Actually in ClojureScript case dispatch is O(n), since it's
> implemented as a macro expanding to cond.

As of release 2156:

https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1119

-- 
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: weird bug with cljs.core.async + macros

[t x]

Looking at 
https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1144-L1147
, you win. :-)

On Tue, Feb 18, 2014 at 1:33 PM, Michał Marczyk
 wrote:
> On 18 February 2014 22:31, Michał Marczyk  wrote:
>> Actually in ClojureScript case dispatch is O(n), since it's
>> implemented as a macro expanding to cond.
>
> As of release 2156:
>
> https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1119
>
> --
> 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: weird bug with cljs.core.async + macros

[David Nolen]

Due to asm.js some JS engines are starting to compile switch statements
where the cases are integers into jump tables. Compiler enhancement that
compiles optimizable case expressions to JS switch statements would be a
welcome enhancement - http://dev.clojure.org/jira/browse/CLJS-713.

David


On Tue, Feb 18, 2014 at 4:35 PM, t x  wrote:

> Looking at
> https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1144-L1147
> , you win. :-)
>
> On Tue, Feb 18, 2014 at 1:33 PM, Michał Marczyk
>  wrote:
> > On 18 February 2014 22:31, Michał Marczyk 
> wrote:
> >> Actually in ClojureScript case dispatch is O(n), since it's
> >> implemented as a macro expanding to cond.
> >
> > As of release 2156:
> >
> >
> https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1119
> >
> > --
> > 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: Looking for advice to fine tune a simple function

[Johanna Belanger]

I know. Isn't Clojure beautiful? Sigh...

In the docs for 
*partition*, 
it says that partition returns a lazy sequence. And if you look at the 
source section of the docs for 
*some* you 
can see that it uses recursion under the hood. So you should be covered 
there.

Thanks for the interesting discussion. =)

On Tuesday, February 18, 2014 11:56:17 AM UTC-8, Laurent Droin wrote:
>
> Wow, that's amazing. Thanks Billy and Johanna. I'm going to try all this 
> tonight.
>
> What I'm not sure of (I don't have a good understanding yet about lazy 
> sequences) is whether or not the sequence given to "some" is lazy or not.
> For example, if I have thousands of parameters but x is <= the first 
> boundary value (i.e. the first element in the sequence), I don't really 
> want to test x against all the other boundary values in the sequence since 
> I already know it's not nil.
> Otherwise, I was thinking I could use recursion, take the two first 
> elements of the sequence, and see if I could conclude. If not, I would call 
> the function again against the rest of the sequence.
>

-- 
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: Looking for advice to fine tune a simple function

[Laurent Droin]

He he... more research work for me tonight. Thanks Johanna for the pointers.

-- 
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: weird bug with cljs.core.async + macros

[Michał Marczyk]

Great! First cut at compiling case to switch (when given numbers and
strings only as tests at the moment, but this can be improved) here:

https://github.com/michalmarczyk/clojurescript/tree/713-compile-case-to-switch

I'll post more details on the ticket.

Cheers,
Michał


On 18 February 2014 22:38, David Nolen  wrote:
> Due to asm.js some JS engines are starting to compile switch statements
> where the cases are integers into jump tables. Compiler enhancement that
> compiles optimizable case expressions to JS switch statements would be a
> welcome enhancement - http://dev.clojure.org/jira/browse/CLJS-713.
>
> David
>
>
> On Tue, Feb 18, 2014 at 4:35 PM, t x  wrote:
>>
>> Looking at
>> https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1144-L1147
>> , you win. :-)
>>
>> On Tue, Feb 18, 2014 at 1:33 PM, Michał Marczyk
>>  wrote:
>> > On 18 February 2014 22:31, Michał Marczyk 
>> > wrote:
>> >> Actually in ClojureScript case dispatch is O(n), since it's
>> >> implemented as a macro expanding to cond.
>> >
>> > As of release 2156:
>> >
>> >
>> > https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1119
>> >
>> > --
>> > 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 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: weird bug with cljs.core.async + macros

[t x]

With apologies for potential stupidity:

* (get {... } key) is an operation that is O(log n) worst case (if
using Red-Black trees) or O(1) average case (hashing)

* (get { ... } key) does not have integer/string limitation

Therefore: why are we not "compiling down to get" ? Are the big-Oh
constants enormous?

On Tue, Feb 18, 2014 at 3:51 PM, Michał Marczyk
 wrote:
> Great! First cut at compiling case to switch (when given numbers and
> strings only as tests at the moment, but this can be improved) here:
>
> https://github.com/michalmarczyk/clojurescript/tree/713-compile-case-to-switch
>
> I'll post more details on the ticket.
>
> Cheers,
> Michał
>
>
> On 18 February 2014 22:38, David Nolen  wrote:
>> Due to asm.js some JS engines are starting to compile switch statements
>> where the cases are integers into jump tables. Compiler enhancement that
>> compiles optimizable case expressions to JS switch statements would be a
>> welcome enhancement - http://dev.clojure.org/jira/browse/CLJS-713.
>>
>> David
>>
>>
>> On Tue, Feb 18, 2014 at 4:35 PM, t x  wrote:
>>>
>>> Looking at
>>> https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1144-L1147
>>> , you win. :-)
>>>
>>> On Tue, Feb 18, 2014 at 1:33 PM, Michał Marczyk
>>>  wrote:
>>> > On 18 February 2014 22:31, Michał Marczyk 
>>> > wrote:
>>> >> Actually in ClojureScript case dispatch is O(n), since it's
>>> >> implemented as a macro expanding to cond.
>>> >
>>> > As of release 2156:
>>> >
>>> >
>>> > https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1119
>>> >
>>> > --
>>> > 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 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.

Re: ANN: om-sync

[Geraldo Lopes de Souza]

Conrad,

Ui library modeled after bootstrap or foundation with rewritten widgets 
compatible with advanced mode.

Or Pure from yahoo.This one does not comes with js and it is very light


On Saturday, February 15, 2014 11:26:18 PM UTC-2, Conrad Barski wrote:
> On Thursday, February 13, 2014 8:55:00 PM UTC-6, David Nolen wrote:
> 
> > I've been banging the drum about Om & modularity for a while now and I've 
> > come up with the very beginning of a simple reusable component that I think 
> > demonstrates the power of Om's emphasis on modularity and application wide 
> > state management:
> 
> > 
> 
> > 
> 
> > 
> 
> > http://github.com/swannodette/om-sync
> 
> > 
> 
> > 
> 
> > 
> 
> > The whole point of Om is to create a universe of shareable components. I 
> > hope this gets people thinking about the possibilities.
> 
> > 
> 
> > 
> 
> > 
> 
> > Feedback welcome!
> 
> > 
> 
> > 
> 
> > David
> 
> 
> 
> I agree that creating an ecosystem of components is where the future is... 
> I'm surprised that there isn't a "ReactjsUI" library yet.
> 
> 
> 
> Stop me if this is obvious, but it seems like the natural conclusion of Om is 
> to have an Om-server library as well to build html server-side, and then have 
> an Om-bridge component or something that automagically bridges between client 
> and server. Then, when a client-side component updates any state that 
> originates in the server part, the existing Om interfaces probably are 
> already comprehensive enough that the Om-bridge component could just 
> transparently use AJAX to push those updates into the state of the Om 
> components residing on the server.

-- 
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: weird bug with cljs.core.async + macros

[Timothy Baldridge]

Firstly, I think you over estimate the cost of an if. Ifs are very very
fast, especially if you are doing identical? checks (like a case is doing).
A simple pointer comparison such as (keyword-identical? :foo :foo) is going
to be way faster than a hashmap lookup.

Secondly, ifs are very JIT friendly. Simpler code often means simpler
inlining. This could mean that several branches of the if/switch could be
removed if the JIT can prove that certain branches cannot be reached. This
is much harder to do with a hash map where things could change from one
dispatch to the next, and there isn't really a way to communicate
immutability to the JVM/JS JITs.

On the JVM I've done many tests while building core.async to try to find a
better way to do SSA block dispatching. In the end switch (aka case) won
every single time. A close second is a small set of nested ifs. Function
pointers are just expensive compared ifs and jump tables.

Timothy


On Tue, Feb 18, 2014 at 5:02 PM, t x  wrote:

> With apologies for potential stupidity:
>
> * (get {... } key) is an operation that is O(log n) worst case (if
> using Red-Black trees) or O(1) average case (hashing)
>
> * (get { ... } key) does not have integer/string limitation
>
> Therefore: why are we not "compiling down to get" ? Are the big-Oh
> constants enormous?
>
> On Tue, Feb 18, 2014 at 3:51 PM, Michał Marczyk
>  wrote:
> > Great! First cut at compiling case to switch (when given numbers and
> > strings only as tests at the moment, but this can be improved) here:
> >
> >
> https://github.com/michalmarczyk/clojurescript/tree/713-compile-case-to-switch
> >
> > I'll post more details on the ticket.
> >
> > Cheers,
> > Michał
> >
> >
> > On 18 February 2014 22:38, David Nolen  wrote:
> >> Due to asm.js some JS engines are starting to compile switch statements
> >> where the cases are integers into jump tables. Compiler enhancement that
> >> compiles optimizable case expressions to JS switch statements would be a
> >> welcome enhancement - http://dev.clojure.org/jira/browse/CLJS-713.
> >>
> >> David
> >>
> >>
> >> On Tue, Feb 18, 2014 at 4:35 PM, t x  wrote:
> >>>
> >>> Looking at
> >>>
> https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1144-L1147
> >>> , you win. :-)
> >>>
> >>> On Tue, Feb 18, 2014 at 1:33 PM, Michał Marczyk
> >>>  wrote:
> >>> > On 18 February 2014 22:31, Michał Marczyk 
> >>> > wrote:
> >>> >> Actually in ClojureScript case dispatch is O(n), since it's
> >>> >> implemented as a macro expanding to cond.
> >>> >
> >>> > As of release 2156:
> >>> >
> >>> >
> >>> >
> https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1119
> >>> >
> >>> > --
> >>> > 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...

Re: weird bug with cljs.core.async + macros

[Michał Marczyk]

switch can be compiled to a direct array indexing operation or a
binary search. I believe that's what the JVM does for tableswitch and
lookupswitch, respectively.

On 19 February 2014 01:02, t x  wrote:
> With apologies for potential stupidity:
>
> * (get {... } key) is an operation that is O(log n) worst case (if
> using Red-Black trees) or O(1) average case (hashing)
>
> * (get { ... } key) does not have integer/string limitation
>
> Therefore: why are we not "compiling down to get" ? Are the big-Oh
> constants enormous?
>
> On Tue, Feb 18, 2014 at 3:51 PM, Michał Marczyk
>  wrote:
>> Great! First cut at compiling case to switch (when given numbers and
>> strings only as tests at the moment, but this can be improved) here:
>>
>> https://github.com/michalmarczyk/clojurescript/tree/713-compile-case-to-switch
>>
>> I'll post more details on the ticket.
>>
>> Cheers,
>> Michał
>>
>>
>> On 18 February 2014 22:38, David Nolen  wrote:
>>> Due to asm.js some JS engines are starting to compile switch statements
>>> where the cases are integers into jump tables. Compiler enhancement that
>>> compiles optimizable case expressions to JS switch statements would be a
>>> welcome enhancement - http://dev.clojure.org/jira/browse/CLJS-713.
>>>
>>> David
>>>
>>>
>>> On Tue, Feb 18, 2014 at 4:35 PM, t x  wrote:

 Looking at
 https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1144-L1147
 , you win. :-)

 On Tue, Feb 18, 2014 at 1:33 PM, Michał Marczyk
  wrote:
 > On 18 February 2014 22:31, Michał Marczyk 
 > wrote:
 >> Actually in ClojureScript case dispatch is O(n), since it's
 >> implemented as a macro expanding to cond.
 >
 > As of release 2156:
 >
 >
 > https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1119
 >
 > --
 > 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 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

Re: weird bug with cljs.core.async + macros

[t x]

@Timothy, Michal:

  Understood. Thanks for clarifying!

On Tue, Feb 18, 2014 at 5:09 PM, Michał Marczyk
 wrote:
> switch can be compiled to a direct array indexing operation or a
> binary search. I believe that's what the JVM does for tableswitch and
> lookupswitch, respectively.
>
> On 19 February 2014 01:02, t x  wrote:
>> With apologies for potential stupidity:
>>
>> * (get {... } key) is an operation that is O(log n) worst case (if
>> using Red-Black trees) or O(1) average case (hashing)
>>
>> * (get { ... } key) does not have integer/string limitation
>>
>> Therefore: why are we not "compiling down to get" ? Are the big-Oh
>> constants enormous?
>>
>> On Tue, Feb 18, 2014 at 3:51 PM, Michał Marczyk
>>  wrote:
>>> Great! First cut at compiling case to switch (when given numbers and
>>> strings only as tests at the moment, but this can be improved) here:
>>>
>>> https://github.com/michalmarczyk/clojurescript/tree/713-compile-case-to-switch
>>>
>>> I'll post more details on the ticket.
>>>
>>> Cheers,
>>> Michał
>>>
>>>
>>> On 18 February 2014 22:38, David Nolen  wrote:
 Due to asm.js some JS engines are starting to compile switch statements
 where the cases are integers into jump tables. Compiler enhancement that
 compiles optimizable case expressions to JS switch statements would be a
 welcome enhancement - http://dev.clojure.org/jira/browse/CLJS-713.

 David


 On Tue, Feb 18, 2014 at 4:35 PM, t x  wrote:
>
> Looking at
> https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1144-L1147
> , you win. :-)
>
> On Tue, Feb 18, 2014 at 1:33 PM, Michał Marczyk
>  wrote:
> > On 18 February 2014 22:31, Michał Marczyk 
> > wrote:
> >> Actually in ClojureScript case dispatch is O(n), since it's
> >> implemented as a macro expanding to cond.
> >
> > As of release 2156:
> >
> >
> > https://github.com/clojure/clojurescript/blob/r2156/src/clj/cljs/core.clj#L1119
> >
> > --
> > 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 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 unsubscr

Re: Looking for advice to fine tune a simple function

[Laurent Droin]

Now that I have a better understanding of what "some" does (i didn't 
interpret the doc properly), it does totally make sense that it would be 
recursive, so that's great.

While reducing my code with Johanna's feedback, I noticed I kept using 
"cond" and not "if".

Is there any meaningful difference between

(if (<= x y) z)

and

(cond (<= x y) z)

?

I see that if is a special form and cone is macro. I haven't reached the 
chapter about macros yet in  the book I'm reading (programming Clojure). 
Not sure if it's relevant.

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

why Clojure/Lisp is so fast

[Andy C]

Hi,

There are many performance benchmarks showing that compiled CLISP is almost
as fast as C++ or Clojure as Java.

Being a dynamically typed language though, I wonder how it is possible. Is
it because the compiler is able to sort out actually used types and
assemble appropriate byte code or the cost of calling virtual methods is
negligible.

I probably should check out generated JVM byte code to see the answer
firsthand but still would appreciate a higher level answer.

Thanks in advance,
Andy

-- 
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: why Clojure/Lisp is so fast

[Mikera]

For Clojure at least, it is a combination of things, including:
- The quality of the optimisations that the JVM itself does during JIT 
compilation. Virtual method calls for example are crazily fast.
- The JVM garbage collector - which is seriously good.
- The ability to use type hints and primitive types (effectively allowing 
some static typing for performance in focused areas)
- Use of Java for much of the underlying infrastructure (e.g. Clojure's 
collections are written in Java)
- A certain amount of type inference (e.g. for numerical primitive 
expressions)
- Intelligent use of the host capabilities (for example, most of Clojure 
"dynamic" feel is achieved through clever use of Java interfaces, which is 
much faster than the map-based method lookup in many other dynamic 
languages). 
- A fairly decent compiler (Clojure is almost always compiled, rather than 
interpreted). The bytecode generated is generally quite good, though there 
is still room for improvements :-)
- Macros can do clever things at compile time to reduce runtime overhead

Some of these are just about good implementation (either within the JVM or 
Clojure itself). 

Other advantages are perhaps more intrinsic to Lisp. I think that macros 
are the best example here.

Apart from that, other dynamic languages probably make things hard for 
themselves. In particular, I think it would be hard to get Lisp-like 
performance in any dynamic language that makes pervasive use of runtime 
monkey-patching - simply because the runtime overhead of implementation 
lookup would always be a performance killer.

On Wednesday, 19 February 2014 10:59:16 UTC+8, Andy C wrote:
>
> Hi,
>
> There are many performance benchmarks showing that compiled CLISP is 
> almost as fast as C++ or Clojure as Java.
>
> Being a dynamically typed language though, I wonder how it is possible. Is 
> it because the compiler is able to sort out actually used types and 
> assemble appropriate byte code or the cost of calling virtual methods is 
> negligible.
>
> I probably should check out generated JVM byte code to see the answer 
> firsthand but still would appreciate a higher level answer.
>
> Thanks in advance,
> Andy
>
>

-- 
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: why Clojure/Lisp is so fast

[Mars0i]

It really depends on the benchmark and the programmer, and sometimes on the 
computer.  And on what a person chooses to report. Here are some 
benchmarks, probably only representative of very special cases, that show 
Java beating Clojure in many cases, Java and SBCL both beating each other 
in some cases, etc.  (For my work, I have found SBCL to be a lot faster 
than CLISP, but again, it probably depends on what you're doing.)

http://benchmarksgame.alioth.debian.org/

Other cases would be different.  (None of this conflicts with Mikera's 
insightful comments.)

-- 
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: why Clojure/Lisp is so fast

[Timothy Baldridge]

Clojure IMO is not truly dynamic, at least not to the extent of
Python/Ruby. I like to refer to Clojure as a "dynamic enough" language.

For example, once defined, types cannot be modified by adding new members
(deftype that is). If you want to add a new field to a deftype in Clojure,
you have to redefine the entire type. Existing instances of that type must
also be recreated to take advantage of the new time. Contrast this with
Python's foo.__class__.bar = 42. Sure defrecord allows some of these
features, but the way it accomplishes this is much different from the way
it is done in other languages.

In addition, some languages like Python allow you to do crazy stuff like
reflect over the stack to inspect locals in parent stack frames. This is
something that is not possible in Clojure, thankfully. These are just two
examples where Clojure is much more restricted than the "normal" dynamic
language.

As mentioned, Clojure also allows for optional type hinting that allows the
compiler to emit code that is very close to the bytecode emitted by javac.
This allows for even better performance, at the cost of having to specify
the type of a few locals here and there.


All that being said, the idea that "dynamic languages are slow" is
basically a myth. The truth is that it is often harder to write good JITs
for dynamic languages, but as LuaJIT and PyPy have shown this, is not a
unsolvable problem.

Lastly, the performance gains from having a "best in the world" GC should
not be underestimated. In functional languages you often create and destroy
objects much faster than in other languages. Therefore the performance cost
of a object allocation can greatly impact performance. Hotspot has one of
the fastest GCs on the planet...Clojure benefits greatly from this.

Timothy


On Tue, Feb 18, 2014 at 8:31 PM, Mikera wrote:

> For Clojure at least, it is a combination of things, including:
> - The quality of the optimisations that the JVM itself does during JIT
> compilation. Virtual method calls for example are crazily fast.
> - The JVM garbage collector - which is seriously good.
> - The ability to use type hints and primitive types (effectively allowing
> some static typing for performance in focused areas)
> - Use of Java for much of the underlying infrastructure (e.g. Clojure's
> collections are written in Java)
> - A certain amount of type inference (e.g. for numerical primitive
> expressions)
> - Intelligent use of the host capabilities (for example, most of Clojure
> "dynamic" feel is achieved through clever use of Java interfaces, which is
> much faster than the map-based method lookup in many other dynamic
> languages).
> - A fairly decent compiler (Clojure is almost always compiled, rather than
> interpreted). The bytecode generated is generally quite good, though there
> is still room for improvements :-)
> - Macros can do clever things at compile time to reduce runtime overhead
>
> Some of these are just about good implementation (either within the JVM or
> Clojure itself).
>
> Other advantages are perhaps more intrinsic to Lisp. I think that macros
> are the best example here.
>
> Apart from that, other dynamic languages probably make things hard for
> themselves. In particular, I think it would be hard to get Lisp-like
> performance in any dynamic language that makes pervasive use of runtime
> monkey-patching - simply because the runtime overhead of implementation
> lookup would always be a performance killer.
>
> On Wednesday, 19 February 2014 10:59:16 UTC+8, Andy C wrote:
>>
>> Hi,
>>
>> There are many performance benchmarks showing that compiled CLISP is
>> almost as fast as C++ or Clojure as Java.
>>
>> Being a dynamically typed language though, I wonder how it is possible.
>> Is it because the compiler is able to sort out actually used types and
>> assemble appropriate byte code or the cost of calling virtual methods is
>> negligible.
>>
>> I probably should check out generated JVM byte code to see the answer
>> firsthand but still would appreciate a higher level answer.
>>
>> Thanks in advance,
>> Andy
>>
>>  --
> 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.
>



-- 
"One of the main causes of the fall of the Roman Empire was that-lacking
zero-they had no way to indicate successful termination of their C
programs."
(Robert Firth)

-- 
You re

ANN: Om 0.5.0-rc1

[David Nolen]

In order to stay in sync with React 0.9.0-rc1 I've cut Om 0.5.0-rc1. There
are a couple of small breaking changes due to React but otherwise the
differences between 0.4.2 and 0.5.0-rc1 are minor. One big enhancement is
that you can now render to a string with om.dom/render-to-str.

Another big enhancement that I had absolutely nothing to do with is that
React is now almost 2X faster for the initial render under Chrome 32 &
Safari 7. This means under these browser Om is nearly 10X faster than a
naive Backbone.js at rendering 200 items in the TodoMVC application.

http://github.com/swannodette/om

Feedback welcome!
David

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

hooks on "namespace required/loaded"

[t x]

Hi,

  Although solutions not involving cljx are perfectly fine, I'm using
cljx -- so solutions that involves hooking into cljx are perfectly
fine too.

  I have my own "poor-man's lint / type checker" (with different
objectives from core.typed). I want a certain function (call it
CHECKER) to be called every time a namespace has been "required /
loaded / reloaded"

  Every time I require/load/reload a namespace, I want the following to happen:

(CHECKER ... source code of the namesapce)

i.e. something like

(CHECKER (read-string "namesapce-just-loaded.clj"))

Then, if CHECKER throws an exception, it should be a compile error. If
CHECKER prints stuff out, it should go into the "lein repl" stdout,
and if CHECKER doesn't do anything, it's assumed that the namespace
passed the check.

  Is there a minimal example somewhere of how this works? (i.e.
something as stupid as: "this example calls a function, which just
prints out the name of all functions defined" would be extremely
helpful).

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.

Re: hooks on "namespace required/loaded"

[t x]

As a point of clarification, read-string is not a hard requirement.
Just getting the name of the namespace (and walking through the
symbols + calling source on each of them to get the source code is
perfeclty fine).

Basically, I want to hook a function that
  * gets called every time a namespace is loaded/required/reloaded
  * gets passed the namespace

Thanks!

On Tue, Feb 18, 2014 at 8:32 PM, t x  wrote:
> Hi,
>
>   Although solutions not involving cljx are perfectly fine, I'm using
> cljx -- so solutions that involves hooking into cljx are perfectly
> fine too.
>
>   I have my own "poor-man's lint / type checker" (with different
> objectives from core.typed). I want a certain function (call it
> CHECKER) to be called every time a namespace has been "required /
> loaded / reloaded"
>
>   Every time I require/load/reload a namespace, I want the following to 
> happen:
>
> (CHECKER ... source code of the namesapce)
>
> i.e. something like
>
> (CHECKER (read-string "namesapce-just-loaded.clj"))
>
> Then, if CHECKER throws an exception, it should be a compile error. If
> CHECKER prints stuff out, it should go into the "lein repl" stdout,
> and if CHECKER doesn't do anything, it's assumed that the namespace
> passed the check.
>
>   Is there a minimal example somewhere of how this works? (i.e.
> something as stupid as: "this example calls a function, which just
> prints out the name of all functions defined" would be extremely
> helpful).
>
> 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.

Re: hooks on "namespace required/loaded"

[t x]

With apologies for spamming:

  Solutions that involves installing a new lein plugin is fine too.

  I'm willing to completely re-organize my workflow in order to

  * have some other piece of Clojure code gets called / do
verification whenever a clojure namespace is required/loaded/reloaded

/ Done spamming.

On Tue, Feb 18, 2014 at 8:38 PM, t x  wrote:
> As a point of clarification, read-string is not a hard requirement.
> Just getting the name of the namespace (and walking through the
> symbols + calling source on each of them to get the source code is
> perfeclty fine).
>
> Basically, I want to hook a function that
>   * gets called every time a namespace is loaded/required/reloaded
>   * gets passed the namespace
>
> Thanks!
>
> On Tue, Feb 18, 2014 at 8:32 PM, t x  wrote:
>> Hi,
>>
>>   Although solutions not involving cljx are perfectly fine, I'm using
>> cljx -- so solutions that involves hooking into cljx are perfectly
>> fine too.
>>
>>   I have my own "poor-man's lint / type checker" (with different
>> objectives from core.typed). I want a certain function (call it
>> CHECKER) to be called every time a namespace has been "required /
>> loaded / reloaded"
>>
>>   Every time I require/load/reload a namespace, I want the following to 
>> happen:
>>
>> (CHECKER ... source code of the namesapce)
>>
>> i.e. something like
>>
>> (CHECKER (read-string "namesapce-just-loaded.clj"))
>>
>> Then, if CHECKER throws an exception, it should be a compile error. If
>> CHECKER prints stuff out, it should go into the "lein repl" stdout,
>> and if CHECKER doesn't do anything, it's assumed that the namespace
>> passed the check.
>>
>>   Is there a minimal example somewhere of how this works? (i.e.
>> something as stupid as: "this example calls a function, which just
>> prints out the name of all functions defined" would be extremely
>> helpful).
>>
>> 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.

Function that "weaves" two collections together - looking for feedback

[Laurent Droin]

Hi,

Continuing my little pet project (small program really) to learn Clojure, I 
am now working on a function whose description would be something like:
  "Returns a collection 'weaving' 2 collections (boundaries into 
categories).
  Boundaries must have one element less than categories.
  For example, if categories is [:z1 :z2 :z3 :z4 :z5]  
  and boundaries is [120 150 165 180] 
  returns [:z1 120 :z2 150 :z3 165 :z4 180 :z5]"

Assume the precondition is enforced.
If categories has n elements, boundaries has n-1.

I have tried to come up with a good implementation. I actually came up with 
two, one that is non recursive, and one that is recursive. But I'm not 
fully satisfied. I have the feeling that it's possible to make the function 
simpler, and more elegant but I only know a subset of Clojure and am surely 
missing some good idioms that I could/should be using.
So once again, relying on feedback from experienced Clojurists to show me 
the way :-)

Here is what I have so far:

1- the non recursive function - based on mapcat

(defn build-quantize-defs
  [categories boundaries]
(conj (into [] (mapcat #(vector %1 %2) categories boundaries)) (last 
categories)))


2 - the recursive function

(defn build-quantize-defs-recur [categories boundaries]
  (let [c (first categories) b (first boundaries)]
(if (nil? b) 
  [c] 
  (into [] (concat [c] [b] (build-quantize-defs-recur (rest categories) 
(rest boundaries)))


Both functions work (on my example at least).

One of the things I don't like, is my abusing (or the feeling that I am 
abusing anyway) of this "into [] " idiom. I find myself constantly turning 
things into vectors. That doesn't seem right and maybe I am using it in 
places it's not needed. That's probably because I don't quite have a very 
good idea of how collections work just yet. 

Thanks for any feedback.

-- 
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: hooks on "namespace required/loaded"

[Joel Holdbrooks]

I know we talked a bit about this in IRC but this is a hack you could use 
to slurp the file's contents into a string in that file:

(ns foo.core
  (:refer-clojure :exclude [slurp]))
 
(defmacro slurp [file]
  (clojure.core/slurp file))
 
;; In CLJS
 
(ns bar.core
  (:require [foo.core :include-macros true :refer [slurp]]))
 
;; This is possible because we can evaluate *Clojure* code at compile time.
(def project-clj 
  (slurp "project.clj"))


>From there you could then use read-string, or what have you, and examine 
the contents.

Here's a link to the gist for 
reference: https://gist.github.com/noprompt/9086232.

On Tuesday, February 18, 2014 8:32:05 PM UTC-8, t x wrote:
>
> Hi, 
>
>   Although solutions not involving cljx are perfectly fine, I'm using 
> cljx -- so solutions that involves hooking into cljx are perfectly 
> fine too. 
>
>   I have my own "poor-man's lint / type checker" (with different 
> objectives from core.typed). I want a certain function (call it 
> CHECKER) to be called every time a namespace has been "required / 
> loaded / reloaded" 
>
>   Every time I require/load/reload a namespace, I want the following to 
> happen: 
>
> (CHECKER ... source code of the namesapce) 
>
> i.e. something like 
>
> (CHECKER (read-string "namesapce-just-loaded.clj")) 
>
> Then, if CHECKER throws an exception, it should be a compile error. If 
> CHECKER prints stuff out, it should go into the "lein repl" stdout, 
> and if CHECKER doesn't do anything, it's assumed that the namespace 
> passed the check. 
>
>   Is there a minimal example somewhere of how this works? (i.e. 
> something as stupid as: "this example calls a function, which just 
> prints out the name of all functions defined" would be extremely 
> helpful). 
>
> 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.

Re: hooks on "namespace required/loaded"

[Andy Fingerhut]

I am not sure about ClojureScript, but in Clojure/Java you can use
alter-var-root to change the definition of load-libs, which is called by
both require and use.  You can use alter-var-root to change the definition
of any function you want in clojure.core or any other namespace.  I
wouldn't recommend going crazy with it, but it should be able to do the
job, at least after the alter-var-root takes effect.

Out of curiosity, what kind of linting does your function do?

Andy


On Tue, Feb 18, 2014 at 8:41 PM, t x  wrote:

> With apologies for spamming:
>
>   Solutions that involves installing a new lein plugin is fine too.
>
>   I'm willing to completely re-organize my workflow in order to
>
>   * have some other piece of Clojure code gets called / do
> verification whenever a clojure namespace is required/loaded/reloaded
>
> / Done spamming.
>
> On Tue, Feb 18, 2014 at 8:38 PM, t x  wrote:
> > As a point of clarification, read-string is not a hard requirement.
> > Just getting the name of the namespace (and walking through the
> > symbols + calling source on each of them to get the source code is
> > perfeclty fine).
> >
> > Basically, I want to hook a function that
> >   * gets called every time a namespace is loaded/required/reloaded
> >   * gets passed the namespace
> >
> > Thanks!
> >
> > On Tue, Feb 18, 2014 at 8:32 PM, t x  wrote:
> >> Hi,
> >>
> >>   Although solutions not involving cljx are perfectly fine, I'm using
> >> cljx -- so solutions that involves hooking into cljx are perfectly
> >> fine too.
> >>
> >>   I have my own "poor-man's lint / type checker" (with different
> >> objectives from core.typed). I want a certain function (call it
> >> CHECKER) to be called every time a namespace has been "required /
> >> loaded / reloaded"
> >>
> >>   Every time I require/load/reload a namespace, I want the following to
> happen:
> >>
> >> (CHECKER ... source code of the namesapce)
> >>
> >> i.e. something like
> >>
> >> (CHECKER (read-string "namesapce-just-loaded.clj"))
> >>
> >> Then, if CHECKER throws an exception, it should be a compile error. If
> >> CHECKER prints stuff out, it should go into the "lein repl" stdout,
> >> and if CHECKER doesn't do anything, it's assumed that the namespace
> >> passed the check.
> >>
> >>   Is there a minimal example somewhere of how this works? (i.e.
> >> something as stupid as: "this example calls a function, which just
> >> prints out the name of all functions defined" would be extremely
> >> helpful).
> >>
> >> 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.
>

-- 
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: why Clojure/Lisp is so fast

[Andy C]

Thanks for the insight and link to http://benchmarksgame.alioth.debian.org.

WRT dynamically typed languages, I have some 5 years experience with Python
circa 2.4ish timeframe. I remember that a practical raw speed was not that
bad, but still was in average like 10 times slower from C++. Good enough
though. We used it along with Twisted to run some performance tests of
certain closed source messaging system. I was okay until we started playing
with threads/GIL. For obvious reasons it was very taxing and is not even
remotely comparable with modern reactive kind of architectures and STM.

I remember someone presented me how common lisp can disassemble compiled
code in fly - very impressive it was. Not only the possibility but the
quality of a generated machine code as well. Following that experience I
ended up trying https://github.com/gtrak/no.disassemble with no beginners
luck :-( with first steps with lein ... Any idea what went wrong?

$ cat project.clj
(defproject my-project "myREPL"
  :dependencies [[nodisassemble "0.1.2"]])

$ lein repl
nREPL server started on port 62154 on host 127.0.0.1
REPL-y 0.3.0
Clojure 1.4.0
Docs: (doc function-name-here)
  (find-doc "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
 Results: Stored in vars *1, *2, *3, an exception in *e

user=> (require 'no.disassemble)
nil
user=> (in-ns 'no.disassemble)
#
no.disassemble=> (println (disassemble (fn [])))
java.lang.NullPointerException
at
org.eclipse.jdt.internal.core.util.ClassFileStruct.u4At(ClassFileStruct.java:61)
at
org.eclipse.jdt.internal.core.util.ClassFileReader.(ClassFileReader.java:76)

Andy

-- 
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: Function that "weaves" two collections together - looking for feedback

[Michael Gardner]

You may be interested in the core function 'interleave'. As for (into []), it's 
perfectly idiomatic as long as you actually need to return a vector and not 
just some kind of sequence (the more common case). But note also the 
mapv/filterv/reduce-kv family of functions, though they're not directly 
applicable here.

On Feb 18, 2014, at 22:58 , Laurent Droin  wrote:

> Hi,
> 
> Continuing my little pet project (small program really) to learn Clojure, I 
> am now working on a function whose description would be something like:
>   "Returns a collection 'weaving' 2 collections (boundaries into categories).
>   Boundaries must have one element less than categories.
>   For example, if categories is [:z1 :z2 :z3 :z4 :z5]  
>   and boundaries is [120 150 165 180] 
>   returns [:z1 120 :z2 150 :z3 165 :z4 180 :z5]"
> 
> Assume the precondition is enforced.
> If categories has n elements, boundaries has n-1.
> 
> I have tried to come up with a good implementation. I actually came up with 
> two, one that is non recursive, and one that is recursive. But I'm not fully 
> satisfied. I have the feeling that it's possible to make the function 
> simpler, and more elegant but I only know a subset of Clojure and am surely 
> missing some good idioms that I could/should be using.
> So once again, relying on feedback from experienced Clojurists to show me the 
> way :-)
> 
> Here is what I have so far:
> 
> 1- the non recursive function - based on mapcat
> (defn build-quantize-defs
> 
>   
> [categories boundaries]
> 
> 
> (conj (into [] (mapcat #(vector %1 %2) categories boundaries)) (last 
> categories)))
> 
> 2 - the recursive function
> (defn build-quantize-defs-recur [categories boundaries]
> 
>   
> (let [c (first categories) b (first boundaries)]
> 
> 
> (if (nil? b)
>  
>   
> [c]
>  
>   
> (into [] (concat [c] [b] (build-quantize-defs-recur (rest categories) (rest 
> boundaries)))
> 
> Both functions work (on my example at least).
> 
> One of the things I don't like, is my abusing (or the feeling that I am 
> abusing anyway) of this "into [] " idiom. I find myself constantly turning 
> things into vectors. That doesn't seem right and maybe I am using it in 
> places it's not needed. That's probably because I don't quite have a very 
> good idea of how collections work just yet. 
> 
> Thanks for any feedback.

-- 
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: Function that "weaves" two collections together - looking for feedback

[Laurent Droin]

Ah, thank you. "interleave" is what I was looking for. I looked for 
"weave", "zip", "map", "concat", and all the "see also" but did not find 
"interleave".
Interleave will of course not handle the last value in the categories 
collection so my first instinct will be to call (into [] ) on the map 
returned by interleave, and to add (using conj) the (last categories) to 
the vector. Not sure whether there is a better way.

On Tuesday, February 18, 2014 9:17:54 PM UTC-8, Michael Gardner wrote:
>
> You may be interested in the core function 'interleave'. As for (into []), 
> it's perfectly idiomatic as long as you actually need to return a vector 
> and not just some kind of sequence (the more common case). But note also 
> the mapv/filterv/reduce-kv family of functions, though they're not directly 
> applicable here. 
>
> On Feb 18, 2014, at 22:58 , Laurent Droin > 
> wrote: 
>
> > Hi, 
> > 
> > Continuing my little pet project (small program really) to learn 
> Clojure, I am now working on a function whose description would be 
> something like: 
> >   "Returns a collection 'weaving' 2 collections (boundaries into 
> categories). 
> >   Boundaries must have one element less than categories. 
> >   For example, if categories is [:z1 :z2 :z3 :z4 :z5]   
> >   and boundaries is [120 150 165 180] 
> >   returns [:z1 120 :z2 150 :z3 165 :z4 180 :z5]" 
> > 
> > Assume the precondition is enforced. 
> > If categories has n elements, boundaries has n-1. 
> > 
> > I have tried to come up with a good implementation. I actually came up 
> with two, one that is non recursive, and one that is recursive. But I'm not 
> fully satisfied. I have the feeling that it's possible to make the function 
> simpler, and more elegant but I only know a subset of Clojure and am surely 
> missing some good idioms that I could/should be using. 
> > So once again, relying on feedback from experienced Clojurists to show 
> me the way :-) 
> > 
> > Here is what I have so far: 
> > 
> > 1- the non recursive function - based on mapcat 
> > (defn build-quantize-defs 
> > 
> >   
> > [categories boundaries] 
> > 
> > 
> > (conj (into [] (mapcat #(vector %1 %2) categories boundaries)) (last 
> categories))) 
> > 
> > 2 - the recursive function 
> > (defn build-quantize-defs-recur [categories boundaries] 
> > 
> >   
> > (let [c (first categories) b (first boundaries)] 
> > 
> > 
> > (if (nil? b) 
> >   
> >   
> > [c] 
> >   
> >   
> > (into [] (concat [c] [b] (build-quantize-defs-recur (rest categories) 
> (rest boundaries))) 
> > 
> > Both functions work (on my example at least). 
> > 
> > One of the things I don't like, is my abusing (or the feeling that I am 
> abusing anyway) of this "into [] " idiom. I find myself constantly turning 
> things into vectors. That doesn't seem right and maybe I am using it in 
> places it's not needed. That's probably because I don't quite have a very 
> good idea of how collections work just yet. 
> > 
> > Thanks for any feedback. 
>

-- 
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: hooks on "namespace required/loaded"

[t x]

@Joel:

  While on IRC, I completely misunderstood you.

  Now, after looking at it again, it makes sense. This is very cool --
because making it a macro forces it to be evaluated at compile time,
when the source is available. Very nice. :-)

@Andy

  Thanks! I will look into load-libs.

  The following is a bit vague-ish not on purpose, but because part of
it works, part of it is still being hacked together.


## stuff I have:

This is how my current pattern matching / object system looks like:
https://gist.github.com/txrev319/9086538

In a very hackish and theoretically unsound way, each hash-map is an
"object" and the :tag field represents the "type" of the object.


## stuff that are vague because I'm still hacking them together /
thinking about them

### missing feature 1

now, I want to be able to say things like:

:animal = [:cat :dog :mouse]

then, if I do:

(hmatch obj :animal
   :dog ...
   :cat ... )

I want it to give me an error of: "hey, you're not matching against
:mouse" -- and I want this to happen at COMPILE time, not at run time


### missing feature 2

using standard Hindley-Milner, and using the ":tag" field as the type,
I want to be able to tag a function as having a certain type, and have
it verified at compile time -- this is purely optional type checking

a common pattern I run into is:

(async/go
  (loop [msg ( :something"


### in summary,

  I'm basically hacking together poor-man's pattern matching (done)
and type checking (still need more hacking). The idea is:

  * I want a dynamically typed langauge

  * I want to be able to say: "for this subset of functions, they have
type signatures, and we can catch errors statically" (<-- and these
choices are completely adhoc, based on what errors I waste time
catching)



On Tue, Feb 18, 2014 at 9:15 PM, Andy Fingerhut
 wrote:
> I am not sure about ClojureScript, but in Clojure/Java you can use
> alter-var-root to change the definition of load-libs, which is called by
> both require and use.  You can use alter-var-root to change the definition
> of any function you want in clojure.core or any other namespace.  I wouldn't
> recommend going crazy with it, but it should be able to do the job, at least
> after the alter-var-root takes effect.
>
> Out of curiosity, what kind of linting does your function do?
>
> Andy
>
>
> On Tue, Feb 18, 2014 at 8:41 PM, t x  wrote:
>>
>> With apologies for spamming:
>>
>>   Solutions that involves installing a new lein plugin is fine too.
>>
>>   I'm willing to completely re-organize my workflow in order to
>>
>>   * have some other piece of Clojure code gets called / do
>> verification whenever a clojure namespace is required/loaded/reloaded
>>
>> / Done spamming.
>>
>> On Tue, Feb 18, 2014 at 8:38 PM, t x  wrote:
>> > As a point of clarification, read-string is not a hard requirement.
>> > Just getting the name of the namespace (and walking through the
>> > symbols + calling source on each of them to get the source code is
>> > perfeclty fine).
>> >
>> > Basically, I want to hook a function that
>> >   * gets called every time a namespace is loaded/required/reloaded
>> >   * gets passed the namespace
>> >
>> > Thanks!
>> >
>> > On Tue, Feb 18, 2014 at 8:32 PM, t x  wrote:
>> >> Hi,
>> >>
>> >>   Although solutions not involving cljx are perfectly fine, I'm using
>> >> cljx -- so solutions that involves hooking into cljx are perfectly
>> >> fine too.
>> >>
>> >>   I have my own "poor-man's lint / type checker" (with different
>> >> objectives from core.typed). I want a certain function (call it
>> >> CHECKER) to be called every time a namespace has been "required /
>> >> loaded / reloaded"
>> >>
>> >>   Every time I require/load/reload a namespace, I want the following to
>> >> happen:
>> >>
>> >> (CHECKER ... source code of the namesapce)
>> >>
>> >> i.e. something like
>> >>
>> >> (CHECKER (read-string "namesapce-just-loaded.clj"))
>> >>
>> >> Then, if CHECKER throws an exception, it should be a compile error. If
>> >> CHECKER prints stuff out, it should go into the "lein repl" stdout,
>> >> and if CHECKER doesn't do anything, it's assumed that the namespace
>> >> passed the check.
>> >>
>> >>   Is there a minimal example somewhere of how this works? (i.e.
>> >> something as stupid as: "this example calls a function, which just
>> >> prints out the name of all functions defined" would be extremely
>> >> helpful).
>> >>
>> >> 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 gro

Re: Function that "weaves" two collections together - looking for feedback

[Mark Engelberg]

(concat sequence [val])

would often be preferable to

(conj (into [] sequence) val)

because the former solution maintains laziness.


On Tue, Feb 18, 2014 at 9:28 PM, Laurent Droin wrote:

> Ah, thank you. "interleave" is what I was looking for. I looked for
> "weave", "zip", "map", "concat", and all the "see also" but did not find
> "interleave".
> Interleave will of course not handle the last value in the categories
> collection so my first instinct will be to call (into [] ) on the map
> returned by interleave, and to add (using conj) the (last categories) to
> the vector. Not sure whether there is a better way.
>
>
> On Tuesday, February 18, 2014 9:17:54 PM UTC-8, Michael Gardner wrote:
>
>> You may be interested in the core function 'interleave'. As for (into
>> []), it's perfectly idiomatic as long as you actually need to return a
>> vector and not just some kind of sequence (the more common case). But note
>> also the mapv/filterv/reduce-kv family of functions, though they're not
>> directly applicable here.
>>
>> On Feb 18, 2014, at 22:58 , Laurent Droin  wrote:
>>
>> > Hi,
>> >
>> > Continuing my little pet project (small program really) to learn
>> Clojure, I am now working on a function whose description would be
>> something like:
>> >   "Returns a collection 'weaving' 2 collections (boundaries into
>> categories).
>> >   Boundaries must have one element less than categories.
>> >   For example, if categories is [:z1 :z2 :z3 :z4 :z5]
>> >   and boundaries is [120 150 165 180]
>> >   returns [:z1 120 :z2 150 :z3 165 :z4 180 :z5]"
>> >
>> > Assume the precondition is enforced.
>> > If categories has n elements, boundaries has n-1.
>> >
>> > I have tried to come up with a good implementation. I actually came up
>> with two, one that is non recursive, and one that is recursive. But I'm not
>> fully satisfied. I have the feeling that it's possible to make the function
>> simpler, and more elegant but I only know a subset of Clojure and am surely
>> missing some good idioms that I could/should be using.
>> > So once again, relying on feedback from experienced Clojurists to show
>> me the way :-)
>> >
>> > Here is what I have so far:
>> >
>> > 1- the non recursive function - based on mapcat
>> > (defn build-quantize-defs
>> >
>> >
>> > [categories boundaries]
>> >
>> >
>> > (conj (into [] (mapcat #(vector %1 %2) categories boundaries)) (last
>> categories)))
>> >
>> > 2 - the recursive function
>> > (defn build-quantize-defs-recur [categories boundaries]
>> >
>> >
>> > (let [c (first categories) b (first boundaries)]
>> >
>> >
>> > (if (nil? b)
>> >
>> >
>> > [c]
>> >
>> >
>> > (into [] (concat [c] [b] (build-quantize-defs-recur (rest categories)
>> (rest boundaries)))
>> >
>> > Both functions work (on my example at least).
>> >
>> > One of the things I don't like, is my abusing (or the feeling that I am
>> abusing anyway) of this "into [] " idiom. I find myself constantly turning
>> things into vectors. That doesn't seem right and maybe I am using it in
>> places it's not needed. That's probably because I don't quite have a very
>> good idea of how collections work just yet.
>> >
>> > Thanks for any feedback.
>>
>  --
> 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: why Clojure/Lisp is so fast

[David Sletten]

The OP almost certainly intended "CLISP" to mean "Common Lisp".  While the 
CLISP implementation of Common Lisp is a decent platform (Conrad Barski 
features it in his book _Land of Lisp_, for example), it is not the fastest 
implementation. Their documentation acknowledges as much: 
http://www.clisp.org/propaganda.html 
See the section "CLISP Performance" at the bottom of the page.

Have all good days,
David Sletten

On Feb 18, 2014, at 10:37 PM, Mars0i  wrote:

> It really depends on the benchmark and the programmer, and sometimes on the 
> computer.  And on what a person chooses to report. Here are some benchmarks, 
> probably only representative of very special cases, that show Java beating 
> Clojure in many cases, Java and SBCL both beating each other in some cases, 
> etc.  (For my work, I have found SBCL to be a lot faster than CLISP, but 
> again, it probably depends on what you're doing.)
> 
> http://benchmarksgame.alioth.debian.org/
> 
> Other cases would be different.  (None of this conflicts with Mikera's 
> insightful comments.)
> 
> -- 
> 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: why Clojure/Lisp is so fast

[Devin Walters]

You need to use the lein plugin for no.disassemble, not the dependency. The 
README explains how.

Cheers,
'(Devin Walters)

> On Feb 18, 2014, at 23:16, Andy C  wrote:
> 
> Thanks for the insight and link to http://benchmarksgame.alioth.debian.org . 
> 
> WRT dynamically typed languages, I have some 5 years experience with Python 
> circa 2.4ish timeframe. I remember that a practical raw speed was not that 
> bad, but still was in average like 10 times slower from C++. Good enough 
> though. We used it along with Twisted to run some performance tests of 
> certain closed source messaging system. I was okay until we started playing 
> with threads/GIL. For obvious reasons it was very taxing and is not even 
> remotely comparable with modern reactive kind of architectures and STM.
> 
> I remember someone presented me how common lisp can disassemble compiled code 
> in fly - very impressive it was. Not only the possibility but the quality of 
> a generated machine code as well. Following that experience I ended up trying 
> https://github.com/gtrak/no.disassemble with no beginners luck :-( with first 
> steps with lein ... Any idea what went wrong?
> 
> $ cat project.clj 
> (defproject my-project "myREPL"
>   :dependencies [[nodisassemble "0.1.2"]])
> 
> $ lein repl
> nREPL server started on port 62154 on host 127.0.0.1
> REPL-y 0.3.0
> Clojure 1.4.0
> Docs: (doc function-name-here)
>   (find-doc "part-of-name-here")
>   Source: (source function-name-here)
>  Javadoc: (javadoc java-object-or-class-here)
> Exit: Control+D or (exit) or (quit)
>  Results: Stored in vars *1, *2, *3, an exception in *e
> 
> user=> (require 'no.disassemble)
> nil
> user=> (in-ns 'no.disassemble)
> #
> no.disassemble=> (println (disassemble (fn [])))
> java.lang.NullPointerException
> at 
> org.eclipse.jdt.internal.core.util.ClassFileStruct.u4At(ClassFileStruct.java:61)
> at 
> org.eclipse.jdt.internal.core.util.ClassFileReader.(ClassFileReader.java:76)
> 
> Andy
> -- 
> 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.

Post on Clojure Intrinsics

[Gal Dolber]

Here is my first post on clojure, I hope it's helpful!

http://galdolber.tumblr.com/post/77153377251/clojure-intrinsics

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