Re: Bumi, a project for loading a git repo into a Titan graph database
On Feb 21, 2013, at 09:34, Zack Maril wrote: codeq looks fantastic and I've looked into using it before. The project seems to have undergone a flurry of activity last October/November and then nothing has really happened with it since then. Work continues, but getting from Rich Hickey's blog and demo code to a production system (or even a splashy demo :-) is going to take some Real Work (TM). I know that a few folks (at least) are playing with ideas and code, but I don't know of any coordinated project. (I would love to pull together such an effort; if folks are interested, please get in touch!) Meanwhile, here are some other excuses for the lack of visible progress: * Although Rich has given a couple of talks on Codeq, no videos are online. So, the official exposure is mostly limited to a blog entry and a demo. * Moving Codeq from a proof of concept demo to a production app is not a small project. So, some possible contributors may have been scared off. * The codeq mailing list has a configuration problem which keeps new submissions from being accepted. So, some folks may have been unable to participate. * I imagine that Rich has had more pressing issues to deal with (:-). * I've been thinking and writing quite a bit about Codeq, but I haven't had the clues, time, and tuits to create a compelling demo for a mass audience. Which worries me, since if it were so powerful, somebody would have easily done something neat with it by now and talked about it. I actually found Rich's demo to be quite compelling, demonstrating major advances over the state of the art in production documentation generators. Specifically: * The use of a database for storage of harvested data allows arbitrary queries to be made about the code base, encourages post-processing and analysis, etc. * The use of Datomic allows queries to consider the code base's state over time. * The use of data from multiple sources (specifically, analyzers and Git metadata) breaks with the typical data silo approach to documentation generators. I'm VERY interested in the possibility of adding other data sources. * The concept of a code quantum is both novel (AFAIK) and useful (IMNSHO). It allows queries to be made about semantically interesting chunks of code, rather than files, sets of lines, etc. So, despite the fact that the demo uses an extremely limited Clojure analyzer, it can report on: * codeqs (eg, functions) that have had a lot of churn * codeqs that were modified during a specified period I haven't seen anybody actually do anything impressive with it, so I decided to write Bumi instead. I'm pretty agnostic about implementation specifics, but I'd hate to see Rich's design decisions (and their benefits) go away. FWIW, most of my Codeq-related thoughts are written up (or linked from) these pages: http://wiki.cfcl.com/bin/view/Projects/Codeq/SS http://wiki.cfcl.com/bin/view/Projects/Codeq/WebHome -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation -- -- 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: Clojure Performance For Expensive Algorithms
On Wednesday, February 27, 2013 12:53:14 AM UTC+1, Luc wrote: Why insist on getting Clojure to be at par with languages that may offer a performance boost on narrow problems at the expense of making parallel processing and code in general more complex everywhere else ? This doesn't represent anyone's view as expressed in this thread. The goal is *better* (not *best*) performance *without* compromising the good features that make Clojure a joy that it is. The goal is to let people enjoy the nice features in as much of the codebase as possible. -- -- 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: Clojure Performance For Expensive Algorithms
On Wednesday, February 27, 2013 5:19:20 AM UTC+1, Isaac Gouy wrote: If idiomatic Clojure was used... The problem, of course, is that: the code one-person considers to be idiomatic; another person considers to be idiotic, naïve. Not really. Take Stuart Halloway's opening example in the section entitled *Why Clojure?* (defn blank? [s] (every? #(Character/isWhitespace %) s)) Have you ever wondered about its performance? Here you go: user (time (dotimes [_ 1] (blank? ))) Elapsed time: 3887.578 msecs Now imagine Stuart's first concern was demonstrating *performant* Clojure: (defn blank? [^String s] (if (or (nil? s) (= (.length s) 0)) true (loop [i 0] (if ( i (.length s)) (if (Character/isWhitespace (.charAt s i)) (recur (inc i)) false) true user (time (dotimes [_ 1] (blank2? ))) Elapsed time: 4.884 msecs Yes, it's *eight hundred times *faster. But, would anyone care for that? Why bother learning yet another JVM language, with open parens awkwardly transposed and an inconvenient *loop-recur* construct? This is clearly *not* idiomatic Clojure and that is not a subjective appraisal. -Marko -- -- 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: Clojure Performance For Expensive Algorithms
(defn blank? [s] (every? #(Character/isWhitespace %) s)) Have you ever wondered about its performance? Here you go: user (time (dotimes [_ 1] (blank? ))) Elapsed time: 3887.578 msecs To give a more complete picture, this version (defn blank? [s] (every? #(Character/isWhitespace ^char %) s)) is only six times slower than the expanded version, and keeping an eye on reflection warnings is not such a drag. So, if it could be demonstrated that in general the properly type-hinted, but otherwise idiomatic Clojure is not more than 10 times slower than idiomatic Java, I'd consider that at least a good starting point. -Marko -- -- 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: Clojure Performance For Expensive Algorithms
On Wed, Feb 27, 2013 at 10:21 AM, Marko Topolnik marko.topol...@gmail.comwrote: (defn blank? [s] (every? #(Character/isWhitespace %) s)) Have you ever wondered about its performance? Here you go: user (time (dotimes [_ 1] (blank? ))) Elapsed time: 3887.578 msecs To give a more complete picture, this version (defn blank? [s] (every? #(Character/isWhitespace ^char %) s)) is only six times slower than the expanded version, and keeping an eye on reflection warnings is not such a drag. So, if it could be demonstrated that in general the properly type-hinted, but otherwise idiomatic Clojure is not more than 10 times slower than idiomatic Java, I'd consider that at least a good starting point. Now that reduce can be short-circuited, redifining every?, some and al on top of it would yield some interesting gains: (defn revery? [pred coll] (reduce (fn [t x] (if (pred x) t (reduced false))) true coll)) (defn rblank? [s] (revery? #(Character/isWhitespace ^char %) s)) (defn blank? [s] (every? #(Character/isWhitespace ^char %) s)) = (dotimes [_ 10] (time (dotimes [_ 10] (blank? Elapsed time: 515.371 msecs Elapsed time: 500.408 msecs Elapsed time: 507.646 msecs Elapsed time: 644.074 msecs Elapsed time: 529.717 msecs Elapsed time: 482.813 msecs Elapsed time: 557.563 msecs Elapsed time: 486.573 msecs Elapsed time: 493.636 msecs Elapsed time: 481.357 msecs nil = (dotimes [_ 10] (time (dotimes [_ 10] (rblank? Elapsed time: 227.692 msecs Elapsed time: 99.937 msecs Elapsed time: 95.922 msecs Elapsed time: 91.193 msecs Elapsed time: 90.794 msecs Elapsed time: 94.765 msecs Elapsed time: 89.842 msecs Elapsed time: 120.551 msecs Elapsed time: 90.843 msecs Elapsed time: 93.523 msecs nil Christophe -- -- 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: Clojure Performance For Expensive Algorithms
On Wednesday, February 27, 2013 10:59:33 AM UTC+1, Christophe Grand wrote: Now that reduce can be short-circuited, redifining every?, some and al on top of it would yield some interesting gains: (defn revery? [pred coll] (reduce (fn [t x] (if (pred x) t (reduced false))) true coll)) (defn rblank? [s] (revery? #(Character/isWhitespace ^char %) s)) (defn blank? [s] (every? #(Character/isWhitespace ^char %) s)) Christophe These are very interesting results because they show that the current, supposedly optimized implementation involving *recur* is apparently 5x slower than plain *reduce* (the short-circuiting aspect doesn't play a role in this example). -Marko -- -- 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.
New Dutch Clojure group - Rotterdam/Den Haag Clojure Meetup - EHRD.clj
Hi All, On Wednesday 27th March we will be hosting the inaugural EHRD.clj in Rotterdam. The first meeting will feature a talk from Christophe Grandhttp://clj-me.cgrand.net/ (Clojure core contributor and co-author of Clojure Programming) plus beer and nibbles. We will be meeting from 7pm at Lunatech Research B.V. on Heemraadssingel 70 in Rotterdam - a short walk from the central train station. EHRD.clj intends to meet on the fourth Wednesday of every month for a couple of hours. We aim to have a regular format consisting of a short talk on a Clojure library or tool, a discussion of the month's Clojure news and a main feature - maybe a talk, maybe a hack-a-long, maybe a dojo, maybe something else. For more information and agenda for the evening see our Meetup group ( http://www.meetup.com/ehrd-clj/) or follow our twitter feed https://twitter.com/ehrdclj. If you are nearby checkout out our meetup page for schedule and agenda, Vijay Kiran - @vijaykiran | Chris Wilson @minleychris -- -- 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: Clojure Performance For Expensive Algorithms
Hi, the recur is not for optimisation but for short-circuiting so that every? kind of works like and. Stoppable reduce allows now to exploit the internal reduce for strings while still keeping the short-circuiting of every?. Kind regards Meikel -- -- 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: Clojure Performance For Expensive Algorithms
On Wed, Feb 27, 2013 at 11:20 AM, Marko Topolnik marko.topol...@gmail.comwrote: On Wednesday, February 27, 2013 10:59:33 AM UTC+1, Christophe Grand wrote: Now that reduce can be short-circuited, redifining every?, some and al on top of it would yield some interesting gains: (defn revery? [pred coll] (reduce (fn [t x] (if (pred x) t (reduced false))) true coll)) (defn rblank? [s] (revery? #(Character/isWhitespace ^char %) s)) (defn blank? [s] (every? #(Character/isWhitespace ^char %) s)) Christophe These are very interesting results because they show that the current, supposedly optimized implementation involving *recur* is apparently 5x slower than plain *reduce* (the short-circuiting aspect doesn't play a role in this example). Indeed not in this example (all chars are blank and the string is short): but you need short-circuiting to replace seq-based every? by reduce-based every?. reduce is special-cased for Strings (well for StringSeq to be precise). I wouldn't call optimized the seq-idiomatic version which allocates one Cons at each iteration step. Using reduce allows (potentially) to avoid the seq allocations (and reducers allow that on a whole transformation pipeline, without having to (manually) merge everything in the reducing fn). Having a short-circuiting reduce allows for reduce-idiomatic versions of functions that would have been too eager otherwise. -- On Clojure http://clj-me.cgrand.net/ Clojure Programming http://clojurebook.com Training, Consulting Contracting http://lambdanext.eu/ -- -- 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 not when-let* ?
Hi, The when-let macro is great, but it accepts only one binding. Why? Are there any reason why this macro was not ever extended to support multiple bindings (defined, for example, here: http://inclojurewetrust.blogspot.ru/2010/12/when-let-maybe.html)? (when-let* [x (something) y (something1)] (do-something x y)) 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 --- 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.
wouldn't it make sense for identity to take variadic args?
I often find myself asking for identity of something but identity takes
a single argument! Why not have it take as many as one likes but only
return the identity of the first? I find that very handy...do people agree?
(defn identity
Returns its argument or its first argument when there are more.
{:added 1.0
:static true}
([x] x)
([x more] x))
Jim
--
--
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: wouldn't it make sense for identity to take variadic args?
Can you give an example use case?
Personally, I would be a little surprised to find out that identity worked
like this. After all, why return the first argument, why not the last? Or a
vector of all the arguments?
Cheers,
Chris
On 27 February 2013 15:02, Jim foo.bar jimpil1...@gmail.com wrote:
I often find myself asking for identity of something but identity takes a
single argument! Why not have it take as many as one likes but only return
the identity of the first? I find that very handy...do people agree?
(defn identity
Returns its argument or its first argument when there are more.
{:added 1.0
:static true}
([x] x)
([x more] x))
Jim
--
--
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+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/**group/clojure?hl=enhttp://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+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com
.
For more options, visit
https://groups.google.com/**groups/opt_outhttps://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: wouldn't it make sense for identity to take variadic args?
On 27/02/13 12:12, Chris Ford wrote: Can you give an example use case? sure... sometimes I do something this: (map (if even? (fn [num _] (identity spans)) str) some-seq1 some-seq2) but I'd like to write this instead: (map (if even? identity str) some-seq1 some-seq2) Personally, I would be a little surprised to find out that identity worked like this. After all, why return the first argument, why not the last? Or a vector of all the arguments? the idea is to we keep the same semantics as we currently have... Jim -- -- 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: wouldn't it make sense for identity to take variadic args?
thinking about it a bit more, it would certainly make sense to return a seq with all the identities. Then I can just ask for the first...hmm interesting :) Jim On 27/02/13 12:20, Jim foo.bar wrote: On 27/02/13 12:12, Chris Ford wrote: Can you give an example use case? sure... sometimes I do something this: (map (if even? (fn [num _] (identity spans)) str) some-seq1 some-seq2) but I'd like to write this instead: (map (if even? identity str) some-seq1 some-seq2) Personally, I would be a little surprised to find out that identity worked like this. After all, why return the first argument, why not the last? Or a vector of all the arguments? the idea is to we keep the same semantics as we currently have... Jim -- -- 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: wouldn't it make sense for identity to take variadic args?
Apparently you misunderstand the term *identity*. The sense is the same as in *identity transform*: it is a function that transforms its argument into itself. It is useful in the context of higher-order functions where it plays the role of a no-op. None of your uses of *identity* make sense to me. On Wednesday, February 27, 2013 1:20:56 PM UTC+1, Jim foo.bar wrote: On 27/02/13 12:12, Chris Ford wrote: Can you give an example use case? sure... sometimes I do something this: (map (if even? (fn [num _] (identity spans)) str) some-seq1 some-seq2) but I'd like to write this instead: (map (if even? identity str) some-seq1 some-seq2) Personally, I would be a little surprised to find out that identity worked like this. After all, why return the first argument, why not the last? Or a vector of all the arguments? the idea is to we keep the same semantics as we currently have... Jim -- -- 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: wouldn't it make sense for identity to take variadic args?
On 27/02/13 12:35, Marko Topolnik wrote: it is a function that transforms its argument into itself. It is useful in the context of higher-order functions where it plays the role of a no-op that is exactly what I'm trying to do..a no-op based on some condition...Though, I can see why it would be confusing to just return the first arg...what exactly makes no sense? Jim -- -- 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 not when-let* ?
In the short time I've been active in the list, I've seen this topic come up a couple of times, and they both have come up really close to each other also, there's been one in December https://groups.google.com/forum/?fromgroups=#!searchin/clojure/let-else/clojure/1g5dEvIvGYY/EWjwFGnS-rYJand another in January https://groups.google.com/forum/#!searchin/clojure/when-let$20$7C$20if-let/clojure/8wdf9M2KRWI/Ixs8F_aAre4J :P What I understand from those discussions is that there's no single expectation from the user perspective on which logical operator (if any) should be applied to the results of each binding, so any implementation that's chosen would surprise someone. Hope it helps, Juan On Wednesday, February 27, 2013 8:56:14 AM UTC-3, Vladimir Tsichevski wrote: Hi, The when-let macro is great, but it accepts only one binding. Why? Are there any reason why this macro was not ever extended to support multiple bindings (defined, for example, here: http://inclojurewetrust.blogspot.ru/2010/12/when-let-maybe.html)? (when-let* [x (something) y (something1)] (do-something x y)) 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 --- 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: wouldn't it make sense for identity to take variadic args?
In this line: (map (if even? (fn [num _] (identity spans)) str) some-seq1 some-seq2) you appear to involve *identity* in a way that makes no sense since (identity spans) is just spans. You also don't involve the *num* argument at all; but maybe you meant (map (if even? (fn [num _] num) str) some-seq1 some-seq2) Then I'd see what you mean, even though I wouldn't call that function * identity* because it clearly does something more specialized than a no-op: it *ignores* the element coming from some-seq2. It would be quite confusing to see a function named *identity* do that. On Wednesday, February 27, 2013 1:39:54 PM UTC+1, Jim foo.bar wrote: On 27/02/13 12:35, Marko Topolnik wrote: it is a function that transforms its argument into itself. It is useful in the context of higher-order functions where it plays the role of a no-op that is exactly what I'm trying to do..a no-op based on some condition...Though, I can see why it would be confusing to just return the first arg...what exactly makes no sense? Jim -- -- 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: wouldn't it make sense for identity to take variadic args?
On 27/02/13 12:52, Marko Topolnik wrote: In this line: (map (if even? (fn [num _] (identity spans)) str) some-seq1 some-seq2) you appear to involve /identity/ in a way that makes no sense since (identity spans) is just spans. You also don't involve the /num/ argument at all; but maybe you meant Ooops! I do apologize cos in my effort to provide a minimal example I copy-pasted wrongly! The actual code looks like this: (let [tok-array (into-array ^String token-seq)] (map #((if spans? (fn [span _] span) spans-strings) ;;decide what fn to use (.find this tok-array) tok-array) token-seq) As you can see I am sort of creating my own version of identity (fn [span _] span) because I cannot use 'identity' with 2 args. This is my use-case...It should make sense now yes? Jim -- -- 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: wouldn't it make sense for identity to take variadic args?
On Wednesday, February 27, 2013 2:02:36 PM UTC+1, Jim foo.bar wrote: The actual code looks like this: (let [tok-array (into-array ^String token-seq)] (map #((if spans? (fn [span _] span) spans-strings) ;;decide what fn to use (.find this tok-array) tok-array) token-seq) As you can see I am sort of creating my own version of identity (fn [span _] span) because I cannot use 'identity' with 2 args. This is my use-case...It should make sense now yes? Jim Yes, that's it. As I said, I wouldn't want *identity* to do that and find it perfectly reasonable to require a special function for this behavior. A side note: since *spans?* is a constant within the *map* transform, it would pay to decide up-front which function to use: (let [f (if spans? (fn [span _] span) spans-strings)] (map f (.find this tok-array) tok-array)) -- -- 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: wouldn't it make sense for identity to take variadic args?
On 27/02/13 13:10, Marko Topolnik wrote: A side note: since /spans?/ is a constant within the /map/ transform, it would pay to decide up-front which function to use: nice catch! Jim ps: thanks a lot for your 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: Clojure Performance For Expensive Algorithms
Well then lets stop trying to twist the code further. Commenting that Clojure looses in these benchmarks or is pushed in the same backyard than ruby is counter productive. What I have seen so far is pulling toward extreme contorsions to achieve better performance at the expense of code readability. Chritophe's example is how much far I would go while tuning the code to get more speed out of it. Beyond this let's open the hood and look at the internals then... Luc On Wednesday, February 27, 2013 12:53:14 AM UTC+1, Luc wrote: Why insist on getting Clojure to be at par with languages that may offer a performance boost on narrow problems at the expense of making parallel processing and code in general more complex everywhere else ? This doesn't represent anyone's view as expressed in this thread. The goal is *better* (not *best*) performance *without* compromising the good features that make Clojure a joy that it is. The goal is to let people enjoy the nice features in as much of the codebase as possible. -- -- 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. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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 Langohr 1.0.0-beta12 is released
Langohr [1] is a Clojure RabbitMQ client that embraces the AMQP 0.9.1 Model [2]. Release notes for beta12: http://blog.clojurewerkz.org/blog/2013/02/27/langohr-1-dot-0-0-beta12-is-released/ 1. http://clojurerabbitmq.info 2. http://www.rabbitmq.com/tutorials/amqp-concepts.html -- 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: Clojure Performance For Expensive Algorithms
In your specific case, where you want every last inch of performance, it is acceptable that you will need to use the optimized idiom. However, if your overall code did anything else besides banging hard against your algorithm, a performance say 5 times worse than Java may soon become acceptable. In my case, for example, I managed to get the time low enough to be drowned out by index reading times inside Lucene. If I could have achieved that without involving arrays, loops, and defrecords, I wouldn't have a reason to complain. On Wednesday, February 27, 2013 2:29:21 PM UTC+1, Luc wrote: Well then lets stop trying to twist the code further. Commenting that Clojure looses in these benchmarks or is pushed in the same backyard than ruby is counter productive. What I have seen so far is pulling toward extreme contorsions to achieve better performance at the expense of code readability. Chritophe's example is how much far I would go while tuning the code to get more speed out of it. Beyond this let's open the hood and look at the internals then... Luc On Wednesday, February 27, 2013 12:53:14 AM UTC+1, Luc wrote: Why insist on getting Clojure to be at par with languages that may offer a performance boost on narrow problems at the expense of making parallel processing and code in general more complex everywhere else ? This doesn't represent anyone's view as expressed in this thread. The goal is *better* (not *best*) performance *without* compromising the good features that make Clojure a joy that it is. The goal is to let people enjoy the nice features in as much of the codebase as possible. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- Softaddictslprefo...@softaddicts.ca javascript: sent by ibisMail from my ipad! -- -- 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: Clojure Performance For Expensive Algorithms
On Wednesday, February 27, 2013 12:48:13 AM UTC+1, David Nolen wrote: Hang out with JRuby? Seriously? http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=alllang=clojurelang2=jruby Well, all the code-size bars are above the baseline :) Let's see how it fares when they disappear or go below it. Probably because none of these things will ever reveal Clojure performance for non-trivial applications. Overall the performance is great, in my experience, due to low-ceremony architecture of the whole app. Clojure is great at reducing incidental complexity and this is relevant to more than just code aesthetics. Most of the time performance is not about computing power, anyway; that shouldn't say that computing performance is irrelevant. A great language (the right thing) is strong at all fronts. -Marko -- -- 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.
problem redefining protocols and records in emacs+nrepl
Hi all, I'm doing interactive development with emacs+clojure-mode+nrepl and I'm experiencing some seriously annoying problems with protocols and records implementing the protocols: 1) When I redefine a protocol by adding a method to it, and then re-implement a record according in accordance to the changed protocol, clojure complains that it cannot implement a method not in the protocol/interface. 2) when I change a protocol method in an existing record (e.g. by simply adding a println statement) the changes do not have any effect. These problems persist even when I do an nrepl-restart or close emacs and restart. Any ideas? Joachim -- -- 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: Clojure Performance For Expensive Algorithms
I disagree with your last statement. If you look backward, you will find that most languages were created with one or two strong influential ideas at the start. Many of them died of not being extendable to meet new concepts (Snobol, Algol, Simula, APL, ...) It did not prevent many of them to be successfull in terms of popularity for a number of years or decades (Fortran, Cobol, Pascal, Basic, C/C++ are in the top ranks here). They were not strong on all fronts on the contrary. Just look at Cobol... but there are a few hundred millions of Cobol code lines out there driving your bank account. We are even hearing about Cobol rejuvenation from IBM. They were a form of compromise. Clojure will not escape this route. Using the JVM is a compromise. You rely on the JVM and not bare metal. This cuts you out from certain forms of optimizations while on the other hand you are isolated from the bare metal and get access to a richer ecosystem. Relying on JavaScript is even a bigger compromise (no threads, no control over the container, ...) but it gets you everywhere. There's no magic. You cannot win on all fronts. Luc P. On Wednesday, February 27, 2013 12:48:13 AM UTC+1, David Nolen wrote: Hang out with JRuby? Seriously? http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=alllang=clojurelang2=jruby Well, all the code-size bars are above the baseline :) Let's see how it fares when they disappear or go below it. Probably because none of these things will ever reveal Clojure performance for non-trivial applications. Overall the performance is great, in my experience, due to low-ceremony architecture of the whole app. Clojure is great at reducing incidental complexity and this is relevant to more than just code aesthetics. Most of the time performance is not about computing power, anyway; that shouldn't say that computing performance is irrelevant. A great language (the right thing) is strong at all fronts. -Marko -- -- 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. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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: problem redefining protocols and records in emacs+nrepl
I'm not sure I fully understand the problem but I'll do my best to guess... 1) are you sure you're using the protocol or are you actually trying to define a method in the interface that the protocol generates? Try fully qualifying the name of you protocol at the extension point... 2)Do your protocols exist in a separate namespace? Are you reloading the namespace after making changes? Could you provide a minimal example of the problem? I've been using protocols quite heavily lately and I do remember some of these issues but I can't pinpoint your exact problem... Jim ps: are you by any chance trying to create 'mixins'? If yes remember that for a protocol to be fully populated , it must be extended fully per individual type (quote from the JOy of Clojure) On 27/02/13 15:48, Joachim De Beule wrote: Hi all, I'm doing interactive development with emacs+clojure-mode+nrepl and I'm experiencing some seriously annoying problems with protocols and records implementing the protocols: 1) When I redefine a protocol by adding a method to it, and then re-implement a record according in accordance to the changed protocol, clojure complains that it cannot implement a method not in the protocol/interface. 2) when I change a protocol method in an existing record (e.g. by simply adding a println statement) the changes do not have any effect. These problems persist even when I do an nrepl-restart or close emacs and restart. Any ideas? Joachim -- -- 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.
Clojure crash on OpenJDK 8
Hi, lein repl is crashing on OpenJDK 8 consistently for me, with this error: Exception in thread main java.lang.ClassCastException: clojure.tools.nrepl.server.Server cannot be cast to compile__stub.clojure.tools.nrepl.server.Server at clojure.tools.nrepl.server.Server.valAt(server.clj:100) at clojure.lang.KeywordLookupSite$1.get(KeywordLookupSite.java:45) at user$eval966.invoke(NO_SOURCE_FILE:1) at clojure.lang.Compiler.eval(Compiler.java:6511) at clojure.lang.Compiler.eval(Compiler.java:6501) at clojure.lang.Compiler.eval(Compiler.java:6477) at clojure.core$eval.invoke(core.clj:2797) at clojure.main$eval_opt.invoke(main.clj:297) at clojure.main$initialize.invoke(main.clj:316) at clojure.main$null_opt.invoke(main.clj:349) at clojure.main$main.doInvoke(main.clj:427) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.lang.Var.invoke(Var.java:419) at clojure.lang.AFn.applyToHelper(AFn.java:163) at clojure.lang.Var.applyTo(Var.java:532) at clojure.main.main(main.java:37) Is there someone out there with better knowledge of Clojure's internals than me who would like to spend some cycles working with me to try to get to the bottom of this? I have a Mac build of OpenJDK 8 which reproduces the problem, and can bring my knowledge of JVM internals to the party. If you were in London could collaborate face-face, so much the better. Thanks, Ben -- -- 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: Clojure crash on OpenJDK 8
the stacktrace points here: https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/server.clj#L100 but that's all I got:) On Wed, Feb 27, 2013 at 5:47 PM, Ben Evans benjamin.john.ev...@gmail.comwrote: Hi, lein repl is crashing on OpenJDK 8 consistently for me, with this error: Exception in thread main java.lang.ClassCastException: clojure.tools.nrepl.server.Server cannot be cast to compile__stub.clojure.tools.nrepl.server.Server at clojure.tools.nrepl.server.Server.valAt(server.clj:100) at clojure.lang.KeywordLookupSite$1.get(KeywordLookupSite.java:45) at user$eval966.invoke(NO_SOURCE_FILE:1) at clojure.lang.Compiler.eval(Compiler.java:6511) at clojure.lang.Compiler.eval(Compiler.java:6501) at clojure.lang.Compiler.eval(Compiler.java:6477) at clojure.core$eval.invoke(core.clj:2797) at clojure.main$eval_opt.invoke(main.clj:297) at clojure.main$initialize.invoke(main.clj:316) at clojure.main$null_opt.invoke(main.clj:349) at clojure.main$main.doInvoke(main.clj:427) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.lang.Var.invoke(Var.java:419) at clojure.lang.AFn.applyToHelper(AFn.java:163) at clojure.lang.Var.applyTo(Var.java:532) at clojure.main.main(main.java:37) Is there someone out there with better knowledge of Clojure's internals than me who would like to spend some cycles working with me to try to get to the bottom of this? I have a Mac build of OpenJDK 8 which reproduces the problem, and can bring my knowledge of JVM internals to the party. If you were in London could collaborate face-face, so much the better. Thanks, Ben -- -- 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. -- Please correct me if I'm wrong or incomplete, even if you think I'll subconsciously hate it. -- -- 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: Clojure Performance For Expensive Algorithms
On Wednesday, February 27, 2013 1:13:10 AM UTC-8, Marko Topolnik wrote: On Wednesday, February 27, 2013 5:19:20 AM UTC+1, Isaac Gouy wrote: If idiomatic Clojure was used... The problem, of course, is that: the code one-person considers to be idiomatic; another person considers to be idiotic, naïve. Not really. Take Stuart Halloway's opening example in the section entitled *Why Clojure?* (defn blank? [s] (every? #(Character/isWhitespace %) s)) Have you ever wondered about its performance? No. Why would I wonder about the performance of a one line code snippet that was written without concern for performance? -- -- 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.
instance? with one argument
The instance? function does not crash with a single argument, when I think that it should throw an arity exception. I asked on SO about this a while back, so I now know why, but I got hit by this again yesterday. I think this is a bug, but I am not sure whether I have missed a good reason why it is not considered so. http://stackoverflow.com/questions/13176400/clojure-instance-single-argument -- -- 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: Clojure Performance For Expensive Algorithms
On Wednesday, February 27, 2013 5:17:16 PM UTC+1, Luc wrote: There's no magic. You cannot win on all fronts. You defeatist, you :) I'm just trying to represent the enthusiastic perspective where if it *could* be better, it *must* be better. In many respects Clojure already embodies exactly that attitude, that's why we all love it. Maybe some people here feel defensive about the criticism of Clojure's performance from those who have nowhere near the complete picture; that can't be helped, I guess, it's the inescapable nature of such public communication. Still, the complacent tone that often comes out rubs me the wrong way. Don't get me wrong; over the years I have progressed from being in love with Clojure towards it becoming my home sweet home; in your home you take all great things for granted and spend time worrying about those little details that could be made better. -Marko -- -- 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: Clojure Performance For Expensive Algorithms
On Wednesday, February 27, 2013 5:59:25 PM UTC+1, Isaac Gouy wrote: (defn blank? [s] (every? #(Character/isWhitespace %) s)) Have you ever wondered about its performance? No. Why would I wonder about the performance of a one line code snippet that was written without concern for performance? So is that piece of code, by your classification, idiotic, naïve? -- -- 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: Clojure Performance For Expensive Algorithms
Luc makes a good point. And that's one thing that I love about Clojure. It is possible to have (more or less) the same language on different platforms with different trade-offs, with little effort. Just look at the three examples we have now: Clojure - Pretty awesome performance + interop with all of JVM. Tradeoff: JVM and the fact of having to install a runtime, etc. ClojureScript - Runs anywhere JS is supported these days. Tradeoff: Single-threaded, source-to-source compilation. Whole program optimization for best performance. ClojureCLR - Runs on .NET. Better interop with Windows. Tradeoff: Performance (compared to JVM). If we extend this analogy to Stalin Lisp (as mentioned above) we get the following: Stalin - Almost magical performance numbers. Tradeoff: whole program optimizations. Once a binary is compiled, you can't extend that code with more lisp code without re-compilation. And the compilation speed isn't anything to boast about (from what I've heard). Timothy Baldridge On Wed, Feb 27, 2013 at 10:03 AM, Marko Topolnik marko.topol...@gmail.comwrote: On Wednesday, February 27, 2013 5:17:16 PM UTC+1, Luc wrote: There's no magic. You cannot win on all fronts. You defeatist, you :) I'm just trying to represent the enthusiastic perspective where if it *could* be better, it *must* be better. In many respects Clojure already embodies exactly that attitude, that's why we all love it. Maybe some people here feel defensive about the criticism of Clojure's performance from those who have nowhere near the complete picture; that can't be helped, I guess, it's the inescapable nature of such public communication. Still, the complacent tone that often comes out rubs me the wrong way. Don't get me wrong; over the years I have progressed from being in love with Clojure towards it becoming my home sweet home; in your home you take all great things for granted and spend time worrying about those little details that could be made better. -Marko -- -- 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: Clojure Performance For Expensive Algorithms
And by with little effort I mean with little effort compared to porting other languages to different platforms. Given 8 hour work days a single man can hack out Clojure on almost any platform in a few months. That's quite impressive considering how hard it would be to do the same for Ruby/Python/PHP, etc. Timothy On Wed, Feb 27, 2013 at 10:13 AM, Timothy Baldridge tbaldri...@gmail.comwrote: Luc makes a good point. And that's one thing that I love about Clojure. It is possible to have (more or less) the same language on different platforms with different trade-offs, with little effort. Just look at the three examples we have now: Clojure - Pretty awesome performance + interop with all of JVM. Tradeoff: JVM and the fact of having to install a runtime, etc. ClojureScript - Runs anywhere JS is supported these days. Tradeoff: Single-threaded, source-to-source compilation. Whole program optimization for best performance. ClojureCLR - Runs on .NET. Better interop with Windows. Tradeoff: Performance (compared to JVM). If we extend this analogy to Stalin Lisp (as mentioned above) we get the following: Stalin - Almost magical performance numbers. Tradeoff: whole program optimizations. Once a binary is compiled, you can't extend that code with more lisp code without re-compilation. And the compilation speed isn't anything to boast about (from what I've heard). Timothy Baldridge On Wed, Feb 27, 2013 at 10:03 AM, Marko Topolnik marko.topol...@gmail.com wrote: On Wednesday, February 27, 2013 5:17:16 PM UTC+1, Luc wrote: There's no magic. You cannot win on all fronts. You defeatist, you :) I'm just trying to represent the enthusiastic perspective where if it *could* be better, it *must* be better. In many respects Clojure already embodies exactly that attitude, that's why we all love it. Maybe some people here feel defensive about the criticism of Clojure's performance from those who have nowhere near the complete picture; that can't be helped, I guess, it's the inescapable nature of such public communication. Still, the complacent tone that often comes out rubs me the wrong way. Don't get me wrong; over the years I have progressed from being in love with Clojure towards it becoming my home sweet home; in your home you take all great things for granted and spend time worrying about those little details that could be made better. -Marko -- -- 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) -- “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: Clojure Performance For Expensive Algorithms
On Feb 27, 2013, at 9:07 AM, Marko Topolnik wrote: On Wednesday, February 27, 2013 5:59:25 PM UTC+1, Isaac Gouy wrote: (defn blank? [s] (every? #(Character/isWhitespace %) s)) Have you ever wondered about its performance? No. Why would I wonder about the performance of a one line code snippet that was written without concern for performance? So is that piece of code, by your classification, idiotic, naïve? I think that Isaac's point in which he used those adjectives is that reasonable people can disagree what the most idiomatic code is for solving a problem that takes over 20 lines of code (and often even if it takes fewer lines of code than that). When you throw unreasonable people into the mix, the disagreements can only increase. If you wanted to create a collection of idiomatic Clojure programs for solving a particular set of problems, e.g. the Benchmarks Game problems, as soon as more than one person submitted a program and/or reviewed a program, there could arise arguments over which ones are idiomatic and which are not. If one person is maintaining the collection, they can make judgement calls on this, and/or keep multiple different submissions around to solve the same problem as all equally idiomatic, even though they use different code constructs to do it. 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: Clojure crash on OpenJDK 8
what version of clojure are you using? I doubt line #100 of main is the correct line in server.clj, the content of the stacktrace looks more like https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/server.clj#L146, what version of nrepl? https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L7504has a comment that sort of explains why the compiler generates stub classes, this sort of looks like the name of the stub is not getting unmunged somewhere. On Wed, Feb 27, 2013 at 8:53 AM, AtKaaZ atk...@gmail.com wrote: the stacktrace points here: https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/server.clj#L100 but that's all I got:) On Wed, Feb 27, 2013 at 5:47 PM, Ben Evans benjamin.john.ev...@gmail.comwrote: Hi, lein repl is crashing on OpenJDK 8 consistently for me, with this error: Exception in thread main java.lang.ClassCastException: clojure.tools.nrepl.server.Server cannot be cast to compile__stub.clojure.tools.nrepl.server.Server at clojure.tools.nrepl.server.Server.valAt(server.clj:100) at clojure.lang.KeywordLookupSite$1.get(KeywordLookupSite.java:45) at user$eval966.invoke(NO_SOURCE_FILE:1) at clojure.lang.Compiler.eval(Compiler.java:6511) at clojure.lang.Compiler.eval(Compiler.java:6501) at clojure.lang.Compiler.eval(Compiler.java:6477) at clojure.core$eval.invoke(core.clj:2797) at clojure.main$eval_opt.invoke(main.clj:297) at clojure.main$initialize.invoke(main.clj:316) at clojure.main$null_opt.invoke(main.clj:349) at clojure.main$main.doInvoke(main.clj:427) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.lang.Var.invoke(Var.java:419) at clojure.lang.AFn.applyToHelper(AFn.java:163) at clojure.lang.Var.applyTo(Var.java:532) at clojure.main.main(main.java:37) Is there someone out there with better knowledge of Clojure's internals than me who would like to spend some cycles working with me to try to get to the bottom of this? I have a Mac build of OpenJDK 8 which reproduces the problem, and can bring my knowledge of JVM internals to the party. If you were in London could collaborate face-face, so much the better. Thanks, Ben -- -- 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. -- Please correct me if I'm wrong or incomplete, even if you think I'll subconsciously hate it. -- -- 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. -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- -- 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.
How to import classes from a runtime-defined ClassLoader?
I am trying to include some Groovy code at runtime, which is already on the
JVM's classloader path. I have succeeded in setting the
groovy.lang.GroovyClassLoader with Clojure's classloader as the Thread's
contextClassLoader, but I'm having troubling getting (import ...) to work.
I discovered so far that (import ...) prefers to use the
clojure.lang.Compiler/LOADER if it's defined (and it is, in my project), so
I tried the following:
(try
(push-thread-bindings {clojure.lang.Compiler/LOADER
(groovy.lang.GroovyClassLoader.)}
;GroovyCL defaults to use contextClassLoader as parent, which is the
Clojure ClassLoader
(import 'my_groovy_class)
(finally (pop-thread-bindings)))
Note that I can successfully do (.. Thread currentThread
getContextClassLoader (loadCLass my_groovy_class)) once I've set the
contextClassLoader.
What is the way to get (import ...) working so that I can manipulate
my_groovy_class without resorting to forName/createInstance?
--
--
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: Clojure Performance For Expensive Algorithms
On Wednesday, February 27, 2013 6:28:03 PM UTC+1, Andy Fingerhut wrote:
If you wanted to create a collection of idiomatic Clojure programs for
solving a particular set of problems, e.g. the Benchmarks Game problems, as
soon as more than one person submitted a program and/or reviewed a program,
there could arise arguments over which ones are idiomatic and which are not.
If one person is maintaining the collection, they can make judgement calls
on this, and/or keep multiple different submissions around to solve the
same problem as all equally idiomatic, even though they use different code
constructs to do it.
There is much truth in this; however, I bet that all those programs could
in fact be considered idomatic from a wider perspective. One guy prefers *
(reduce...assoc)* where another prefers *(into {}...map...)* and that's OK.
However, if someone comes along with *(let [m (HashMap.)] (loop []...(recur
(.put m ...)))* claiming that is in fact idomatic, he's just being
unreasonable---by everyone's agreement. Yes, in the final analysis there
will always be a fine dividing line over which everyone involved will love
to disagree, but that's a lesser concern.
-Marko
--
--
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 not when-let* ?
On Wed, Feb 27, 2013 at 4:40 AM, juan.facorro juan.faco...@gmail.com wrote: In the short time I've been active in the list, I've seen this topic come up a couple of times, and they both have come up really close to each other also, there's been one in December and another in January :P What I understand from those discussions is that there's no single expectation from the user perspective on which logical operator (if any) should be applied to the results of each binding, so any implementation that's chosen would surprise someone. There's also no need for it to be in the core. when-let* (with your preferred semantics) can be defined in terms of existing constructs. It doesn't need to be primitive the way fn* is. -- 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.
(def newsletter)
I just ran across this and don't see anything about it in my list archives, so... (def newsletter) A weekly Clojure newsletter http://defnewsletter.com Seems like a useful way to keep up with announcements, etc. -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation -- -- 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.
Improving visibility of clojure-doc.org
Started in October 2012, http://clojure-doc.org is a pretty extensive community documentation effort. It covers Clojure, its ecosystem and tools and has two key goals: * We produce beginner-friendly content * It is dead easy to join and help Even though recently that hasn't been as much activity as in the past, it is not abandoned and continues to accumulate useful, beginner-friendly material. We constantly get praises from newcomers to Clojure who discover clojure-doc.org. Unfortunately, it does not appear even in top 10 in Google for clojure docs or clojure documentation and many community members are not aware of it. In part it is less visible because we no longer actively post progress reports. Things have settled down and most of changes now are small edits and improvements all over the place. It is a bit pointless to post progress reports more often than once a month or so. So I'd like to start a discussion about what can be done about it. The community (we have 40 contributors) has worked very hard on clojure-doc.org and I'd like to see high profile resources (namly clojure.org and leiningen.org) link to it. What would it take to convince clojure.org maintainers to do so? There are still guides left ot be written (macros, gen-class), but overall, I'd say there is no better source of freely available, beginner-friendly, hackable (no Clojure CA, everything is developed on GitHub [1], content is in Markdown) documentation. All it needs is some linking and promotion love. One way to help would be to start a campaign such as Mozilla's Promote JS [docs]. Unfortunately, unlike Mozilla key contributors behind clojure-doc.org largely lack graphic and Web design skills, so replicating that campaing is probably not an option. Do you have any ideas about how we can make clojure-doc.org more visible? Do you know who can help with getting a link from clojure.org? Do you think clojure-doc.org is not good enough to be the blessed open source documentation resource? Please post your suggestions and concerns. Improving CDS visibility will benefit the entire community plus all the people who will join it in the future. Most of the work is already done, it just needs to be promoted better. Thanks you. 1. https://github.com/clojuredocs/cds -- 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: Improving visibility of clojure-doc.org
How about introducing a section with solutions to this ( http://projecteuler.net/problems) or other problems. While most of us beginners can write clojure code, solving problems in an idiomatic way is another story. You could have a page for each question and users can each attempt and learn from each others attempts. Just a suggestion. Josh. On Wed, Feb 27, 2013 at 9:06 PM, Michael Klishin michael.s.klis...@gmail.com wrote: Started in October 2012, http://clojure-doc.org is a pretty extensive community documentation effort. It covers Clojure, its ecosystem and tools and has two key goals: * We produce beginner-friendly content * It is dead easy to join and help Even though recently that hasn't been as much activity as in the past, it is not abandoned and continues to accumulate useful, beginner-friendly material. We constantly get praises from newcomers to Clojure who discover clojure-doc.org. Unfortunately, it does not appear even in top 10 in Google for clojure docs or clojure documentation and many community members are not aware of it. In part it is less visible because we no longer actively post progress reports. Things have settled down and most of changes now are small edits and improvements all over the place. It is a bit pointless to post progress reports more often than once a month or so. So I'd like to start a discussion about what can be done about it. The community (we have 40 contributors) has worked very hard on clojure-doc.org and I'd like to see high profile resources (namly clojure.org and leiningen.org) link to it. What would it take to convince clojure.org maintainers to do so? There are still guides left ot be written (macros, gen-class), but overall, I'd say there is no better source of freely available, beginner-friendly, hackable (no Clojure CA, everything is developed on GitHub [1], content is in Markdown) documentation. All it needs is some linking and promotion love. One way to help would be to start a campaign such as Mozilla's Promote JS [docs]. Unfortunately, unlike Mozilla key contributors behind clojure-doc.org largely lack graphic and Web design skills, so replicating that campaing is probably not an option. Do you have any ideas about how we can make clojure-doc.org more visible? Do you know who can help with getting a link from clojure.org? Do you think clojure-doc.org is not good enough to be the blessed open source documentation resource? Please post your suggestions and concerns. Improving CDS visibility will benefit the entire community plus all the people who will join it in the future. Most of the work is already done, it just needs to be promoted better. Thanks you. 1. https://github.com/clojuredocs/cds -- 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: [clj-power] Improving visibility of clojure-doc.org
FWIW, I've added a permanent link to clojure-doc.org from my blog with the link text Clojure Documentation - perhaps others who have blogs could do the same? I was looking at meetup.com to see if I could easily find a way to add resources / links to a group's home page, thinking it would be a good link to have there (Bay Area Clojure User Group). Anyone know enough about meetup.com to point me in the right direction there? Sean On Wed, Feb 27, 2013 at 10:06 AM, Michael Klishin michael.s.klis...@gmail.com wrote: Started in October 2012, http://clojure-doc.org is a pretty extensive community documentation effort. It covers Clojure, its ecosystem and tools and has two key goals: * We produce beginner-friendly content * It is dead easy to join and help Even though recently that hasn't been as much activity as in the past, it is not abandoned and continues to accumulate useful, beginner-friendly material. We constantly get praises from newcomers to Clojure who discover clojure-doc.org. Unfortunately, it does not appear even in top 10 in Google for clojure docs or clojure documentation and many community members are not aware of it. In part it is less visible because we no longer actively post progress reports. Things have settled down and most of changes now are small edits and improvements all over the place. It is a bit pointless to post progress reports more often than once a month or so. So I'd like to start a discussion about what can be done about it. The community (we have 40 contributors) has worked very hard on clojure-doc.org and I'd like to see high profile resources (namly clojure.org and leiningen.org) link to it. What would it take to convince clojure.org maintainers to do so? There are still guides left ot be written (macros, gen-class), but overall, I'd say there is no better source of freely available, beginner-friendly, hackable (no Clojure CA, everything is developed on GitHub [1], content is in Markdown) documentation. All it needs is some linking and promotion love. One way to help would be to start a campaign such as Mozilla's Promote JS [docs]. Unfortunately, unlike Mozilla key contributors behind clojure-doc.org largely lack graphic and Web design skills, so replicating that campaing is probably not an option. Do you have any ideas about how we can make clojure-doc.org more visible? Do you know who can help with getting a link from clojure.org? Do you think clojure-doc.org is not good enough to be the blessed open source documentation resource? Please post your suggestions and concerns. Improving CDS visibility will benefit the entire community plus all the people who will join it in the future. Most of the work is already done, it just needs to be promoted better. Thanks you. 1. https://github.com/clojuredocs/cds -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- You received this message because you are subscribed to the Google Groups clojure-power group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-power+unsubscr...@googlegroups.com. To post to this group, send email to clojure-po...@googlegroups.com. Visit this group at http://groups.google.com/group/clojure-power?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- 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 --- 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: Clojure crash on OpenJDK 8
FWIW, I've just built jdk8-b78 on my linux machine (due to the oracle build being unavailable) and everything seemed to work: % JAVA_CMD=~/checkout/openjdk8/build/linux-x86_64-normal-server-release/images/j2re-image/bin/java lein version Leiningen 2.0.0 on Java 1.8.0-internal OpenJDK 64-Bit Server VM % JAVA_CMD=~/checkout/openjdk8/build/linux-x86_64-normal- server-release/images/j2re-image/bin/java lein repl REPL-y 0.1.9 Clojure 1.4.0 user= (System/getProperty java.version) 1.8.0-internal The error you get looks similar to the kind of errors you can get with AOT compilation, but lein repl shouldn't use an AOT compiled nrepl .. hm .. no idea TBH. -- -- 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: instance? with one argument
This special handling technique is known as a compiler macro in clojurescript (and elsewhere). Essentially, all direct calls to instance? get emitted as an instanceof expression for performance. Higher order uses behave as expected: user= (apply instance? Long []) ArityException Wrong number of args (1) passed to: core$instance-QMARK- clojure.lang.AFn.throwArity (AFn.java:437) Unfortunately the handler in the compiler doesn't do arity checks, hence the behavior you see. IMO this is a bug. I can't speak for clojure/core, but I believe ticket and patch would be welcome in this case. -- -- 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: instance? with one argument
Also direct calls are only handled, if the first arg is a symbol that directly resolves to a class: user= (def C Long) user= (instance? C) ArityException Wrong number of args (1) passed to: core$instance-QMARK- clojure.lang.AFn.throwArity (AFn.java:437) Starting from this, I just discovered another, much more severe bug: user= (let [Long String] (instance? Long abc)) false I've opened a ticket: http://dev.clojure.org/jira/browse/CLJ-1171 -- -- 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: Clojure crash on OpenJDK 8
On Wed, Feb 27, 2013 at 5:42 PM, Kevin Downey redc...@gmail.com wrote: what version of clojure are you using? I doubt line #100 of main is the correct line in server.clj, the content of the stacktrace looks more like https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/server.clj#L146, what version of nrepl? From the working Java 7 install: lein repl nREPL server started on port 53804 REPL-y 0.1.9 Clojure 1.4.0 [snip] user= (System/getProperty java.version) 1.7.0_11 https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L7504 has a comment that sort of explains why the compiler generates stub classes, this sort of looks like the name of the stub is not getting unmunged somewhere. I'll investigate further in that source - thanks. To add a bit more light on this, my JDK 8 Mac build is from the lambda repo, so may have changes which are ahead of mainline JDK8 (to Herwig's point). Does Clojure make use of custom classloading? If so, is there a concise description of how it does so? My top two guesses for a root cause were name mangling custom classloading. Thanks, Ben -- -- 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: Clojure crash on OpenJDK 8
clojure uses a class called DynamicClassloader to load runtime generated classes, but it is a pretty strait forward extension of URLClassloader On Wed, Feb 27, 2013 at 11:27 AM, Ben Evans benjamin.john.ev...@gmail.comwrote: On Wed, Feb 27, 2013 at 5:42 PM, Kevin Downey redc...@gmail.com wrote: what version of clojure are you using? I doubt line #100 of main is the correct line in server.clj, the content of the stacktrace looks more like https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/server.clj#L146 , what version of nrepl? From the working Java 7 install: lein repl nREPL server started on port 53804 REPL-y 0.1.9 Clojure 1.4.0 [snip] user= (System/getProperty java.version) 1.7.0_11 https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L7504 has a comment that sort of explains why the compiler generates stub classes, this sort of looks like the name of the stub is not getting unmunged somewhere. I'll investigate further in that source - thanks. To add a bit more light on this, my JDK 8 Mac build is from the lambda repo, so may have changes which are ahead of mainline JDK8 (to Herwig's point). Does Clojure make use of custom classloading? If so, is there a concise description of how it does so? My top two guesses for a root cause were name mangling custom classloading. Thanks, Ben -- -- 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. -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- -- 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: [clj-power] Improving visibility of clojure-doc.org
I've updated http://clojure.org/documentation to add a link to http://clojure-doc.org. I think it's a great resource for all Clojure developers!! I think it would be useful in your regular updates to highlight areas that could use help. Another area that I think would be useful in addition to the current docs are smallish examples of full projects that highlight how to put the existing pieces together into a (small) real project. Alex On Wed, Feb 27, 2013 at 12:06 PM, Michael Klishin michael.s.klis...@gmail.com wrote: Started in October 2012, http://clojure-doc.org is a pretty extensive community documentation effort. It covers Clojure, its ecosystem and tools and has two key goals: * We produce beginner-friendly content * It is dead easy to join and help Even though recently that hasn't been as much activity as in the past, it is not abandoned and continues to accumulate useful, beginner-friendly material. We constantly get praises from newcomers to Clojure who discover clojure-doc.org. Unfortunately, it does not appear even in top 10 in Google for clojure docs or clojure documentation and many community members are not aware of it. In part it is less visible because we no longer actively post progress reports. Things have settled down and most of changes now are small edits and improvements all over the place. It is a bit pointless to post progress reports more often than once a month or so. So I'd like to start a discussion about what can be done about it. The community (we have 40 contributors) has worked very hard on clojure-doc.org and I'd like to see high profile resources (namly clojure.org and leiningen.org) link to it. What would it take to convince clojure.org maintainers to do so? There are still guides left ot be written (macros, gen-class), but overall, I'd say there is no better source of freely available, beginner-friendly, hackable (no Clojure CA, everything is developed on GitHub [1], content is in Markdown) documentation. All it needs is some linking and promotion love. One way to help would be to start a campaign such as Mozilla's Promote JS [docs]. Unfortunately, unlike Mozilla key contributors behind clojure-doc.org largely lack graphic and Web design skills, so replicating that campaing is probably not an option. Do you have any ideas about how we can make clojure-doc.org more visible? Do you know who can help with getting a link from clojure.org? Do you think clojure-doc.org is not good enough to be the blessed open source documentation resource? Please post your suggestions and concerns. Improving CDS visibility will benefit the entire community plus all the people who will join it in the future. Most of the work is already done, it just needs to be promoted better. Thanks you. 1. https://github.com/clojuredocs/cds -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- You received this message because you are subscribed to the Google Groups clojure-power group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-power+unsubscr...@googlegroups.com. To post to this group, send email to clojure-po...@googlegroups.com. Visit this group at http://groups.google.com/group/clojure-power?hl=en. 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: Clojure crash on OpenJDK 8
2013/2/27 Ben Evans benjamin.john.ev...@gmail.com To add a bit more light on this, my JDK 8 Mac build is from the lambda repo, so may have changes which are ahead of mainline JDK8 (to Herwig's point). Tried lambda-8-b79-linux-x64-25_feb_2013.tar.gz from http://jdk8.java.net/lambda/ it works for me aswell. I gotta run now, later I could try the hg tip of the lambda repo. Is there anything else I could try to reproduce it on my linux machine? Could it be an OSX specific issue maybe? -- -- 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: core.logic: Dividing the knowledge base
Sounds like an interesting idea though I can't give much guidance about how to approach it. Curious to know how it goes though! On Wed, Feb 27, 2013 at 3:50 PM, JvJ kfjwhee...@gmail.com wrote: I'm creating something with core.logic that involves multiple agents(not the same as a clojure agent!) which each have distinct knowledge. I'd like to know the best way of going about separating the knowledge base so that it can be accessed by each agent individually. The simplest thing I can think of is to define each relation with an additional agent parameter, but that seems sloppy and I'm not sure if it would be efficient. Is this a good approach, or is there something better I can do? 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: core.logic: Dividing the knowledge base
Thanks for the quick reply. I guess I'll go through with my initial plan and see what happens. Thanks. On Wednesday, 27 February 2013 16:14:49 UTC-5, David Nolen wrote: Sounds like an interesting idea though I can't give much guidance about how to approach it. Curious to know how it goes though! On Wed, Feb 27, 2013 at 3:50 PM, JvJ kfjwh...@gmail.com javascript:wrote: I'm creating something with core.logic that involves multiple agents(not the same as a clojure agent!) which each have distinct knowledge. I'd like to know the best way of going about separating the knowledge base so that it can be accessed by each agent individually. The simplest thing I can think of is to define each relation with an additional agent parameter, but that seems sloppy and I'm not sure if it would be efficient. Is this a good approach, or is there something better I can do? Thanks -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/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: core.logic: Dividing the knowledge base
Actually, I have a quick question. How could I modify the following code to add some metadata to he newly defined relation? (defmacro defkrel Macro for defining knowledge-based relations. [nme rest] `(defrel ~nme ~'agent ~@rest)) On Wednesday, 27 February 2013 16:17:30 UTC-5, JvJ wrote: Thanks for the quick reply. I guess I'll go through with my initial plan and see what happens. Thanks. On Wednesday, 27 February 2013 16:14:49 UTC-5, David Nolen wrote: Sounds like an interesting idea though I can't give much guidance about how to approach it. Curious to know how it goes though! On Wed, Feb 27, 2013 at 3:50 PM, JvJ kfjwh...@gmail.com wrote: I'm creating something with core.logic that involves multiple agents(not the same as a clojure agent!) which each have distinct knowledge. I'd like to know the best way of going about separating the knowledge base so that it can be accessed by each agent individually. The simplest thing I can think of is to define each relation with an additional agent parameter, but that seems sloppy and I'm not sure if it would be efficient. Is this a good approach, or is there something better I can do? Thanks -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: core.logic: Dividing the knowledge base
Hrm, how are you going to consume that metadata? On Wed, Feb 27, 2013 at 4:26 PM, JvJ kfjwhee...@gmail.com wrote: Actually, I have a quick question. How could I modify the following code to add some metadata to he newly defined relation? (defmacro defkrel Macro for defining knowledge-based relations. [nme rest] `(defrel ~nme ~'agent ~@rest)) On Wednesday, 27 February 2013 16:17:30 UTC-5, JvJ wrote: Thanks for the quick reply. I guess I'll go through with my initial plan and see what happens. Thanks. On Wednesday, 27 February 2013 16:14:49 UTC-5, David Nolen wrote: Sounds like an interesting idea though I can't give much guidance about how to approach it. Curious to know how it goes though! On Wed, Feb 27, 2013 at 3:50 PM, JvJ kfjwh...@gmail.com wrote: I'm creating something with core.logic that involves multiple agents(not the same as a clojure agent!) which each have distinct knowledge. I'd like to know the best way of going about separating the knowledge base so that it can be accessed by each agent individually. The simplest thing I can think of is to define each relation with an additional agent parameter, but that seems sloppy and I'm not sure if it would be efficient. Is this a good approach, or is there something better I can do? Thanks -- -- 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=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://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.
defmacro/gen-class/annotation woes
Hi Folks,
I'm attempting to write a clojure macro that uses gen-class to replace
several manually written Java classes that all follow a similar pattern.
Yes, in my magic world of unicorns and mermaids, I would just rewrite them
in pure clojure, but for the context of this question my solution has to
generate Java classes (I can elaborate if anybody really wants to know).
The problem is that my macro is apparently unable to emit gen-class code
that will include annotations in the class. I've boiled my problem down to
this example:
(gen-class
:name ^{Deprecated true} Test1
:prefix Test1-
:methods [[^{Deprecated true} getValue [] Integer]])
(defn Test1-getValue [] 42)
(defmacro create-test-class [name x]
(let [prefix (str name -)]
`(do
(gen-class
:name ~(with-meta name {Deprecated true})
:prefix ~(symbol prefix)
:methods [[~(with-meta 'getValue {Deprecated true}) [] Integer]])
(defn ~(symbol (str prefix getValue)) [] ~x
(create-test-class Test2 56)
When I compile this file, it creates a Test1.class and Test2.class - I
inspect both with Eclipse, and find that Test1 has both class-level and
method-level @Deprecated annotations, but Test2.class has no annotations.
When I use macroexpand, it looks as though my Test2.class should be
annotated:
user= (set! **print-meta** true)
true
user= (macroexpand '(create-test-class Test2 56))
(do (clojure.core/gen-class :name ^{java.lang.Deprecated true} Test2
:prefix Test2- :methods [[^{java.lang.Deprecated true} getValue []
java.lang.Integer]]) (user/defn Test2-getValue [] 56))
Is there something wrong with the way that I attempt to attach the metadata?
Thanks!
Michael Willis
--
--
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: [clj-power] Improving visibility of clojure-doc.org
I added a link to http://clojure-doc.org in both the group discussion and the about page for the Den of Clojure (http://www.meetup.com/denofclojure/). Sean (or anyone else for that matter) is there an easy way we can let the rest of the user group to lend a hand? Is there a better place to post the link on the meetup site? Daniel On Wednesday, February 27, 2013 12:55:09 PM UTC-7, Alex Miller wrote: I've updated http://clojure.org/documentation to add a link to http://clojure-doc.org. I think it's a great resource for all Clojure developers!! I think it would be useful in your regular updates to highlight areas that could use help. Another area that I think would be useful in addition to the current docs are smallish examples of full projects that highlight how to put the existing pieces together into a (small) real project. Alex On Wed, Feb 27, 2013 at 12:06 PM, Michael Klishin michael@gmail.comjavascript: wrote: Started in October 2012, http://clojure-doc.org is a pretty extensive community documentation effort. It covers Clojure, its ecosystem and tools and has two key goals: * We produce beginner-friendly content * It is dead easy to join and help Even though recently that hasn't been as much activity as in the past, it is not abandoned and continues to accumulate useful, beginner-friendly material. We constantly get praises from newcomers to Clojure who discover clojure-doc.org. Unfortunately, it does not appear even in top 10 in Google for clojure docs or clojure documentation and many community members are not aware of it. In part it is less visible because we no longer actively post progress reports. Things have settled down and most of changes now are small edits and improvements all over the place. It is a bit pointless to post progress reports more often than once a month or so. So I'd like to start a discussion about what can be done about it. The community (we have 40 contributors) has worked very hard on clojure-doc.org and I'd like to see high profile resources (namly clojure.org and leiningen.org) link to it. What would it take to convince clojure.org maintainers to do so? There are still guides left ot be written (macros, gen-class), but overall, I'd say there is no better source of freely available, beginner-friendly, hackable (no Clojure CA, everything is developed on GitHub [1], content is in Markdown) documentation. All it needs is some linking and promotion love. One way to help would be to start a campaign such as Mozilla's Promote JS [docs]. Unfortunately, unlike Mozilla key contributors behind clojure-doc.org largely lack graphic and Web design skills, so replicating that campaing is probably not an option. Do you have any ideas about how we can make clojure-doc.org more visible? Do you know who can help with getting a link from clojure.org? Do you think clojure-doc.org is not good enough to be the blessed open source documentation resource? Please post your suggestions and concerns. Improving CDS visibility will benefit the entire community plus all the people who will join it in the future. Most of the work is already done, it just needs to be promoted better. Thanks you. 1. https://github.com/clojuredocs/cds -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- You received this message because you are subscribed to the Google Groups clojure-power group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-powe...@googlegroups.com javascript:. To post to this group, send email to clojur...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/group/clojure-power?hl=en. 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: core.logic: Dividing the knowledge base
Actually, I figured it out. I just didn't realize you had to do the #'
thing to get the meta from a function.
But! I'm basically going to write a variation of run* that binds an agent
to the first argument of any knowledge-based relations. So, if they have
something like {:knowledge true} in their metadata, the first argument is
replaced with the agent.
On Wednesday, 27 February 2013 16:29:24 UTC-5, David Nolen wrote:
Hrm, how are you going to consume that metadata?
On Wed, Feb 27, 2013 at 4:26 PM, JvJ kfjwh...@gmail.com javascript:wrote:
Actually, I have a quick question. How could I modify the following code
to add some metadata to he newly defined relation?
(defmacro defkrel
Macro for defining knowledge-based relations.
[nme rest]
`(defrel ~nme
~'agent
~@rest))
On Wednesday, 27 February 2013 16:17:30 UTC-5, JvJ wrote:
Thanks for the quick reply. I guess I'll go through with my initial
plan and see what happens. Thanks.
On Wednesday, 27 February 2013 16:14:49 UTC-5, David Nolen wrote:
Sounds like an interesting idea though I can't give much guidance about
how to approach it. Curious to know how it goes though!
On Wed, Feb 27, 2013 at 3:50 PM, JvJ kfjwh...@gmail.com wrote:
I'm creating something with core.logic that involves multiple
agents(not the same as a clojure agent!) which each have distinct
knowledge. I'd like to know the best way of going about separating the
knowledge base so that it can be accessed by each agent individually.
The simplest thing I can think of is to define each relation with an
additional agent parameter, but that seems sloppy and I'm not sure if it
would be efficient. Is this a good approach, or is there something
better
I can do?
Thanks
--
--
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=enhttp://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+u...@googlegroups.com.
For more options, visit
https://groups.google.com/**groups/opt_outhttps://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 clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+u...@googlegroups.com javascript:.
For more options, visit https://groups.google.com/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: core.logic: Dividing the knowledge base
On Wed, Feb 27, 2013 at 2:50 PM, JvJ kfjwhee...@gmail.com wrote: I'm creating something with core.logic that involves multiple agents(not the same as a clojure agent!) which each have distinct knowledge. I'd like to know the best way of going about separating the knowledge base so that it can be accessed by each agent individually. The simplest thing I can think of is to define each relation with an additional agent parameter, but that seems sloppy and I'm not sure if it would be efficient. Is this a good approach, or is there something better I can do? Threatgrid had the problem of wanting to have distinct datasets over the same relations. Our solutions was to declare facts in to a persistent logic db and refer them explicitly when performing queries. I've released part of that work here: https://github.com/threatgrid/pldb There's a branch with indexing support on my fork, and I have a few other enhancements queued up. We use this code on some very large datasets and it is working well for us. -- -- 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: core.logic: Dividing the knowledge base
I'm also enthusiastic about eventually replacing the current core.logic defrel/fact stuff with this excellent work. David On Wed, Feb 27, 2013 at 4:45 PM, Norman Richards o...@nostacktrace.comwrote: On Wed, Feb 27, 2013 at 2:50 PM, JvJ kfjwhee...@gmail.com wrote: I'm creating something with core.logic that involves multiple agents(not the same as a clojure agent!) which each have distinct knowledge. I'd like to know the best way of going about separating the knowledge base so that it can be accessed by each agent individually. The simplest thing I can think of is to define each relation with an additional agent parameter, but that seems sloppy and I'm not sure if it would be efficient. Is this a good approach, or is there something better I can do? Threatgrid had the problem of wanting to have distinct datasets over the same relations. Our solutions was to declare facts in to a persistent logic db and refer them explicitly when performing queries. I've released part of that work here: https://github.com/threatgrid/pldb There's a branch with indexing support on my fork, and I have a few other enhancements queued up. We use this code on some very large datasets and it is working well for us. -- -- 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: core.logic: Dividing the knowledge base
Wow. Thanks, this will probably help a lot! On Wednesday, 27 February 2013 16:45:07 UTC-5, Norman Richards wrote: On Wed, Feb 27, 2013 at 2:50 PM, JvJ kfjwh...@gmail.com javascript:wrote: I'm creating something with core.logic that involves multiple agents(not the same as a clojure agent!) which each have distinct knowledge. I'd like to know the best way of going about separating the knowledge base so that it can be accessed by each agent individually. The simplest thing I can think of is to define each relation with an additional agent parameter, but that seems sloppy and I'm not sure if it would be efficient. Is this a good approach, or is there something better I can do? Threatgrid had the problem of wanting to have distinct datasets over the same relations. Our solutions was to declare facts in to a persistent logic db and refer them explicitly when performing queries. I've released part of that work here: https://github.com/threatgrid/pldb There's a branch with indexing support on my fork, and I have a few other enhancements queued up. We use this code on some very large datasets and it is working well for us. -- -- 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: core.logic: Dividing the knowledge base
It states that retractions aren't yet implemented. Is there any way to delete facts? On Wednesday, 27 February 2013 16:45:07 UTC-5, Norman Richards wrote: On Wed, Feb 27, 2013 at 2:50 PM, JvJ kfjwh...@gmail.com javascript:wrote: I'm creating something with core.logic that involves multiple agents(not the same as a clojure agent!) which each have distinct knowledge. I'd like to know the best way of going about separating the knowledge base so that it can be accessed by each agent individually. The simplest thing I can think of is to define each relation with an additional agent parameter, but that seems sloppy and I'm not sure if it would be efficient. Is this a good approach, or is there something better I can do? Threatgrid had the problem of wanting to have distinct datasets over the same relations. Our solutions was to declare facts in to a persistent logic db and refer them explicitly when performing queries. I've released part of that work here: https://github.com/threatgrid/pldb There's a branch with indexing support on my fork, and I have a few other enhancements queued up. We use this code on some very large datasets and it is working well for us. -- -- 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: core.logic: Dividing the knowledge base
On Wed, Feb 27, 2013 at 4:03 PM, JvJ kfjwhee...@gmail.com wrote: It states that retractions aren't yet implemented. Is there any way to delete facts? This is something I want to add, and if it's something you could use now, I'll bump up priority of getting that in. What we do is just build a new logic db for each runs with different facts, which is why it hasn't been implemented yet. -- -- 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: core.logic: Dividing the knowledge base
If it's not too much trouble, it's something I'd like to see, but I'm sure I can find a way around it somehow. On Wednesday, 27 February 2013 17:08:24 UTC-5, Norman Richards wrote: On Wed, Feb 27, 2013 at 4:03 PM, JvJ kfjwh...@gmail.com javascript:wrote: It states that retractions aren't yet implemented. Is there any way to delete facts? This is something I want to add, and if it's something you could use now, I'll bump up priority of getting that in. What we do is just build a new logic db for each runs with different facts, which is why it hasn't been implemented yet. -- -- 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: Clojure Performance For Expensive Algorithms
On Wednesday, February 27, 2013 9:48:15 AM UTC-8, Marko Topolnik wrote: However, if someone comes along with *(let [m (HashMap.)] (loop []...(recur (.put m ...)))* claiming that is in fact idomatic, he's just being unreasonable---by everyone's agreement. You don't think there are fast-code idioms? -- -- 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: core.logic: Dividing the knowledge base
One more thing I'd like to ask. Is it possible to combine the databases in a way? For instance, I'd like to have a universal database that every agent can access, as well as agent-specific databases. I understand that databases can be modified in a purely functional way (which is great), but I'm wondering if there's a way for changes in the universal database to be reflected in the others. On Wednesday, 27 February 2013 17:12:24 UTC-5, JvJ wrote: If it's not too much trouble, it's something I'd like to see, but I'm sure I can find a way around it somehow. On Wednesday, 27 February 2013 17:08:24 UTC-5, Norman Richards wrote: On Wed, Feb 27, 2013 at 4:03 PM, JvJ kfjwh...@gmail.com wrote: It states that retractions aren't yet implemented. Is there any way to delete facts? This is something I want to add, and if it's something you could use now, I'll bump up priority of getting that in. What we do is just build a new logic db for each runs with different facts, which is why it hasn't been implemented yet. -- -- 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] clj-nio2 0.1.0
Hi, I implemented some high-level wrappers for the File(system) improvements introducedin NIO.2/Java 7. In particular: - Handle filesystem events (WatchService) via a lazy *watch-se*q - Read directories using a lazy *dir-seq* - Implementation of * clojure.java.io/Coercions * and * clojure.java.io/IOFactory* protocols for NIO.2 paths. More Infos and a quick walkthrough: https://github.com/juergenhoetzel/clj-nio2 Jürgen -- -- 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: Clojure Performance For Expensive Algorithms
On 2/27/13 9:59 AM, Isaac Gouy wrote: On Wednesday, February 27, 2013 1:13:10 AM UTC-8, Marko Topolnik wrote: On Wednesday, February 27, 2013 5:19:20 AM UTC+1, Isaac Gouy wrote: If idiomatic Clojure was used... The problem, of course, is that: the code one-person considers to be idiomatic; another person considers to be idiotic, naīve. Not really. Take Stuart Halloway's opening example in the section entitled /Why Clojure?/ (defn blank? [s] (every? #(Character/isWhitespace %) s)) Have you ever wondered about its performance? No. Why would I wonder about the performance of a one line code snippet that was written without concern for performance? Because that one line of code is representative of the majority of clojure functions (i.e. idiomatic clojure using core functions against seqs). -Ben -- -- 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: problem redefining protocols and records in emacs+nrepl
Hi Jim, I'm sorry I can't really be more specific. I tried to duplicate the problems with a few simple steps, but they only seem to turn when things get complicates, e.g. involve different namespaces etc. I now even encountered a third problem which I think is related to the other two because it involves caching of protocol functions: - In namespace 1, I define and create a record, say R, that implements a protocol P as defined in namespace 2. - In a third namespace I call a method called classes of protocol P on record R, i.e. I evaluate (classes R). Clojure then complains with IllegalArgumentException No implementation of method: :classes of protocol: #'sentiment.protocols/ClassifierP found for class: sentiment.classification.client$fn__1479 clojure.core/-cache-protocol-fn (core_deftype.clj:527). - when I evaluate (classes R) in namespace 1 (of R), no exception is raised Both namespaces A and C use namespace B. Op woensdag 27 februari 2013 17:19:33 UTC+1 schreef Jim foo.bar het volgende: I'm not sure I fully understand the problem but I'll do my best to guess... 1) are you sure you're using the protocol or are you actually trying to define a method in the interface that the protocol generates? Try fully qualifying the name of you protocol at the extension point... 2)Do your protocols exist in a separate namespace? Are you reloading the namespace after making changes? Could you provide a minimal example of the problem? I've been using protocols quite heavily lately and I do remember some of these issues but I can't pinpoint your exact problem... Jim ps: are you by any chance trying to create 'mixins'? If yes remember that for a protocol to be fully populated , it must be extended fully per individual type (quote from the JOy of Clojure) On 27/02/13 15:48, Joachim De Beule wrote: Hi all, I'm doing interactive development with emacs+clojure-mode+nrepl and I'm experiencing some seriously annoying problems with protocols and records implementing the protocols: 1) When I redefine a protocol by adding a method to it, and then re-implement a record according in accordance to the changed protocol, clojure complains that it cannot implement a method not in the protocol/interface. 2) when I change a protocol method in an existing record (e.g. by simply adding a println statement) the changes do not have any effect. These problems persist even when I do an nrepl-restart or close emacs and restart. Any ideas? Joachim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/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: problem redefining protocols and records in emacs+nrepl
(At the end of my previous update, I mean namespaces 1, 2 and 3 instead of A, B and C. Sorry for that ...) Op woensdag 27 februari 2013 23:49:42 UTC+1 schreef Joachim De Beule het volgende: Hi Jim, I'm sorry I can't really be more specific. I tried to duplicate the problems with a few simple steps, but they only seem to turn when things get complicates, e.g. involve different namespaces etc. I now even encountered a third problem which I think is related to the other two because it involves caching of protocol functions: - In namespace 1, I define and create a record, say R, that implements a protocol P as defined in namespace 2. - In a third namespace I call a method called classes of protocol P on record R, i.e. I evaluate (classes R). Clojure then complains with IllegalArgumentException No implementation of method: :classes of protocol: #'sentiment.protocols/ClassifierP found for class: sentiment.classification.client$fn__1479 clojure.core/-cache-protocol-fn (core_deftype.clj:527). - when I evaluate (classes R) in namespace 1 (of R), no exception is raised Both namespaces A and C use namespace B. Op woensdag 27 februari 2013 17:19:33 UTC+1 schreef Jim foo.bar het volgende: I'm not sure I fully understand the problem but I'll do my best to guess... 1) are you sure you're using the protocol or are you actually trying to define a method in the interface that the protocol generates? Try fully qualifying the name of you protocol at the extension point... 2)Do your protocols exist in a separate namespace? Are you reloading the namespace after making changes? Could you provide a minimal example of the problem? I've been using protocols quite heavily lately and I do remember some of these issues but I can't pinpoint your exact problem... Jim ps: are you by any chance trying to create 'mixins'? If yes remember that for a protocol to be fully populated , it must be extended fully per individual type (quote from the JOy of Clojure) On 27/02/13 15:48, Joachim De Beule wrote: Hi all, I'm doing interactive development with emacs+clojure-mode+nrepl and I'm experiencing some seriously annoying problems with protocols and records implementing the protocols: 1) When I redefine a protocol by adding a method to it, and then re-implement a record according in accordance to the changed protocol, clojure complains that it cannot implement a method not in the protocol/interface. 2) when I change a protocol method in an existing record (e.g. by simply adding a println statement) the changes do not have any effect. These problems persist even when I do an nrepl-restart or close emacs and restart. Any ideas? Joachim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: problem redefining protocols and records in emacs+nrepl
Oops, sorry again, this last problem was just a stupid mistake, pls ignore it (I guess I'm not just getting annoyed but also a bit too suspicious) Op woensdag 27 februari 2013 23:53:46 UTC+1 schreef Joachim De Beule het volgende: (At the end of my previous update, I mean namespaces 1, 2 and 3 instead of A, B and C. Sorry for that ...) Op woensdag 27 februari 2013 23:49:42 UTC+1 schreef Joachim De Beule het volgende: Hi Jim, I'm sorry I can't really be more specific. I tried to duplicate the problems with a few simple steps, but they only seem to turn when things get complicates, e.g. involve different namespaces etc. I now even encountered a third problem which I think is related to the other two because it involves caching of protocol functions: - In namespace 1, I define and create a record, say R, that implements a protocol P as defined in namespace 2. - In a third namespace I call a method called classes of protocol P on record R, i.e. I evaluate (classes R). Clojure then complains with IllegalArgumentException No implementation of method: :classes of protocol: #'sentiment.protocols/ClassifierP found for class: sentiment.classification.client$fn__1479 clojure.core/-cache-protocol-fn (core_deftype.clj:527). - when I evaluate (classes R) in namespace 1 (of R), no exception is raised Both namespaces A and C use namespace B. Op woensdag 27 februari 2013 17:19:33 UTC+1 schreef Jim foo.bar het volgende: I'm not sure I fully understand the problem but I'll do my best to guess... 1) are you sure you're using the protocol or are you actually trying to define a method in the interface that the protocol generates? Try fully qualifying the name of you protocol at the extension point... 2)Do your protocols exist in a separate namespace? Are you reloading the namespace after making changes? Could you provide a minimal example of the problem? I've been using protocols quite heavily lately and I do remember some of these issues but I can't pinpoint your exact problem... Jim ps: are you by any chance trying to create 'mixins'? If yes remember that for a protocol to be fully populated , it must be extended fully per individual type (quote from the JOy of Clojure) On 27/02/13 15:48, Joachim De Beule wrote: Hi all, I'm doing interactive development with emacs+clojure-mode+nrepl and I'm experiencing some seriously annoying problems with protocols and records implementing the protocols: 1) When I redefine a protocol by adding a method to it, and then re-implement a record according in accordance to the changed protocol, clojure complains that it cannot implement a method not in the protocol/interface. 2) when I change a protocol method in an existing record (e.g. by simply adding a println statement) the changes do not have any effect. These problems persist even when I do an nrepl-restart or close emacs and restart. Any ideas? Joachim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
AOT and side-effects associated to ns initialization
So I was playing with AOT for the first time. My main reason to use it is
so the consumer Java code doesn't look so alien / run-timey.
The thing is, I encountered that the following line causes `lein compile`
to hang:
(defn -server [] (jetty/run-jetty #'app {:port 8000 :join? false}))
(for those not familiar with Jetty, the expression causes a web server to
launch.)
I can sort of see why this code represents a fault, from a compiler's point
of view. But OTOH, in e.g. Java it's not that much of a rare practice to
bind a the result of a side-effectful op to a variable, right?
My question is quite simply, why can't the given code compile? It is not
entirely clear to me, as I don't thoroughly understand how Clojure's
compiler works (or any compiler at all, for that matter).
--
--
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.
AOT and side-effects associated to ns initialization
So I was playing with AOT for the first time. My main reason to use it is
so the consumer Java code doesn't look so alien / run-timey.
The thing is, I encountered that the following line causes `lein compile`
to hang:
(def server (jetty/run-jetty #'app {:port 8000 :join? false}))
(for those not familiar with Jetty, the expression causes a web server to
launch.)
I can sort of see why this code represents a fault, from a compiler's point
of view. But OTOH, in e.g. Java it's not that much of a rare practice to
bind a the result of a side-effectful op to a variable definition, right?
My question is quite simply, why can't the given code compile? It is not
entirely clear to me, as I don't thoroughly understand how Clojure's
compiler works (or any compiler at all, for that matter).
--
--
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: Clojure Performance For Expensive Algorithms
I beg to differ. You can't separate an assessment of idiomaticity
from the specific problem domain. *That* is true no matter what the
language.
On Feb 27, 9:48 am, Marko Topolnik marko.topol...@gmail.com wrote:
On Wednesday, February 27, 2013 6:28:03 PM UTC+1, Andy Fingerhut wrote:
If you wanted to create a collection of idiomatic Clojure programs for
solving a particular set of problems, e.g. the Benchmarks Game problems, as
soon as more than one person submitted a program and/or reviewed a program,
there could arise arguments over which ones are idiomatic and which are not.
If one person is maintaining the collection, they can make judgement calls
on this, and/or keep multiple different submissions around to solve the
same problem as all equally idiomatic, even though they use different code
constructs to do it.
There is much truth in this; however, I bet that all those programs could
in fact be considered idomatic from a wider perspective. One guy prefers *
(reduce...assoc)* where another prefers *(into {}...map...)* and that's OK.
However, if someone comes along with *(let [m (HashMap.)] (loop []...(recur
(.put m ...)))* claiming that is in fact idomatic, he's just being
unreasonable---by everyone's agreement. Yes, in the final analysis there
will always be a fine dividing line over which everyone involved will love
to disagree, but that's a lesser concern.
-Marko
--
--
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: AOT and side-effects associated to ns initialization
Of course, the expression needs to be evaluated at runtime only :)
Presently, your jetty server gets started just after the expression is compiled.
When you want to defer evaluation at runtime when generating compiled code
ahead of time, you need to wrap expressions like these with this:
(def server (when-not *compile-files* (jetty/...
This will defer evaluation of the expression when the code actually runs,
not after it got compiled.
Remember, expressions are compiled then evaluated immediately.
Be cautious, you can get stuff started this way while building your targets.
It's unlikely that you want this to happen...
Luc P.
So I was playing with AOT for the first time. My main reason to use it is
so the consumer Java code doesn't look so alien / run-timey.
The thing is, I encountered that the following line causes `lein compile`
to hang:
(def server (jetty/run-jetty #'app {:port 8000 :join? false}))
(for those not familiar with Jetty, the expression causes a web server to
launch.)
I can sort of see why this code represents a fault, from a compiler's point
of view. But OTOH, in e.g. Java it's not that much of a rare practice to
bind a the result of a side-effectful op to a variable definition, right?
My question is quite simply, why can't the given code compile? It is not
entirely clear to me, as I don't thoroughly understand how Clojure's
compiler works (or any compiler at all, for that matter).
--
--
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.
--
Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad!
--
--
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: AOT and side-effects associated to ns initialization
Much clearer now :) Never heard of that *compile-files* var. Having to
resort to it looks pretty nasty anyway - I'd rather refactor my code
instead.
Thanks for the answer Luc!
On Thu, Feb 28, 2013 at 2:44 AM, Softaddicts lprefonta...@softaddicts.cawrote:
Of course, the expression needs to be evaluated at runtime only :)
Presently, your jetty server gets started just after the expression is
compiled.
When you want to defer evaluation at runtime when generating compiled code
ahead of time, you need to wrap expressions like these with this:
(def server (when-not *compile-files* (jetty/...
This will defer evaluation of the expression when the code actually runs,
not after it got compiled.
Remember, expressions are compiled then evaluated immediately.
Be cautious, you can get stuff started this way while building your
targets.
It's unlikely that you want this to happen...
Luc P.
So I was playing with AOT for the first time. My main reason to use it is
so the consumer Java code doesn't look so alien / run-timey.
The thing is, I encountered that the following line causes `lein compile`
to hang:
(def server (jetty/run-jetty #'app {:port 8000 :join? false}))
(for those not familiar with Jetty, the expression causes a web server to
launch.)
I can sort of see why this code represents a fault, from a compiler's
point
of view. But OTOH, in e.g. Java it's not that much of a rare practice to
bind a the result of a side-effectful op to a variable definition, right?
My question is quite simply, why can't the given code compile? It is not
entirely clear to me, as I don't thoroughly understand how Clojure's
compiler works (or any compiler at all, for that matter).
--
--
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.
--
Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad!
--
--
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: (def newsletter)
Pretty cool. Have you subscribed and recieved any newsletter yet? If so, what do you think of the content? Thanks! J On Wednesday, February 27, 2013 2:49:01 PM UTC-3, Rich Morin wrote: I just ran across this and don't see anything about it in my list archives, so... (def newsletter) A weekly Clojure newsletter http://defnewsletter.com Seems like a useful way to keep up with announcements, etc. -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com javascript: http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation -- -- 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: (def newsletter)
You can click to see the archives: http://us2.campaign-archive2.com/home/?u=62fb70be840779d7af85e9b6eid=4951b7aa7c On Wed, Feb 27, 2013 at 6:26 PM, juan.facorro juan.faco...@gmail.com wrote: Pretty cool. Have you subscribed and recieved any newsletter yet? If so, what do you think of the content? Thanks! J On Wednesday, February 27, 2013 2:49:01 PM UTC-3, Rich Morin wrote: I just ran across this and don't see anything about it in my list archives, so... (def newsletter) A weekly Clojure newsletter http://defnewsletter.com Seems like a useful way to keep up with announcements, etc. -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation -- -- 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. -- 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 --- 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: (def newsletter)
I subscribed and completely missed the Check out the archives link. Thanks! On Wednesday, February 27, 2013 11:54:57 PM UTC-3, Sean Corfield wrote: You can click to see the archives: http://us2.campaign-archive2.com/home/?u=62fb70be840779d7af85e9b6eid=4951b7aa7c On Wed, Feb 27, 2013 at 6:26 PM, juan.facorro juan.f...@gmail.comjavascript: wrote: Pretty cool. Have you subscribed and recieved any newsletter yet? If so, what do you think of the content? Thanks! J On Wednesday, February 27, 2013 2:49:01 PM UTC-3, Rich Morin wrote: I just ran across this and don't see anything about it in my list archives, so... (def newsletter) A weekly Clojure newsletter http://defnewsletter.com Seems like a useful way to keep up with announcements, etc. -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- 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 --- 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: AOT and side-effects associated to ns initialization
It's not nasty :) It's about cultural differences :)
In the 70s/80s, dynamic languages were much more present than in the past 20
years.
People understood the difference between interpretation vs code packaging
for production use.
Suspending evaluation at packaging time of some expressions is ok,
especially if you have side effects like connecting to an application database.
Who would want to that at build time ?
It's a (little) price to pay to get the best of both worlds, a REPL with
dynamic evaluation,
the ability to get your code verified before run time by the compiler and
allowing you to deliver runnable code without source code with a faster
startup time.
Not including the ability to patch a living process ... yeah !
I work with near like embedded systems in Clojure. We deliver AOT all the way
in production.
AOT has a bad reputation for reasons that leave me expressionless.
I understand the dev. reasons for avoiding it but when it's time to package for
production
it has a definite value.
Luc P.
Much clearer now :) Never heard of that *compile-files* var. Having to
resort to it looks pretty nasty anyway - I'd rather refactor my code
instead.
Thanks for the answer Luc!
On Thu, Feb 28, 2013 at 2:44 AM, Softaddicts
lprefonta...@softaddicts.cawrote:
Of course, the expression needs to be evaluated at runtime only :)
Presently, your jetty server gets started just after the expression is
compiled.
When you want to defer evaluation at runtime when generating compiled code
ahead of time, you need to wrap expressions like these with this:
(def server (when-not *compile-files* (jetty/...
This will defer evaluation of the expression when the code actually runs,
not after it got compiled.
Remember, expressions are compiled then evaluated immediately.
Be cautious, you can get stuff started this way while building your
targets.
It's unlikely that you want this to happen...
Luc P.
So I was playing with AOT for the first time. My main reason to use it is
so the consumer Java code doesn't look so alien / run-timey.
The thing is, I encountered that the following line causes `lein compile`
to hang:
(def server (jetty/run-jetty #'app {:port 8000 :join? false}))
(for those not familiar with Jetty, the expression causes a web server to
launch.)
I can sort of see why this code represents a fault, from a compiler's
point
of view. But OTOH, in e.g. Java it's not that much of a rare practice to
bind a the result of a side-effectful op to a variable definition, right?
My question is quite simply, why can't the given code compile? It is not
entirely clear to me, as I don't thoroughly understand how Clojure's
compiler works (or any compiler at all, for that matter).
--
--
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.
--
Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad!
--
--
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
Re: defmacro/gen-class/annotation woes
Hi,
just a wild guess: quote the annotation in the macro. (with-meta name
`{Deprecated true}). Note the backtick.
Kind regards
Meikel
--
--
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: AOT and side-effects associated to ns initialization
Hi,
Another option:
(ns you.ns // add :aot [you.ns] to project.clj
(:gen-class))
(def server (atom nil))
(defn -main [ args]; command line args
(reset! server (jetty/run-jetty #'app {:port 8000 :join? false})))
;;; run it and pass command line arguments
java -cp your-aot-compiled.jar you.ns --port 9090
On Thursday, February 28, 2013 8:47:36 AM UTC+8, vemv wrote:
So I was playing with AOT for the first time. My main reason to use it is
so the consumer Java code doesn't look so alien / run-timey.
The thing is, I encountered that the following line causes `lein compile`
to hang:
(def server (jetty/run-jetty #'app {:port 8000 :join? false}))
(for those not familiar with Jetty, the expression causes a web server to
launch.)
I can sort of see why this code represents a fault, from a compiler's
point of view. But OTOH, in e.g. Java it's not that much of a rare practice
to bind a the result of a side-effectful op to a variable definition, right?
My question is quite simply, why can't the given code compile? It is not
entirely clear to me, as I don't thoroughly understand how Clojure's
compiler works (or any compiler at all, for that matter).
--
--
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: defmacro/gen-class/annotation woes
Meikel,
Good guess - your idea works! I'm impressed.
What made you think of that? How did you know to syntax-quote the metadata
map?
I'm curious how you solved it.
Paul
On Wednesday, February 27, 2013 11:52:05 PM UTC-7, Meikel Brandmeyer
(kotarak) wrote:
Hi,
just a wild guess: quote the annotation in the macro. (with-meta name
`{Deprecated true}). Note the backtick.
Kind regards
Meikel
--
--
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: defmacro/gen-class/annotation woes
Hi, if you want to avoid reflection in macro-generated code you have to quote the class because the compiler expects the classname and not the class itself. I figured it could be similar here. Kind regards Meikel -- -- 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.
