Re: Results from 2011 State of Clojure survey
On Tuesday, July 12, 2011 6:18:12 PM UTC-7, Chas Emerick wrote: I hesitate to go even more meta, but since I started the thread, I thought I would say: I talked for a bit in the results post about mailing list threads going into the weeds; at least IMO, this one qualifies. It wouldn't be the worst thing in the world if it died right here. :-) Cheers, - Chas Too late. Your thread has been YAKT (Yet Another Ken Thread). -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Change in reduce behavior in 1.3.0?
Hi, I think the culprit is here: https://github.com/clojure/clojure/blob/5f9d6a02c530a02251197e1b844af37440a6b569/src/clj/clojure/core/protocols.clj#L64 The line (recur cls (next s) f (f val (first s))) must be written as (let [v (f val (first s))] (recur cls (next s) f v)) for your scenario to work. Sincerely 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
Re: Immutable Piece-table
On Wed, Jul 13, 2011 at 02:33, Ghadi Shayban gshay...@gmail.com wrote: I put up a simple demo that implements a piece table data structure in Clojure (This is totally an excuse to use finger trees, which Chris Houser implemented and excellently presented at the first conj) A piece table is good for buffer management in a text editor, as it gets around making changes in place. All changes are made to a separate append-only buffer. I'll spare you the details but if you look at the code you'll see why a finger tree is a good base structure... Each piece in the table has a different weight (the length of the piece), and you need to find a point without traversing the whole sequence. https://github.com/ghadishayban/piece-table/blob/master/src/piecetable/core.clj That's a nice use of finger trees. I'll take it along this morning to read on the subway. More about piece-tables http://www.cs.unm.edu/~crowley/papers/sds.pdf Ah, the memories! :-) Wirth and Gutknecht's Oberon System used this technique (under the name 'piece chain') for the built-in text editing facility. In their case the pieces also carried attribute (font, size, style, color) information for the run of text being described. The raw text backing the chain remained on disk. Newly entered text was appended to a separate on disk file. So, on disk text files had the property of being immutable or append only while you were editing. Saving the current document replaced the old version atomically in the disk directory. This always struck me as a tiny bit FP, though one would never confuse Oberon with FP or a lisp. The implementation is described here: http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf (~ 5MB!) Starting at page 83. There are figures on pp 84-86. // 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
Re: monads macros
On 12 Jul 2011, at 23:18, Alan Malloy wrote: On Jul 12, 12:01 pm, Konrad Hinsen konrad.hin...@fastmail.net wrote: The composability issue with macros lies in writing them, not using them. Strongly disagree. Macros compose reasonably well when writing them (eg, using let in the implementation of with-open is trivial); it's That's not composition, that's use. What I mean by composition is writing a complex macro in terms of simpler macros and macro composers, just as one writes complex functions in terms of simple functions and higher-order functions. There is no equivalent of higher- order functions in the macro universe, for example. composing already-written macros with other pieces of your codebase that's hard. (reduce and xs) won't test that every element of xs is truthy, because and is a macro and thus can't be used as a higher- order function. That's exactly the kind of problem I was thinking of. So in fact we agree, except for the label to put on the problem. Konrad. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Change in reduce behavior in 1.3.0?
On Wed, Jul 13, 2011 at 08:43, Meikel Brandmeyer m...@kotka.de wrote: Hi, I think the culprit is here: https://github.com/clojure/clojure/blob/5f9d6a02c530a02251197e1b844af37440a6b569/src/clj/clojure/core/protocols.clj#L64 The line (recur cls (next s) f (f val (first s))) must be written as (let [v (f val (first s))] (recur cls (next s) f v)) for your scenario to work. I'm probably being a little dense this morning, but... I've stared at both examples for some time now and still don't see why the first should behave differently than the second. Can you give me a hint? // 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
Re: Change in reduce behavior in 1.3.0?
Hi, Am Mittwoch, 13. Juli 2011 11:02:40 UTC+2 schrieb bsmith.occs: On Wed, Jul 13, 2011 at 08:43, Meikel Brandmeyer m...@kotka.de wrote: Hi, I think the culprit is here: https://github.com/clojure/clojure/blob/5f9d6a02c530a02251197e1b844af37440a6b569/src/clj/clojure/core/protocols.clj#L64 The line (recur cls (next s) f (f val (first s))) must be written as (let [v (f val (first s))] (recur cls (next s) f v)) for your scenario to work. I'm probably being a little dense this morning, but... I've stared at both examples for some time now and still don't see why the first should behave differently than the second. Can you give me a hint? Because - although not guaranteed - clojure evaluates function arguments from the left to the right. So the next element in the sequence is realised before the function f is called. In the second snippet f will be called always before the next element is realised. If f is pure, there won't be a difference. If f is not pure, it will be a difference. Especially if next relies on side-effects of f (or vice versa) as in the scenario described by the OP. Sincerely 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
Re: Results from 2011 State of Clojure survey
Chas, It seems that relatively few people are taking advantage of some of Clojure’s most sophisticated and unique features: metadata; protocols, records, and types; and multimethods. These facilities are absolutely game-changers, at least IMO. Either most domains have no use for them (I can’t believe that), or most people don’t know how to use them effectively, thus they are left unused. Those of us that write about and teach Clojure, take note. What prevents me from using it is that clojure 1.3.* is still alpha or early beta, and it's been for a long time. If clojure 1.3 was released and development continued into 1.4, I predict that protocols and records would suddenly start being used a lot more. Albert -- http://albert.rierol.net http://www.ini.uzh.ch/~acardona/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Results from 2011 State of Clojure survey
I've found that (some of) Clojure's advanced features are best taught in terms of simpler ideas that most programmers would be familiar with. For example, excuse the plug, I motivated multimethods by relating them to simple conditionals like case. I think I succeeded in making MMs just look like a fancier conditional, which is much more friendly than an arbitrary dispatch mechanism ;) http://pragprog.com/magazines/2011-07/growing-a-dsl-with-clojure I'm brainstorming how we could approach teaching the other features you mentioned similarly. Thanks, Ambrose On Wed, Jul 13, 2011 at 6:52 PM, Albert Cardona sapri...@gmail.com wrote: Chas, It seems that relatively few people are taking advantage of some of Clojure’s most sophisticated and unique features: metadata; protocols, records, and types; and multimethods. These facilities are absolutely game-changers, at least IMO. Either most domains have no use for them (I can’t believe that), or most people don’t know how to use them effectively, thus they are left unused. Those of us that write about and teach Clojure, take note. What prevents me from using it is that clojure 1.3.* is still alpha or early beta, and it's been for a long time. If clojure 1.3 was released and development continued into 1.4, I predict that protocols and records would suddenly start being used a lot more. Albert -- http://albert.rierol.net http://www.ini.uzh.ch/~acardona/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your 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 post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads macros
On 13 Jul 2011, at 05:04, Ken Wesson wrote: One approach that has been proposed to improve composability of macros is to adopt a continuation-passing style. This would make macros a candidate for the continuation monad, so perhaps monads may be of use in implementing complex macros. That popcorn-popping sound you hear is heads exploding out there in the audience. Maybe this article will help understand what I was referring to - noting that this is for Scheme and not Clojure: http://okmij.org/ftp/papers/CPS-Macros.ps.gz Konrad. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Results from 2011 State of Clojure survey
All those are available in 1.2, or am I missing something? From my own experience: metadata, when I started to learn clojure, I thought this is awesome. When I realized that metadata only applies to clojure types, it felt unreliable and I never got to using it. protocols records/types - they're straightforward, I use them. multimethods - since close to every mention of multimethods also involves telling how slow they are, these are most often shunned. Jonathan On Wed, Jul 13, 2011 at 12:52 PM, Albert Cardona sapri...@gmail.com wrote: Chas, It seems that relatively few people are taking advantage of some of Clojure’s most sophisticated and unique features: metadata; protocols, records, and types; and multimethods. These facilities are absolutely game-changers, at least IMO. Either most domains have no use for them (I can’t believe that), or most people don’t know how to use them effectively, thus they are left unused. Those of us that write about and teach Clojure, take note. What prevents me from using it is that clojure 1.3.* is still alpha or early beta, and it's been for a long time. If clojure 1.3 was released and development continued into 1.4, I predict that protocols and records would suddenly start being used a lot more. Albert -- http://albert.rierol.net http://www.ini.uzh.ch/~acardona/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your 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 post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Results from 2011 State of Clojure survey
Hi, On Wed, Jul 13, 2011 at 7:57 PM, Jonathan Fischer Friberg odysso...@gmail.com wrote: multimethods - since close to every mention of multimethods also involves telling how slow they are, these are most often shunned. I don't get that impression. MM's seem to be pushed as a first choice for implementing prototypes over protocols, much like maps are often recommended over records. At least on this mailing list, maybe more generally you hear recounting their experience of converting MM to protocols as an optimization. Thanks, Ambrose -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads macros
On Wed, Jul 13, 2011 at 7:19 AM, Konrad Hinsen konrad.hin...@fastmail.net wrote: On 13 Jul 2011, at 05:04, Ken Wesson wrote: One approach that has been proposed to improve composability of macros is to adopt a continuation-passing style. This would make macros a candidate for the continuation monad, so perhaps monads may be of use in implementing complex macros. That popcorn-popping sound you hear is heads exploding out there in the audience. Maybe this article will help understand what I was referring to - noting that this is for Scheme and not Clojure: http://okmij.org/ftp/papers/CPS-Macros.ps.gz Oh, I'm not saying my own is exploding -- just that macros can be tough for some people to get their heads around, and monads even more so, so combining the two ... -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Results from 2011 State of Clojure survey
I think for me at least leveraging the polymorphism that the seq abstraction provides gets you such a long way compared to collection libs in other languages that you don't have to reach for the other features as quickly. I think Rich even stated that as one of the reasons for delaying their introduction in the first place, he wanted people to become comfortable making full use of seqs. Cheers, James S On Jul 13, 9:03 pm, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: I've found that (some of) Clojure's advanced features are best taught in terms of simpler ideas that most programmers would be familiar with. For example, excuse the plug, I motivated multimethods by relating them to simple conditionals like case. I think I succeeded in making MMs just look like a fancier conditional, which is much more friendly than an arbitrary dispatch mechanism ;) http://pragprog.com/magazines/2011-07/growing-a-dsl-with-clojure I'm brainstorming how we could approach teaching the other features you mentioned similarly. Thanks, Ambrose On Wed, Jul 13, 2011 at 6:52 PM, Albert Cardona sapri...@gmail.com wrote: Chas, It seems that relatively few people are taking advantage of some of Clojure’s most sophisticated and unique features: metadata; protocols, records, and types; and multimethods. These facilities are absolutely game-changers, at least IMO. Either most domains have no use for them (I can’t believe that), or most people don’t know how to use them effectively, thus they are left unused. Those of us that write about and teach Clojure, take note. What prevents me from using it is that clojure 1.3.* is still alpha or early beta, and it's been for a long time. If clojure 1.3 was released and development continued into 1.4, I predict that protocols and records would suddenly start being used a lot more. Albert -- http://albert.rierol.net http://www.ini.uzh.ch/~acardona/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your 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 post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Question on eliminating recur
On Jul 13, 1:16 am, Christian Marks 9fv...@gmail.com wrote: Thank you. Based on this I've simplified the code further. You could combine the test for a cycle leader with the cycle length count--but your original code, which calculates cycle lengths only if a cycle leader is identified, is more efficient! (ns knuth (:require [clojure.contrib.math :as math])) (defn random-perm [n] (shuffle (range n))) (defn cycle-leader-length [perm i] (loop [cycle 1 j (nth perm i)] (cond ( j i) 1 (= j i) cycle :else (recur (inc cycle) (nth perm j) (defn order-perm [perm] (reduce (fn [order i] (math/lcm (cycle- leader-length perm i) order)) 1 perm)) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Change in reduce behavior in 1.3.0?
Oh I see it now, the call is inverted in 1.2.1 core.clj. Thanks, it was driving me crazy. Regarding Meikel comment on clojure-dev I will open a ticket to either apply the shown fix, or modify the contract of reduce to require pureness of f. I think that changing reduce contract, such a basic building block, may be a little harsh. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Change in reduce behavior in 1.3.0?
2011/7/13 Sebastián Galkin paras...@gmail.com Oh I see it now, the call is inverted in 1.2.1 core.clj. Thanks, it was driving me crazy. Regarding Meikel comment on clojure-dev I will open a ticket to either apply the shown fix, or modify the contract of reduce to require pureness of f. I think that changing reduce contract, such a basic building block, may be a little harsh. Making assumptions between the order of realization of seq elements and calls to the reducing functions seems crazy to me, really. I don't even see why a ticket should be opened, or the contract of reduce should be changed. My 0.02€, -- Laurent -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Change in reduce behavior in 1.3.0?
Making assumptions between the order of realization of seq elements and calls to the reducing functions seems crazy to me, really. May be, but it's not as much about the order as about the laziness. New reduce is less lazy than previous, and maybe unnecessarily so. If you think of a collection, you don't care, since is going to be completely reduced anyway, but if your seq is a lazy-seq, you want as much laziness as you can have. My 1E-3M$ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Change in reduce behavior in 1.3.0?
Hi, Am Mittwoch, 13. Juli 2011 16:15:28 UTC+2 schrieb Sebastián Galkin: Making assumptions between the order of realization of seq elements and calls to the reducing functions seems crazy to me, really. May be, but it's not as much about the order as about the laziness. New reduce is less lazy than previous, and maybe unnecessarily so. If you think of a collection, you don't care, since is going to be completely reduced anyway, but if your seq is a lazy-seq, you want as much laziness as you can have. reduce is always eager and will consume the total sequence. At what point in time it realises the elements is mood in the end, unless two elements of your seq won't fit in memory at the same time (or you got side-effects...). So, I still think reduce shouldn't do that, although hitting a case triggering this issue is rather unlikely in practise. But why rely on unlikeliness when one can easily fix this? Sincerely 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
Re: Change in reduce behavior in 1.3.0?
At what point in time it realises the elements is mood in the end Yes. Probably the whole point of (finite) lazy seqs is some sort of side effect. Be it memory consumption, processing time, or other forms of side-effect. But, shouldn't map, filter, reduce and others, with its lazy-friendly behavior help us deal with the side effects in a predictable manner? Maybe reduce doesn't belong to that group, and that's why you proposed a change in contract. But why rely on unlikeliness when one can easily fix this? Yes, I already changed it to not depend on reduce realization order. 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
Repeating a vector n times
I have to write a function that will take a vector as input, repeat the elements multiple times and return back a single vector of the repeated items. I came up with the following but am wondering if there is a better or simpler way to write this: (def xs [a b c]) (defn repeat-vec-n [xs n] (vec (reduce concat [] (take n (repeat xs) OUTPUT: user= xs [a b c] user= (repeat-vec-n xs 3) [a b c a b c a b c] -- Shoeb -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your 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
Aw: Repeating a vector n times
Hi, you could use (reduce into [] (repeat n xs)). Sincerely 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
Re: Repeating a vector n times
Damn, Meikel's solution is better, I was thinking: (apply concat (repeat n xs)) On Wed, Jul 13, 2011 at 10:54 AM, Bhinderwala, Shoeb sabhinderw...@wellington.com wrote: ** I have to write a function that will take a vector as input, repeat the elements multiple times and return back a single vector of the repeated items. I came up with the following but am wondering if there is a better or simpler way to write this: (def xs [a b c]) (defn repeat-vec-n [xs n] (vec (reduce concat [] (take n (repeat xs) OUTPUT: user= xs [a b c] user= (repeat-vec-n xs 3) [a b c a b c a b c] ***-- Shoeb* -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your 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 post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
RE: Repeating a vector n times
Thanks Tamreen. Your solution will have to be wrapped in another vec call. I will use Miekel's: (reduce into [] (repeat n xs)). From: clojure@googlegroups.com [mailto:clojure@googlegroups.com] On Behalf Of Tamreen Khan Sent: Wednesday, July 13, 2011 11:02 AM To: clojure@googlegroups.com Subject: Re: Repeating a vector n times Damn, Meikel's solution is better, I was thinking: (apply concat (repeat n xs)) On Wed, Jul 13, 2011 at 10:54 AM, Bhinderwala, Shoeb sabhinderw...@wellington.com wrote: I have to write a function that will take a vector as input, repeat the elements multiple times and return back a single vector of the repeated items. I came up with the following but am wondering if there is a better or simpler way to write this: (def xs [a b c]) (defn repeat-vec-n [xs n] (vec (reduce concat [] (take n (repeat xs) OUTPUT: user= xs [a b c] user= (repeat-vec-n xs 3) [a b c a b c a b c] -- Shoeb -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com mailto:clojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your 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 post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Reworking :pre condition to add an error message
I do think a simple String error message is all that the user of the function should provide. From there, An AssertionError can throw up something along the lines of what you said - Expected… , Found… , Message. That would give enough information for reporting at least in a test framework. To get more precise information, like you said, that AssertionError could also throw up class/file information, etc. that a debugger could use. I would guard against designing these things to accomodate a context outside of it's execution scope. In the ideal functional world, the input and output are wholly localized. Any Error/Exception thrown can be consumed or chained to give very precise failure reasoning. As for how that would fit into the entire exception chain, that's still being thought (see herehttp://dev.clojure.org/display/design/Error+Handling). There are already a few approaches, and I think this (see herehttp://dev.clojure.org/display/design/Error+Handling+Comparisons) is the context of how the core team is approaching this problem. Cheers Tim On Tue, Jul 12, 2011 at 6:01 AM, Shantanu Kumar kumar.shant...@gmail.comwrote: As I am the culprit of having introduced it with a naive example, I'd better admit it may not be very useful in practical scenarios across a wide variety of use cases. For example, when there is an assertion error with message `m` should be a map 14 levels down the stack, I'd really wish it said `m` -- Expected: map, Found: vector [:foo :bar] so that I can debug it quickly. Pre-conditions and Post-conditions are a valuable debugging aid, and to enable that we need very precise information. Unfortunately passing a string error message cannot encapsulate enough error context. A more complex example can be where the correctness of input must be determined collectively (in association with other args) -- in those cases one can only fall back on comparing input values and raise IllegalArgumentException accordingly. Regards, Shantanu On Jul 11, 10:40 pm, Timothy Washington twash...@gmail.com wrote: -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads macros
On Wed, Jul 13, 2011 at 5:20 AM, Ken Wesson kwess...@gmail.com wrote: Oh, I'm not saying my own is exploding -- just that macros can be tough for some people to get their heads around, and monads even more so, so combining the two ... maybe call them something else and it won't be so bad. when people see the need for something, they are generally willing to pursue it and learn it, i think. the people using clojure are probably somewhat self-selectingly smart enough ;-) as long as you don't call them monads ha ha. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Results from 2011 State of Clojure survey
Indeed, all of these features were introduced in 1.2.0. Metadata has been around since (roughly) the beginning. It's true that metadata being available only for Clojure types (those that implement clojure.lang.IObj) is unfortunate — but I wouldn't say that that's reason to consider the mechanism unreliable. Multimethods shouldn't be shunned, insofar as they can succinctly solve modeling problems that no other mechanism can. When you need to haul a big load, avoiding the big rig because it's not as fast as the race car doesn't make much sense. :-) - Chas On Jul 13, 2011, at 7:57 AM, Jonathan Fischer Friberg wrote: All those are available in 1.2, or am I missing something? From my own experience: metadata, when I started to learn clojure, I thought this is awesome. When I realized that metadata only applies to clojure types, it felt unreliable and I never got to using it. protocols records/types - they're straightforward, I use them. multimethods - since close to every mention of multimethods also involves telling how slow they are, these are most often shunned. Jonathan On Wed, Jul 13, 2011 at 12:52 PM, Albert Cardona sapri...@gmail.com wrote: Chas, It seems that relatively few people are taking advantage of some of Clojure’s most sophisticated and unique features: metadata; protocols, records, and types; and multimethods. These facilities are absolutely game-changers, at least IMO. Either most domains have no use for them (I can’t believe that), or most people don’t know how to use them effectively, thus they are left unused. Those of us that write about and teach Clojure, take note. What prevents me from using it is that clojure 1.3.* is still alpha or early beta, and it's been for a long time. If clojure 1.3 was released and development continued into 1.4, I predict that protocols and records would suddenly start being used a lot more. Albert -- http://albert.rierol.net http://www.ini.uzh.ch/~acardona/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your 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 post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your 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 post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Results from 2011 State of Clojure survey
Albert Cardona sapri...@gmail.com writes: It seems that relatively few people are taking advantage of some of Clojure’s most sophisticated and unique features: metadata; protocols, records, and types; and multimethods. These facilities are absolutely game-changers, at least IMO. Either most domains have no use for them (I can’t believe that), or most people don’t know how to use them effectively, thus they are left unused. Those of us that write about and teach Clojure, take note. Or it could just be that some of the other things on that list were so compelling that they overshadowed these. * The REPL * Functional Programming * Ease of development These are the bread-and-butter of programming, so much that I'd have a hard time ever working in (or even taking seriously) a language that didn't support them. I'm a fan of using multimethods to achieve polymorphism, but polymorphism is only needed in a small subset of the code I write, while the features above affect *everything*. -Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads macros
On Wed, Jul 13, 2011 at 1:37 PM, Raoul Duke rao...@gmail.com wrote: On Wed, Jul 13, 2011 at 5:20 AM, Ken Wesson kwess...@gmail.com wrote: Oh, I'm not saying my own is exploding -- just that macros can be tough for some people to get their heads around, and monads even more so, so combining the two ... maybe call them something else and it won't be so bad. when people see the need for something, they are generally willing to pursue it and learn it, i think. the people using clojure are probably somewhat self-selectingly smart enough ;-) as long as you don't call them monads ha ha. I'd probably be more insulted by being called macro. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Results from 2011 State of Clojure survey
On Wed, Jul 13, 2011 at 2:41 PM, Phil Hagelberg p...@hagelb.org wrote: Albert Cardona sapri...@gmail.com writes: It seems that relatively few people are taking advantage of some of Clojure’s most sophisticated and unique features: metadata; protocols, records, and types; and multimethods. These facilities are absolutely game-changers, at least IMO. Either most domains have no use for them (I can’t believe that), or most people don’t know how to use them effectively, thus they are left unused. Those of us that write about and teach Clojure, take note. Or it could just be that some of the other things on that list were so compelling that they overshadowed these. * The REPL * Functional Programming * Ease of development Good point. Though the items on that question were not mutually exclusive (you could tick more than one), it's likely some people ticked the one they thought most compelling and that others ticked three or four, but only the ones they considered to be bread and butter rather than the icing on the cake. These are the bread-and-butter of programming, so much that I'd have a hard time ever working in (or even taking seriously) a language that didn't support them. What about ones that seem to go out of their way not to? Java comes to mind. VB adds in from Microsoft and no free software implementation for added fun. :) Languages that do have those three items you considered crucial: Lisps, of course, and I think Python and maybe even Ruby. Smalltalk may be a bit of an oddball case: with its BlockContext closures it has roughly half of FP available (there are limits on creating and returning and then reusing them, or using them in multiple threads) and its Transcript objects are something of a REPL (it's even possible to create new classes and methods at it by typing the right incantations, something like BaseClass subclass: NewName ...) and interactive development and debugging there can make development somewhat easier than in, say, Java. Particularly, it's rapid prototyping and quickie testing that the REPL helps, and modularization and making small, composable, easily testable bits and clever HOF-based abstractions that FP helps, that contributes to the third item on your list. I'm a fan of using multimethods to achieve polymorphism, but polymorphism is only needed in a small subset of the code I write, while the features above affect *everything*. Hence icing vs. bread-and-butter. Or put another way you may appreciate the socket wrench in the toolbox even if the jobs you do mean you mostly use the hammer, the needle-nose pliers, the screwdrivers, and the rotary tool and reach for the wrench only occasionally. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Repeating a vector n times
On Wed, Jul 13, 2011 at 11:21 AM, Bhinderwala, Shoeb sabhinderw...@wellington.com wrote: Thanks Tamreen. Your solution will have to be wrapped in another vec call. I will use Miekel’s: (reduce into [] (repeat n xs)). What about (vec (take n (cycle xs)))? -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Repeating a vector n times
Ken, that'll result in the original vector back out again. (vec (take 3 (cycle [1 2 3]))) = [1 2 3]. I think you mean: (vec (take (* n (count xs)) (cycle xs On Wed, Jul 13, 2011 at 5:13 PM, Ken Wesson kwess...@gmail.com wrote: On Wed, Jul 13, 2011 at 11:21 AM, Bhinderwala, Shoeb sabhinderw...@wellington.com wrote: Thanks Tamreen. Your solution will have to be wrapped in another vec call. I will use Miekel’s: (reduce into [] (repeat n xs)). What about (vec (take n (cycle xs)))? -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your 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 post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Repeating a vector n times
On Wed, Jul 13, 2011 at 5:17 PM, Sam Ritchie sritchi...@gmail.com wrote: Ken, that'll result in the original vector back out again. (vec (take 3 (cycle [1 2 3]))) = [1 2 3]. I think you mean: (vec (take (* n (count xs)) (cycle xs I wasn't using n to mean the number of repetitions of the xs but the total number of desired elements. One advantage of this method is if you want the first 20 elements from repeating a vector of seven items it won't set your hair on fire. :) -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to add jar files to leiningen projects?
Am glad it worked for you. I have updated the plugin to version 0.2 with list functionality. Will appreciate any feedback/suggestion. https://github.com/kumarshantanu/lein-localrepo Regards, Shantanu On Jul 12, 6:40 pm, Mark Rathwell mark.rathw...@gmail.com wrote: Works great, Shantanu. Thanks! On Tue, Jul 12, 2011 at 3:12 AM, Shantanu Kumar kumar.shant...@gmail.comwrote: It would be ideal if it could be run outside of the project structure, as would be the case if an additional arity was added to the install function in leiningen.install. Thanks for the report -- I have pushed version 0.1.1 so it should now be possible to install it as a plugin and run from any directory. Regards, Shantanu -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your 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 post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Using Clojure To Debug Java Apps
This is great !!!
But you should posting it in a blog and compare it with other
solutions.
On Jul 12, 2:31 am, Asim Jalis asimja...@gmail.com wrote:
I have been using the Clojure REPL to debug a large Java server app.
It's great for exploratory testing and for validating assumptions
about how the system works. I wanted to post the code here in case
someone else finds this useful.
1. Stick this in a class that is loaded early in the server/app.
public static class Repl {
public static final String PORT = 18081;
public static final String NS = user;
private final String initResult; public String getInitResult() {
return initResult; }
public Object invoke(String fn) { try { return
clojure.lang.RT.var(NS, fn).invoke(); } catch (Exception e) { return
null; } }
public Object invoke(String fn, Object arg1) { try { return
clojure.lang.RT.var(NS, fn).invoke(arg1); } catch (Exception e) {
return null; } }
public Object invoke(String fn, Object arg1, Object arg2) { try {
return clojure.lang.RT.var(NS, fn).invoke(arg1, arg2); } catch
(Exception e) { return null; } }
public Object invoke(String fn, Object arg1, Object arg2, Object
arg3) { try { return clojure.lang.RT.var(NS, fn).invoke(arg1, arg2,
arg3); } catch (Exception e) { return null; } }
public Repl() {
String result;
try {
clojure.lang.Var eval = clojure.lang.RT.var(clojure.core,
eval);
clojure.lang.Var read =
clojure.lang.RT.var(clojure.core, read-string);
String create_repl_server =
(do +
(use '[clojure.contrib.server-socket :only
[create-repl-server]]) +
(create-repl-server + PORT + ) + );
result = eval.invoke(read.invoke(create_repl_server)).toString();
} catch (Exception e) {
result = e.toString();
}
initResult = result;
}}
public static final Repl REPL = new Repl();
2. Use this on the command line to start the REPL:
rlwrap --logfile $HOME/tmp/clj.log telnet localhost 18081
Now from the REPL you can create Java objects and call methods at will.
3. To call a Clojure function called some-function in user namespace
from Java, use something like this:
REPL.invoke(some-function, arg1));
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Using Clojure To Debug Java Apps
I wrote a tool called liverepl a while ago: https://github.com/djpowell/liverepl It effectively lets you get a repl into a Java or Clojure process, but it has the nice feature that it works with any Java processes without requiring any modifications to the code. It uses the Java Attach API, which jvisualvm and jconsole use to inject the repl server into the process, and then it connects the console to that server. It has some special support for Tomcat servers too, so that you can repl into a specific webapp. -- Dave -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Build tool for mixed Clojure/Java projects
On Tue, 12 Jul 2011 22:21:39 -0400 Ken Wesson kwess...@gmail.com wrote: Which means it's not really case 4 at all. Well, it's very clearly not cases 1, 2 or 3. No, it's case zero: standard multi-developer, multi-computer, single canonical master copy on one computer/cluster somewhere. The thing cases 1 through 4 were *alternatives* to. Technically true, but meaningless. The master gets tens of zillions of submissions Completely and totally wrong. Linus developed the model used by the Linux kernel specifically to avoid having some master copy on a central server with tens of zillions of submissions. He wrote a SCM that allowed the distributed, ad-hoc model to work without such a central server. All because his experience with the kernel up to that point was that he had reached the scalability limits of your case zero model. And now you're claiming it's a central server model in order to justify your erroneous assumption that having a repository implies having a server? I'm not sure whether that's more funny or pathetic. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Results from 2011 State of Clojure survey
On Jul 13, 2011, at 6:03 AM, Ambrose Bonnaire-Sergeant wrote: I've found that (some of) Clojure's advanced features are best taught in terms of simpler ideas that most programmers would be familiar with. +1 - Brian Marick, Artisanal Labrador Contract programming in Ruby and Clojure Occasional consulting on Agile www.exampler.com, www.twitter.com/marick -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Results from 2011 State of Clojure survey
We use 1.2 in prod with protocols... no need to wait for 1.3 Luc P. On Wed, 13 Jul 2011 06:52:01 -0400 Albert Cardona sapri...@gmail.com wrote: Chas, It seems that relatively few people are taking advantage of some of Clojure’s most sophisticated and unique features: metadata; protocols, records, and types; and multimethods. These facilities are absolutely game-changers, at least IMO. Either most domains have no use for them (I can’t believe that), or most people don’t know how to use them effectively, thus they are left unused. Those of us that write about and teach Clojure, take note. What prevents me from using it is that clojure 1.3.* is still alpha or early beta, and it's been for a long time. If clojure 1.3 was released and development continued into 1.4, I predict that protocols and records would suddenly start being used a lot more. Albert -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Results from 2011 State of Clojure survey
On Wed, Jul 13, 2011 at 3:52 AM, Albert Cardona sapri...@gmail.com wrote: What prevents me from using it is that clojure 1.3.* is still alpha or early beta, and it's been for a long time. Well, those features are all in Clojure 1.2.0 so nothing is preventing you using them. That said, so far I haven't had much need for those features, although we just added our first code using multimethods in the last week or so (very slick solution to an event sourced email delivery analysis problem - we dispatch on a dynamic combination of event and current state so multimethods were the obvious, simplest and, in this case, probably fastest solution!). We're already using Clojure 1.3.0 in production at World Singles (in fact our build today updated us to Beta 1 - we previously went live with Alpha 7 and then used Alpha 8 in dev/QA for a while but were on Beta 1 by the time we scheduled our next production build). We also just added a cron job that uses lein run to execute a new scheduled process - I was pleased at how straightforward that was, although of course it downloaded the world the first time it ran (thank you Maven!). -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.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
Re: Results from 2011 State of Clojure survey
On Wed, Jul 13, 2011 at 11:41 AM, Phil Hagelberg p...@hagelb.org wrote: Or it could just be that some of the other things on that list were so compelling that they overshadowed these. * The REPL * Functional Programming * Ease of development True. Look at the results - the top five big wins are: * Functional programming * Platform (JVM) compatibility / interop * The REPL * Immutability Next are Macros, Concurrency, Ease of development. Also big wins. I think folks would have to check almost everything to put the features Chas highlighted into the big wins category. Perhaps a more interesting question for next year would be: Which of the following Clojure features are you using? - they don't have to be big wins but it would be nice to know how widely used they are. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.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
Re: Using Clojure To Debug Java Apps
That looks very interesting Dave - can you give a bit more information on what sorts of things you can actually do once you have a REPL connected? (in terms of how to access / explore things inside the running Java application) On Wed, Jul 13, 2011 at 4:06 PM, David Powell djpow...@djpowell.net wrote: I wrote a tool called liverepl a while ago: https://github.com/djpowell/liverepl It effectively lets you get a repl into a Java or Clojure process, but it has the nice feature that it works with any Java processes without requiring any modifications to the code. It uses the Java Attach API, which jvisualvm and jconsole use to inject the repl server into the process, and then it connects the console to that server. It has some special support for Tomcat servers too, so that you can repl into a specific webapp. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Results from 2011 State of Clojure survey
On Jul 13, 2011, at 8:37 PM, Sean Corfield wrote: On Wed, Jul 13, 2011 at 11:41 AM, Phil Hagelberg p...@hagelb.org wrote: Or it could just be that some of the other things on that list were so compelling that they overshadowed these. * The REPL * Functional Programming * Ease of development True. Look at the results - the top five big wins are: * Functional programming * Platform (JVM) compatibility / interop * The REPL * Immutability Next are Macros, Concurrency, Ease of development. Also big wins. I think folks would have to check almost everything to put the features Chas highlighted into the big wins category. Perhaps a more interesting question for next year would be: Which of the following Clojure features are you using? - they don't have to be big wins but it would be nice to know how widely used they are. My phrasing may very well have gotten in the way. Big wins isn't exactly precise language. :-( - Chas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Results from 2011 State of Clojure survey
On Wed, Jul 13, 2011 at 6:25 PM, Chas Emerick cemer...@snowtide.com wrote: True. Look at the results - the top five big wins are: * Functional programming * Platform (JVM) compatibility / interop * The REPL * Immutability My phrasing may very well have gotten in the way. Big wins isn't exactly precise language. :-( Well, I think it clearly identified the big wins so it worked in that respect! :) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.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
meta data question
I know I can get the meta data using the following form:
= (meta #'get)
{:ns #Namespace clojure.core, :name get, :file clojure/
core.clj
Is there a means to get the meta data from the stored function without
using its identifier?
ie. knowing this result:
= get
#core$get clojure.core$get@77036a6b
Can I somehow do this:
=(meta #core$get clojure.core$get@77036a6b)
java.lang.Exception: Unreadable form...
Thanks,
Tim
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Build tool for mixed Clojure/Java projects
On Wed, Jul 13, 2011 at 7:49 PM, Mike Meyer m...@mired.org wrote: On Tue, 12 Jul 2011 22:21:39 -0400 Ken Wesson kwess...@gmail.com wrote: Which means it's not really case 4 at all. Well, it's very clearly not cases 1, 2 or 3. No, it's case zero: standard multi-developer, multi-computer, single canonical master copy on one computer/cluster somewhere. The thing cases 1 through 4 were *alternatives* to. Technically true, but meaningless. The master gets tens of zillions of submissions Completely and totally wrong. Meyer, your *opinion* of me has been made *abundantly* clear by your numerous recent posts publicly attacking my character and questioning my intelligence and/or honesty. Everyone, by now, knows you hate me and knows what you think of me. There is therefore no point in your repeating it over and over again, and no point in your replying to any more of my posts since it's a foregone conclusion what you are going to say and that I am not going to agree with it. That you would go so far as to suggest that Linus doesn't get large numbers of kernel patches crossing his (perhaps not literal) desk, when such is simply not a logical belief to hold, purely for the purpose of publicly disagreeing with me as an excuse for belittling me once again, proves that you have little interest in reasoned discourse with me. Meanwhile, I have no interest at all in any other kind of discourse, so it seems we have nothing to talk about. Good-bye. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: meta data question
#core$get clojure.core$get@77036a6b is a string representation of the fn
object, not the object
itself.
user= (def a get)
#'user/a
user= (meta a)
{:ns #Namespace clojure.core, :name get, :file clojure/core.clj, :line
1154, :arglists ([map key] [map key not-found]), :added 1.0, :inline-arities
#{2 3}, :inline #core$get__inliner clojure.core$get__inliner@3a1834, :doc
Returns the value mapped to key, not-found or nil if key not present.}
works because a contains the fn object (get in this case).
If your intent is to get the meta data of an unnamed fn at runtime the above
solves your issue.
Luc P.
On Wed, 13 Jul 2011 18:35:00 -0700 (PDT)
Tim Robinson tim.blacks...@gmail.com wrote:
I know I can get the meta data using the following form:
= (meta #'get)
{:ns #Namespace clojure.core, :name get, :file clojure/
core.clj
Is there a means to get the meta data from the stored function without
using its identifier?
ie. knowing this result:
= get
#core$get clojure.core$get@77036a6b
Can I somehow do this:
=(meta #core$get clojure.core$get@77036a6b)
java.lang.Exception: Unreadable form...
Thanks,
Tim
--
Luc P.
The rabid Muppet
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: meta data question
On Wed, Jul 13, 2011 at 9:35 PM, Tim Robinson tim.blacks...@gmail.com wrote:
I know I can get the meta data using the following form:
= (meta #'get)
{:ns #Namespace clojure.core, :name get, :file clojure/
core.clj
Is there a means to get the meta data from the stored function without
using its identifier?
ie. knowing this result:
= get
#core$get clojure.core$get@77036a6b
Can I somehow do this:
=(meta #core$get clojure.core$get@77036a6b)
java.lang.Exception: Unreadable form...
= (let [a get] (meta a))
{:ns #Namespace clojure.core, :name get, :file clojure/core.clj,
:line 1154, :arglists ([map key] [map key not-found]), :added 1.0,
:inline-arities #{2 3}, :inline #core$get__inliner
clojure.core$get__inliner@97e3a5, :doc Returns the value mapped to
key, not-found or nil if key not present.}
Current versions, at least, put the meta on the function object itself
and not just the Var. (This was with 1.2). So if you have the
function, in a local like a above, you can get at the metadata.
With just the class name? You can create an instance and call the function:
= (let [a (.newInstance clojure.core$get)] (a {:x 42} :x))
42
But the new instance won't have any metadata:
= (let [a (.newInstance clojure.core$get)] (meta a))
nil
--
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: meta data question
By string I mean human readable...
On Wed, 13 Jul 2011 21:56:58 -0400
Luc Prefontaine lprefonta...@softaddicts.ca wrote:
#core$get clojure.core$get@77036a6b is a string representation of
the fn object, not the object itself.
user= (def a get)
#'user/a
user= (meta a)
{:ns #Namespace clojure.core, :name get, :file
clojure/core.clj, :line 1154, :arglists ([map key] [map key
not-found]), :added 1.0, :inline-arities #{2 3}, :inline
#core$get__inliner clojure.core$get__inliner@3a1834, :doc Returns
the value mapped to key, not-found or nil if key not present.}
works because a contains the fn object (get in this case).
If your intent is to get the meta data of an unnamed fn at runtime
the above solves your issue.
Luc P.
On Wed, 13 Jul 2011 18:35:00 -0700 (PDT)
Tim Robinson tim.blacks...@gmail.com wrote:
I know I can get the meta data using the following form:
= (meta #'get)
{:ns #Namespace clojure.core, :name get, :file clojure/
core.clj
Is there a means to get the meta data from the stored function
without using its identifier?
ie. knowing this result:
= get
#core$get clojure.core$get@77036a6b
Can I somehow do this:
=(meta #core$get clojure.core$get@77036a6b)
java.lang.Exception: Unreadable form...
Thanks,
Tim
--
Luc P.
The rabid Muppet
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: How to add jar files to leiningen projects?
The listing is nice...maybe would be nice to be able to limit the listing to one artifact, or a match of artifacts with wildcards, not sure if the feature would be used enough to justify the work though, but something like: lein localrepo list *ring* would output: [ring] ring-core (0.2.0, 0.2.0-RC2, 0.3.5, 0.3.7, 0.3.8) ring-devel (0.3.5, 0.3.7, 0.3.8) ring-jetty-adapter (0.2.0-RC2, 0.3.5, 0.3.7, 0.3.8) ring-servlet (0.2.0-RC2, 0.3.5, 0.3.7, 0.3.8) [lein-ring] lein-ring (0.3.2, 0.4.0, 0.4.3) - Mark On Wed, Jul 13, 2011 at 6:57 PM, Shantanu Kumar kumar.shant...@gmail.comwrote: Am glad it worked for you. I have updated the plugin to version 0.2 with list functionality. Will appreciate any feedback/suggestion. https://github.com/kumarshantanu/lein-localrepo Regards, Shantanu On Jul 12, 6:40 pm, Mark Rathwell mark.rathw...@gmail.com wrote: Works great, Shantanu. Thanks! On Tue, Jul 12, 2011 at 3:12 AM, Shantanu Kumar kumar.shant...@gmail.comwrote: It would be ideal if it could be run outside of the project structure, as would be the case if an additional arity was added to the install function in leiningen.install. Thanks for the report -- I have pushed version 0.1.1 so it should now be possible to install it as a plugin and run from any directory. Regards, Shantanu -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your 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 post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your 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 post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your 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
Expanding symbols and expression in macros.
I'm not an expert in macros, and maybe this is a stupid question but i think there should be a general pattern for this. I' ve a function: (defn choose* [f choices] Applies f to one of the choices . .) And this macro: (defmacro choose [[c choices] body] `(choose* (fn [~c] ~@body) ~@choices)) Now if i call it with a literal sequence: (choose [x [:a :b :c]] (println x)) it correctly expands to: (choose* (fn [x] (println x)) :a :b :c) but if i have: (def y [:a :b :c]) (choose [x y] (println x)) it gives me an error: don't know how to create ISeq from symbol. with an expression: (choose [x (vec 2 3 4)] (println x)) it expands to: (choose* (fn [x] (println x)) vec 2 3 4) I knew it could not be that simple, and i also understand why i get theese expansions, but i don't get how to solve it. So what's the pattern for something like this, where you want to evaluate a symbol or an expression before expansion? Andrea -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: meta data question
That'll do - Thank you both.
Tim
On Jul 13, 8:12 pm, Luc Prefontaine lprefonta...@softaddicts.ca
wrote:
By string I mean human readable...
On Wed, 13 Jul 2011 21:56:58 -0400
Luc Prefontaine lprefonta...@softaddicts.ca wrote:
#core$get clojure.core$get@77036a6b is a string representation of
the fn object, not the object itself.
user= (def a get)
#'user/a
user= (meta a)
{:ns #Namespace clojure.core, :name get, :file
clojure/core.clj, :line 1154, :arglists ([map key] [map key
not-found]), :added 1.0, :inline-arities #{2 3}, :inline
#core$get__inliner clojure.core$get__inliner@3a1834, :doc Returns
the value mapped to key, not-found or nil if key not present.}
works because a contains the fn object (get in this case).
If your intent is to get the meta data of an unnamed fn at runtime
the above solves your issue.
Luc P.
On Wed, 13 Jul 2011 18:35:00 -0700 (PDT)
Tim Robinson tim.blacks...@gmail.com wrote:
I know I can get the meta data using the following form:
= (meta #'get)
{:ns #Namespace clojure.core, :name get, :file clojure/
core.clj
Is there a means to get the meta data from the stored function
without using its identifier?
ie. knowing this result:
= get
#core$get clojure.core$get@77036a6b
Can I somehow do this:
=(meta #core$get clojure.core$get@77036a6b)
java.lang.Exception: Unreadable form...
Thanks,
Tim
--
Luc P.
The rabid Muppet
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Expanding symbols and expression in macros.
(defmacro choose [[c choices] body] `(choose* (fn [~c] ~@body) ~choices)) --- not ~@, just ~ ~@ expects a sequence result In your first example, [:a :b :c] is a sequence but in the second example, y is not. body is a sequence ( body), using ~@ there is ok there. Luc P. On Wed, 13 Jul 2011 07:33:57 -0700 (PDT) Andrea Tortorella elian...@gmail.com wrote: I'm not an expert in macros, and maybe this is a stupid question but i think there should be a general pattern for this. I' ve a function: (defn choose* [f choices] Applies f to one of the choices . .) And this macro: (defmacro choose [[c choices] body] `(choose* (fn [~c] ~@body) ~@choices)) Now if i call it with a literal sequence: (choose [x [:a :b :c]] (println x)) it correctly expands to: (choose* (fn [x] (println x)) :a :b :c) but if i have: (def y [:a :b :c]) (choose [x y] (println x)) it gives me an error: don't know how to create ISeq from symbol. with an expression: (choose [x (vec 2 3 4)] (println x)) it expands to: (choose* (fn [x] (println x)) vec 2 3 4) I knew it could not be that simple, and i also understand why i get theese expansions, but i don't get how to solve it. So what's the pattern for something like this, where you want to evaluate a symbol or an expression before expansion? Andrea -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Expanding symbols and expression in macros.
On Wed, Jul 13, 2011 at 10:33 AM, Andrea Tortorella elian...@gmail.com wrote: I'm not an expert in macros, and maybe this is a stupid question but i think there should be a general pattern for this. I' ve a function: (defn choose* [f choices] Applies f to one of the choices . .) And this macro: (defmacro choose [[c choices] body] `(choose* (fn [~c] ~@body) ~@choices)) Now if i call it with a literal sequence: (choose [x [:a :b :c]] (println x)) it correctly expands to: (choose* (fn [x] (println x)) :a :b :c) but if i have: (def y [:a :b :c]) (choose [x y] (println x)) it gives me an error: don't know how to create ISeq from symbol. with an expression: (choose [x (vec 2 3 4)] (println x)) it expands to: (choose* (fn [x] (println x)) vec 2 3 4) I knew it could not be that simple, and i also understand why i get theese expansions, but i don't get how to solve it. So what's the pattern for something like this, where you want to evaluate a symbol or an expression before expansion? Andrea Macros splice in an unevaluated expression. You'll get what you want if you change the definition of choose* to: (defn choose* [f choices] Applies f to one of the choices . .) so it takes a function and a sequence argument, rather than a function and a variable number of element arguments, and of choose to: (defmacro choose [[c choices] body] `(choose* (fn [~c] ~@body) ~choices)) so it doesn't splice choices. Your last example (choose [x (vec 2 3 4)] (println x)) should now expand to: (choose* (fn [x] (println x)) (vec 2 3 4)) which means the new choose* will run with choices bound to the vector [2 3 4] as you desired. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your 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
