Re: Why is a non-transient `into` faster than the built-in one?
On my repl into is consistently faster. What versions of clojure, java and the OS are you running? -- 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
Re: Why is a non-transient `into` faster than the built-in one?
I restart the repl and run the two versions, still `into` is slower:
>
>
> user=> (time (do (into #{} (range 1e6)) nil))
> "Elapsed time: 4913.818 msecs"
> nil
> user=> (time (do (naive-into #{} (range 1e6)) nil))
> "Elapsed time: 5599.32 msecs"
> nil
> user=>
> user=> (time (do (naive-into #{} (range 1e6)) nil))
> "Elapsed time: 4030.512 msecs"
> nil
> user=> (time (do (into #{} (range 1e6)) nil))
> "Elapsed time: 5412.179 msecs"
> nil
> user=> (time (do (into #{} (range 1e6)) nil))
> "Elapsed time: 4794.481 msecs"
> nil
> user=> (time (do (naive-into #{} (range 1e6)) nil))
> "Elapsed time: 4430.741 msecs"
> nil
On Sunday, November 4, 2012 11:26:49 AM UTC+8, Herwig Hochleitner wrote:
>
> On my machine the version with into fluctuates around 200ms, whereas the
> version with naive-into fluctuates around 300ms.
> Have you tried running the examples multiple times to give the jit time to
> warm up?
>
--
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
Re: impossible to create classes for non-closure environment
On Sat, 2012-11-03 at 13:57 -0700, Vladimir Tsichevski wrote: > In one of my purely Java project I have to create hundreds of java classes > with repeatable structure, so the task is an excellent candidate for > automation. I hoped I will be able to create these classes with the latest > closure, using the 'deftype' construct. If you know all the details of classes to create at compile time, you can use macros instead, which are perfectly well able to output deftype forms. Untested: (defmacro defrefs "Make a bunch of :x boxes." [& names] `(do ~@(map (fn [name] `(defrecord ~name [~'x])) names))) ;; makes classes foo, bar, baz, qux, quux, all with the :x field. (defrefs foo bar baz qux quux) -- Stephen Compall ^aCollection allSatisfy: [:each|aCondition]: less is better -- 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
Re: Why is a non-transient `into` faster than the built-in one?
On my machine the version with into fluctuates around 200ms, whereas the version with naive-into fluctuates around 300ms. Have you tried running the examples multiple times to give the jit time to warm up? -- 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
Why is a non-transient `into` faster than the built-in one?
Hi, all.
I am following an example demonstrating that `transient` can help optimize
mass updates to data structures:
First, a function is defined, which doesn't use transient collection:
(defn naive-into
> [coll source]
> (reduce conj coll source))
This is supposed to run slower than the built-in `into`, because, as the
book said, `into` uses transient collections whenever possible.
But the result shows up in my `repl` is just the reverse.
> user=> (time (do (into #{} (range 1e6)) nil))
> "Elapsed time: 4882.176 msecs"
> nil
> user=> (time (do (naive-into #{} (range 1e6)) nil))
> "Elapsed time: 3745.707 msecs"
> nil
What could be the reason of this?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Proposal/request: Give clojure.core/conj a unary implementation
That's a good point Alan, and I should have mentioned into.
But this came up for me in a situation relevant to Ben's' point.
I was adding or removing a computed sequence of elements of a set based on
some other
input and was using either conj or disj depending on that input, with apply.
It worked on the disj's but failed on the conj's, of course.
I could in this case have made the check at the time of change and used
into or disj
as appropriate, but in general, one might be passed just the functions as
Ben suggests.
Even if there is a better way to handle this problem in this case, I don't
see it as an argument
against the unary conj. The unary conj is conceptually natural, is
consistent with disj, does not
mask bugs, appears to really have no practical downside, and seems to have
at least one useful application.
Why not include it?
On Saturday, November 3, 2012 7:43:22 PM UTC-4, Ben wrote:
>
> There might be a reason to write (apply f coll seqable) in a situation
> in which f might be conj, though.
>
> On Sat, Nov 3, 2012 at 4:25 PM, Alan Malloy >
> wrote:
> > There is never a reason to write (apply conj ...). Instead, use `into`,
> > which does the same thing but faster and with fewer characters.
> >
> >
> > On Saturday, November 3, 2012 3:27:24 PM UTC-7, CGAT wrote:
> >>
> >> It would be nice if clojure.core/conj had a unary implementation
> >>
> >>([coll] coll)
> >>
> >> The motivating use case is when one is conjoining sequences of
> >> items to a collection all at once:
> >>
> >>(apply conj coll seqable)
> >>
> >> such as (apply conj #{1 2 3} [2 4 6 8 10]).
> >> Currently (1.4.0), this will raise an arity exception
> >> if the seqable object is empty:
> >>
> >>(apply conj #{1 2 3} [])
> >>
> >> necessitating an awkward empty? check when,
> >> for instance, the sequence is computed or passed in.
> >>
> >> It seems to me that making unary conj the identity is both
> >> a natural interpretation and essentially cost free, while
> >> making this use case much more convenient.
> >> Moreover, it is consistent with clojure.core/disj for sets
> >> which does act like this
> >>
> >> (apply disj #{1 2 3} []) -> #{1 2 3}
> >>
> >> and has an identity unary implementation.
> >>
> >> Comments?
> >>
> >>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clo...@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+u...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
>
>
>
> --
> 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
Re: Proposal/request: Give clojure.core/conj a unary implementation
There might be a reason to write (apply f coll seqable) in a situation
in which f might be conj, though.
On Sat, Nov 3, 2012 at 4:25 PM, Alan Malloy wrote:
> There is never a reason to write (apply conj ...). Instead, use `into`,
> which does the same thing but faster and with fewer characters.
>
>
> On Saturday, November 3, 2012 3:27:24 PM UTC-7, CGAT wrote:
>>
>> It would be nice if clojure.core/conj had a unary implementation
>>
>>([coll] coll)
>>
>> The motivating use case is when one is conjoining sequences of
>> items to a collection all at once:
>>
>>(apply conj coll seqable)
>>
>> such as (apply conj #{1 2 3} [2 4 6 8 10]).
>> Currently (1.4.0), this will raise an arity exception
>> if the seqable object is empty:
>>
>>(apply conj #{1 2 3} [])
>>
>> necessitating an awkward empty? check when,
>> for instance, the sequence is computed or passed in.
>>
>> It seems to me that making unary conj the identity is both
>> a natural interpretation and essentially cost free, while
>> making this use case much more convenient.
>> Moreover, it is consistent with clojure.core/disj for sets
>> which does act like this
>>
>> (apply disj #{1 2 3} []) -> #{1 2 3}
>>
>> and has an identity unary implementation.
>>
>> 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
--
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
Re: Proposal/request: Give clojure.core/conj a unary implementation
There is never a reason to write (apply conj ...). Instead, use `into`,
which does the same thing but faster and with fewer characters.
On Saturday, November 3, 2012 3:27:24 PM UTC-7, CGAT wrote:
>
> It would be nice if clojure.core/conj had a unary implementation
>
>([coll] coll)
>
> The motivating use case is when one is conjoining sequences of
> items to a collection all at once:
>
>(apply conj coll seqable)
>
> such as (apply conj #{1 2 3} [2 4 6 8 10]).
> Currently (1.4.0), this will raise an arity exception
> if the seqable object is empty:
>
>(apply conj #{1 2 3} [])
>
> necessitating an awkward empty? check when,
> for instance, the sequence is computed or passed in.
>
> It seems to me that making unary conj the identity is both
> a natural interpretation and essentially cost free, while
> making this use case much more convenient.
> Moreover, it is consistent with clojure.core/disj for sets
> which does act like this
>
> (apply disj #{1 2 3} []) -> #{1 2 3}
>
> and has an identity unary implementation.
>
> 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
Proposal/request: Give clojure.core/conj a unary implementation
It would be nice if clojure.core/conj had a unary implementation
([coll] coll)
The motivating use case is when one is conjoining sequences of
items to a collection all at once:
(apply conj coll seqable)
such as (apply conj #{1 2 3} [2 4 6 8 10]).
Currently (1.4.0), this will raise an arity exception
if the seqable object is empty:
(apply conj #{1 2 3} [])
necessitating an awkward empty? check when,
for instance, the sequence is computed or passed in.
It seems to me that making unary conj the identity is both
a natural interpretation and essentially cost free, while
making this use case much more convenient.
Moreover, it is consistent with clojure.core/disj for sets
which does act like this
(apply disj #{1 2 3} []) -> #{1 2 3}
and has an identity unary implementation.
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
impossible to create classes for non-closure environment
Hi closure developers. In one of my purely Java project I have to create hundreds of java classes with repeatable structure, so the task is an excellent candidate for automation. I hoped I will be able to create these classes with the latest closure, using the 'deftype' construct. I learned currently it is impossible to do that with closure. Is that functionality planned for future releases? What is the correct place to ask for clojure improvements? Regards, Vladimir -- 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
Re: Easy way to implement IFn in java?
Thanks! Works like a charm.
On Friday, 2 November 2012 19:58:19 UTC-4, AtKaaZ wrote:
>
> looks like you can use AFn() in your example
> ie.
> static IFn assoc = new AFn(){
> @Override
> public Object invoke(Object m, Object k, Object v) {
> return RT.assoc(m, k, v);
> }
> };
> (code from clojure.lang.Var.assoc)
>
>
>
> On Sat, Nov 3, 2012 at 12:51 AM, JvJ >wrote:
>
>> I'm writing a Java interface to some Clojure code, and some of the code
>> needs functions as parameters.
>> I'd like to be able create objects from anonymous inner classes.
>> Something like this:
>>
>> func = new IFn(){
>> public Object invoke(obj1,...){
>> //code in here
>> }
>> };
>>
>> I'd like to be able to know if there's a way to do this easily without
>> overloading like 20 methods or whatever.
>>
>> I suppose I could implement my own abstract class and extend that, but I
>> don't want to if I don't have to.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
>
>
>
> --
> I may be wrong or incomplete.
> Please express any corrections / additions,
> they are encouraged and appreciated.
> At least one entity is bound to be transformed if you do ;)
>
>
--
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
Re: Problem installing Noir with Lein
As I understand it, lein-noir was a plugin needed for Leiningen 1.x. But since Leiningen 2 you can create new projects using remote templates without having to install anything. See lein help new: If two arguments are passed, the first should be the name of a template, > and the second is used as the name of the project, for example: > > lein new *$TEMPLATE_NAME* $PROJECT_NAME > > The list of built-in templates can be shown with `lein help new`. > Third-party > templates can be found at https://clojars.org/search?q=lein-template. > *When creating a new project from a third-party template, use its group-id > as the template name. Note that there's no need to "install" a given third- > party template --- lein will automatically fetch it for you*. > This is why you can create a new project with the noir template with: lein new noir project-name Without any plugin. Enjoy :) Il giorno sabato 3 novembre 2012 06:47:46 UTC+1, Satoru Logic ha scritto: > > > > On Saturday, November 3, 2012 12:07:02 PM UTC+8, Sean Corfield wrote: >> >> On Fri, Nov 2, 2012 at 8:15 PM, Satoru Logic wrote: >> > So I add a line of requirement into `~/.lein/profiles.clj`: >> > >> > [lein-noir "1.2.1"] >> >> You should not need that. >> > > Thanks. > > I remove the line from `profiles.clj` and it works! > > >> >> I just tried on my system, which has no ~/.lein/profiles.clj file. I did: >> >> lein new noir my-website >> >> (note the different syntax) >> >> Then: >> >> cd my-website >> lein run >> >> and on http://localhost:8080 I see Noir is up and running... time to >> start building some websites! >> -- >> Sean A Corfield -- (904) 302-SEAN >> An Architect's View -- http://corfield.org/ >> World Singles, LLC. -- http://worldsingles.com/ >> >> "Perfection is the enemy of the good." >> -- Gustave Flaubert, French realist novelist (1821-1880) >> > -- 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
