Re: advantage of dynamic typing
On Wed, Sep 21, 2011 at 3:00 AM, Dennis Haupt d.haup...@googlemail.com wrote: yes, but you magically need to know a) for which types does it work? if you give a byte to the function, will you get an error, or its first bit? or its first char after its been converted to a string? b) if i want my data structure to support this, how do i have to do that? I'm curious: in what world is API documentation considered to be magical? :) -- 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: coding-dojo-20110921
On Wed, Sep 21, 2011 at 8:20 AM, Denis Labaye denis.lab...@gmail.com wrote: Hello, On a code une implem alternative de retour dans le RER: https://gist.github.com/1231894 A+ Denis Hello, On a code what?? -- 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: coding-dojo-20110921
On Wed, Sep 21, 2011 at 3:13 PM, Meikel Brandmeyer m...@kotka.de wrote: Am 21.09.2011 um 19:59 schrieb Ken Wesson: On Wed, Sep 21, 2011 at 8:20 AM, Denis Labaye denis.lab...@gmail.com wrote: On a code une implem alternative de retour dans le RER: https://gist.github.com/1231894 On a code what?? That's french. Yeah, I thought it might be. But it's odd that it suddenly switched from plain English to a foreign language in mid-sentence. Someone has programmed an alternative implementation of return in the RER. ... The RER? -- 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: implement a shell in repl
Wouldn't the simplest way be to simply use the REPL itself as the shell, with a few things defined like this? (def dir (atom (System/getProperty user.home))) (defn pwd [] @dir) (defn cd [dir] (reset! @dir dir)) (defn ... ) -- 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: Is there a reason that def- isn't part of the core lib?
On Sun, Sep 18, 2011 at 6:12 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: And yes, defn- should be located elsewhere than in core. +1 for moving it out of core, at least, defn- should not be make publicly available by core. I'm of more or less the opposite appearance: anything that core itself uses, and that therefore already exists in core, and that is likely to be useful to a significant number of users, ought to be public. Otherwise it will end up wastefully duplicated in core and at least one third-party library, and there might even be a lot of wheel-reinvention -- with some of them probably turning out square. -- 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: Language shoutout clojure code does not have types
On Sun, Sep 18, 2011 at 11:20 AM, Andy Fingerhut andy.finger...@gmail.com wrote: One more detail. The Scala program, and I think all of the fastest programs for that problem, use the GNU GMP library for big integer arithmetic. If that's true, then it indicates that the Java BigInteger class is less than maximally efficient -- otherwise, the JIT should likely turn it into native code of speed the equal of GMP's (perhaps superior, since the JIT could optimize for the exact architecture of the hardware it was running on while your libgmp.so would be compiled for generic x86 hardware so as to be compatible with any x86 box, whether or not it supported 3DNow, MMX, or any of the other various extensions that have cropped up on x86 descendants over the years). Can the BigInt class introduced in Clojure 1.3, perhaps, be made to JIT into code as fast as GMP's? -- 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: Clojure embedded in a Java Application
On Sun, Sep 18, 2011 at 4:06 AM, Meikel Brandmeyer m...@kotka.de wrote:
Am 18.09.2011 um 05:55 schrieb Ken Wesson:
The easiest might be to just pass a map literal (in String form)
through the Clojure reader. Variable integers or other simple objects
can just be incorporated using the Java String + operator; the
concatenation will always start with a string literal such as { so
this will work in general. (It's likely keywords etc. will be constant
while numbers might be variable.)
It's a complete mystery to me why people in the 21st century still promote
messing around with strings as FFI when an easy and simple programmatic
interface exists, which will *always* work – not only with literals the
reader understands. Not to speak about quoting hell and other gotchas.
Tell me which is simpler:
Reader.read({:foo 1 :bar + x + });
or
Var keyword = RT.var(clojure.core, keyword);
Var hashMap = RT.var(clojure.core, hash-map);
hashMap.invoke(keyword.invoke(foo), 1, keyword.invoke(bar), x);
Nobody suggested using the reader in the cases where it is actually
more compact to express using stuff like the above, by the way.
--
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: Clojure embedded in a Java Application
On Sun, Sep 18, 2011 at 4:40 AM, Meikel Brandmeyer m...@kotka.de wrote:
Hi,
Am 18.09.2011 um 10:11 schrieb Ken Wesson:
Tell me which is simpler:
Reader.read({:foo 1 :bar + x + });
String x = 13rabc;
Have fun.
Syntactically invalid Clojure code would fail just as much in Clojure
source as it would in Java source.
If x is expected to be a string, it needs to be quoted. If it's not,
then you have a type error that will blow up at runtime, same as
usual.
Var keyword = RT.var(clojure.core, keyword);
Var hashMap = RT.var(clojure.core, hash-map);
hashMap.invoke(keyword.invoke(foo), 1, keyword.invoke(bar), x);
This one is more simple. This is clojure code.
No, it's Java code, and butt-ugly Java code at that.
And the example shows what unnecessary boilerplate is required in Java which
Clojure hides from you. Everyone knowing how to call
a clojure function understands this code after learning how to get a Var from
a namespace and how to to invoke it.
Capability of understanding isn't the issue. Speed of understanding
is. It takes a lot longer to parse that. And it's harder to be sure it
doesn't have errors.
For yours you have to know what x is. You have to quote it if you want to
pass it as a string. You have to escape various quotes in strings. You have
to know features of the reader.
Your point being? You have to know this stuff to write functioning
Clojure source code, too -- including what types you expect in what
parts of your business logic.
Nobody suggested using the reader in the cases where it is actually
more compact to express using stuff like the above, by the way.
Compactness says close to nothing about simplicity.
In this case, it does.
--
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: Clojure embedded in a Java Application
On Sat, Sep 17, 2011 at 10:58 PM, Eamonn odon...@gmail.com wrote:
Hi Meikel
Thank you for your reply. Is there a way to populate the HashMap
before passing it to the invoke method
The easiest might be to just pass a map literal (in String form)
through the Clojure reader. Variable integers or other simple objects
can just be incorporated using the Java String + operator; the
concatenation will always start with a string literal such as { so
this will work in general. (It's likely keywords etc. will be constant
while numbers might be variable.)
--
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: misuse of or bug in transients?
IMO, get and contains? should work on transients. If the fn-call variant of get works, the others can for transients be defined in terms of that. Add containsKey to ITransientAssociative and implement containsKey on transient sets and maps to do what calling them as functions does, and the problem is completely solved. I can't see why there'd be any controversy over this, by the way. The behavior violates least surprise, is contrary to the written docu, and is easily fixed without worsening the transients' current performance. -- 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 convert general recursion to loop .. recur syntax
On Thu, Sep 15, 2011 at 8:56 AM, Herwig Hochleitner hhochleit...@gmail.com wrote: Consider (defn find-in-tree ([tree pred?] (concat (filter pred? tree) (mapcat find-in-tree (filter sequential? tree) (repeat pred?) which of course is much simpler written as (defn find-in-tree ([tree pred?] (filter pred? (flatten tree Not quite -- these differ in the case where pred? sometimes fires for a subtree and not just for leaves. The latter will miss all the subtrees for which pred? returns logical true. -- 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: autoboxing in 1.3 RC-0
On Thu, Sep 15, 2011 at 10:50 AM, David Nolen dnolen.li...@gmail.com wrote: On Thu, Sep 15, 2011 at 3:18 AM, Sergey Didenko sergey.dide...@gmail.com wrote: Auto-boxing loop arg: change (loop [x 1 changed 0] (if (= x 10) changed (recur (inc x) (loop [y 1 changed-y changed] changed-y Loop itself will return boxed values I think. David It shouldn't, if all the return paths out of the loop return an unboxed primitive of the same type and an unboxed primitive of that type is an acceptable input to the enclosing expression, which is the case here. -- 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: puzzlement over lazy sequences
On Tue, Sep 13, 2011 at 2:39 AM, Michael Gardner gardne...@gmail.com wrote: On Sep 12, 2011, at 11:28 PM, Ken Wesson wrote: But if, as you say, take, drop, etc. work for larger n, it should be easy to make nth work with larger n and non-random-access seqs, just by changing the non-random-access case to (first (drop n the-seq)). I'd be rather surprised if nth suddenly started giving linear performance on arrays for large values of n. If nth can't be made to work in constant time on arrays for n 2**31, then I'd favor the IllegalArgumentException approach. One can always do (first (drop …)) manually if linear performance is acceptable. It already gives log32 rather than constant time performance on vectors, I think. That would stay the same. It can be extended to sorted-set and sorted-map with log2 time performance, again including with large-n support. On actual java.util collections and Java arrays it can just check if n exceeds 2^31 - 1, give not-found behavior if so, and otherwise punt to Java. And on non-random-access stuff it can use (first (drop n thingy)). -- 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: puzzlement over lazy sequences
On Tue, Sep 13, 2011 at 4:18 AM, Stefan Kamphausen ska2...@googlemail.com wrote: Hi, On Tuesday, September 13, 2011 6:28:01 AM UTC+2, Ken Wesson wrote: They're trees of arrays of 32 items, and the trees can in principle have arbitrary depth. So the 2^31 limit on Java arrays doesn't impact the Clojure collections, it seems. are you sure? As far as I understood things (reading PersistentVector.java and [1]), there can only be 6 levels of nodes, because of the 32bit which are used to store an integer and because of the bit-shifting which is used to find the correct level. I said the tree can *in principle* have arbitrary depth. Bit-shifting can be done on BigIntegers, too. -- 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: puzzlement over lazy sequences
On Mon, Sep 12, 2011 at 12:54 AM, Alan Malloy a...@malloys.org wrote: Integer overflow. user (mod 9876543210 (bigint (Math/pow 2 32))) 1286608618 Oops. But nth can probably be fixed while keeping good performance: (defn- small-drop [s n] (loop [n (int n) s (seq s)] (if (zero? n) s (recur (dec n) (next s) (def pow231 (bigint (Math/pow 2 31))) (defn my-nth [s n] (let [s (small-drop s (rem n pow231))] (loop [n (quot n pow231) s s] (if s (if (zero? n) (first s) (recur (dec n) (small-drop s pow231))) Given a bigint n, this does only two arithmetic operations on bigints at the start and one possibly-bigint dec every 2^31 items, instead of doing a bigint dec every single item. So it should be nearly as fast for large n as for small n, per item. I'm guessing there are similar bugs in drop, take, and so forth with large n and large (or infinite) seqs. They should all be fixed. Note: the above code is untested, and (nth n too-short-a-seq) returns nil. For further speed you'd want small-drop to use an unchecked dec. You'd also want my-nth to punt to the special implementations for vectors and other random-access seqables, and maybe change the behavior on long seqs. -- 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: puzzlement over lazy sequences
On Mon, Sep 12, 2011 at 11:55 AM, Stuart Halloway stuart.hallo...@gmail.com wrote: I'm guessing there are similar bugs in drop, take, and so forth with large n and large (or infinite) seqs. They should all be fixed. The other fns are ok, thanks to their separate heritage. drop, take, et al are sequence functions, and proceed iteratively. nth is of a different lineage. It was designed to target collections that support constant time-lookup. Collection-y things in the Java world provide APIs that take int, not long, because that is what arrays do at the bottom. FWIW, Sun (now Oracle) considers this a low-priority problem: http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=5d84e2e6a65a5c03eacaafb73e91?bug_id=4963452. nth has a doc bug: it should be documented as a function of a collection and a 32-bit int. A patch updating the docstring, and even enforcing it with an IllegalArgumentException, would be welcome. (George: want to write your first patch? :-) ) Stu Stuart Halloway Clojure/core http://clojure.com The Clojure collections aren't just flat arrays, though, are they? They're trees of arrays of 32 items, and the trees can in principle have arbitrary depth. So the 2^31 limit on Java arrays doesn't impact the Clojure collections, it seems. And nth should therefore work for larger n, on all of them. But if, as you say, take, drop, etc. work for larger n, it should be easy to make nth work with larger n and non-random-access seqs, just by changing the non-random-access case to (first (drop n the-seq)). -- 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: puzzlement over lazy sequences
On Sun, Sep 11, 2011 at 8:28 AM, Stuart Halloway
stuart.hallo...@gmail.com wrote:
cycle actually calls lazy-seq. A quick way to check such things at the REPL
is with source:
user= (source cycle)
(defn cycle
Returns a lazy (infinite!) sequence of repetitions of the items in coll.
{:added 1.0
:static true}
[coll] (lazy-seq
(when-let [s (seq coll)]
(concat s (cycle s)
snip
Is there any reason not to define it as
(defn cycle
Returns a lazy (infinite!) sequence of repetitions of the items in coll.
{:added 1.0
:static true}
[coll]
(let [l (lazy-seq
(when-let [s (seq coll)]
(concat s l
This will have the effect that holding any element of the cycle holds
the head; however, even the original holds the head of s as long as
the cycle is referenced, so that at worst doubles memory use for
finite s, and for finite walks along the cycle with infinite s, as s
(or the first N elements of s) get held onto in both cases, but an
equal number of cycle elements get held onto with the self-referencing
cycle instead of potentially only one at a time.
Now I'll test it with 9876543210, a number which ev? was able to
handle:
user= (time (mod3 9876543210))
Elapsed time: 37759.615 msecs
1
user= (mod 987654321 3)
0
Whoa! The computation finished in reasonable time, but with the WRONG
answer! How did that happen?
Did I find a bug?
No, there is simply a typo in your input arg.
True, but both numbers are congruent to 0 mod 3, so where did the 1
come from in (time (mod3 9876543210))?
--
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: Clojure 1.3: defs can now have docstrings; how so?
On Tue, Sep 6, 2011 at 9:13 AM, Meikel Brandmeyer (kotarak) m...@kotka.de wrote: user= (def foo A foo :foo) #'user/foo user= (doc foo) - user/foo A foo nil Hrm. Doc on a var not bound to a function or macro doesn't print its (default) value? -- 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: not= counterintuitive?
On Sat, Sep 3, 2011 at 1:30 PM, Despite desp...@gmail.com wrote: So, you want to make sure each value in the vector is unique? My first thought was to put them into a set, then see if the set was equal to the vector, but clojure's equality doesn't allow for that. And if you put the set back into a vector, you've changed the order. Just see if the set is the same *size* as the vector. If there were duplicates, it will be smaller instead. -- 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: new Getting Started page
On Sat, Sep 3, 2011 at 2:11 AM, Kevin Downey redc...@gmail.com wrote: The idea that the way to get started is with a fancy editor and a fancy ide is just crazy. The way to get started with Clojure is: write functions, and run them, and be happy. None of that requires any of the mandated complications that come from sophisticated editing environments. Nope; not if you don't mind losing such minor frills as being able to save your code to disk and come back to it later. :) -- 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: new Getting Started page
On Sun, Sep 4, 2011 at 9:50 PM, Alan Malloy a...@malloys.org wrote: Are we catering to the crowd who (1) wants to try Clojure, and (2) doesn't have a text editor with copy/paste on their system? Well, in the original context a Unix commandline environment was being suggested as well, which means no global clipboard. Even if you opened an editor and copied something, if you then closed it, ran lein repl or whatever, and tried to paste -- nada. Same thing in reverse. -- 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 create a ordered data structure which would efficiently return the element before and after it
On Thu, Sep 1, 2011 at 2:08 PM, Alan Malloy a...@malloys.org wrote: Well, the two calls to subseq are unpleasant and possibly slow. I was thinking there's a way to write it as a single operation that returns three items, say (subseq s = (dec 50)) to get the items before and after 50, but of course that doesn't work unless you know 49 is in there, and in that case why bother with subseq? It's a bit galling, because the sorted-set *knows* how to get to where 50 should be, and how to walk in either direction from there, but in order to walk in two different directions you have to walk down from the root twice. Maybe it'd be nice to have a (get-walker s 50) that you can later pass directions to, to walk through the set in whatever order. A less-Clojury solution would be to have sorted-set implement List, and provide something like get-walker that yields a ListIterator on the specified element, or the next higher if any, or one past the end otherwise, or whatever. Of course a ListIterator is a mutable Java object. A Clojury solution would be a function that traverses from the root and then generates a return value equivalent to [(rsubseq s x) (subseq s x)], except not performing two traversals to generate it. The caller can destructure this and use the two seqs. -- 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: Top secret clojure project names
On Thu, Sep 1, 2011 at 5:31 PM, JAX jayunit...@gmail.com wrote: Hi guys: I assume some of you have secret Clojure projects at work, that your bosses don't know about. I was going to suggest that we all decide on a convention for top secret clojure project names... Like maybe soft drink names? That way we can all recognize each other. And anyone policing for unauthorized use of Clojure at their workplace can read this mailing list and know exactly what to watch out for. :) Anyways... Or Maybe there is already a clojure code name convention that I never knew about? Well, there's a few associated names with js substituting fro ss... -- 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: passing a list as a ref bombs
On Wed, Aug 31, 2011 at 3:14 PM, loonster tbur...@acm.org wrote: I'm converting a newLisp application I wrote, in production for several years, into clojure, and got stuck immediately. (def input-list (ref '(OR,CA,CO,ID,WA))) (defn list-ploop accepts a ref and returns a list's first and alters the rest [in-list] (do (dosync (ref-set input-list (rest in-list)) ((first in-list) Issuing (list-ploop @input-list) successfully alters the input-list, but it bombs on evaluating the (first ). Many thanks. I'm not sure what you're trying to do here, but it seems likely that (defn list-ploop accepts a ref and returns a list's first and alters the rest [in-list] (dosync (let [res (first @in-list)] (alter in-list rest) res))) (list-ploop @input-list) is what you're after. -- 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: get keys from defrecord
On Mon, Aug 29, 2011 at 10:14 PM, Steve Miner stevemi...@gmail.com wrote: On Aug 29, 2011, at 8:20 PM, Alex Miller wrote: I'm not sure if there are any enhancements in the 1.3 record support for this feature. In 1.3beta2, the record class has a static method getBasis that will give you the fields. I remember Fogus mentioning this on the mailing list. The design notes [1] say These methods should not be used in Clojure code as they're intended for tool support, but they seem generally useful to me. In a Lisp, anything useful for tool support and accessible from inside the language tends to be useful sometimes in macros as well; perhaps macros need to be considered part of tool support for a Lisp. After all, they are used to extend and metaprogram the language. -- 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: ClojureScript and lein?
On Mon, Aug 29, 2011 at 9:09 PM, Eric Lavigne lavigne.e...@gmail.com wrote: I'm also a Mac user and probably in home all this howto will work, but in company where we all are using Windows there is no chance to get it working easily. There are people at your workplace who program in Clojure, or who are willing to try it, but aren't willing to try developing on Linux or Mac? This surprises me. If all they have are Windows PCs, they'd have to buy a whole additional machine to develop on Mac. It's one thing to get coders to experiment and quite another to get management to release several hundred dollars of funds to support that experiment. The same almost goes for Linux. The sole alternative to an additional machine in that case is to perform major surgery on an existing one, involving a hard drive repartitioning. The coders that are willing to experiment and the IT admins with the root passwords for the PCs may not be the same people, and no repartitioning and dual-boot OS installs would take place without the cooperation of the latter. -- 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: A re look at re-groups
On Tue, Aug 30, 2011 at 11:18 AM, Matt Smith m0sm...@gmail.com wrote: I have been studying patterns or the notion of idiomatic code in Clojure. The code in clojure.core has some good examples of proper Clojure code and is well done. For that reason I was a bit surprised at the definition for re-groups: (defn re-groups [^java.util.regex.Matcher m] (let [gc (. m (groupCount))] (if (zero? gc) (. m (group)) (loop [ret [] c 0] (if (= c gc) (recur (conj ret (. m (group c))) (inc c)) ret) It seems like the loop/recur is non-idiomatic for this usage and could be done with either a map or reduce. Speed is probably the consideration here, assuming this code appears after the bulk of bootstrap. The final implementation with multi-methods seems cleaner to me in making it clearer what the intent of the code is while allowing the disjoint functionality. Too bad the result of the defmulti filter is not available to the methods. This suggests that the following might be a useful enhancement to multimethods: if any particular method is given 1 more argument than the dispatch function, the last argument will be filled with the dispatch function's return value if that method is selected. -- 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: ClojureScript and lein?
On Tue, Aug 30, 2011 at 1:03 PM, Mark Rathwell mark.rathw...@gmail.com wrote: The sole alternative to an additional machine in that case is to perform major surgery on an existing one, involving a hard drive repartitioning VirtualBox is free: http://www.virtualbox.org/ Emulators? I hadn't considered those, mainly because they're generally expensive (comparable in some cases to buying fresh hardware, only without growing your nonvolatile space or cluster crunching power) and usually substantially deviate from the behavior of a real, separate machine in at least some cases. I'd think it especially likely that if there's a free one, there're a lot of software that won't quite work the same as on a separate PC, and will be outright broken in some cases. There's also the matter of OS vendors commonly inserting EULA clauses forbidding installing to emulated machines, of questionable encorceability (my reading of copyright law doesn't seem to indicate that how the user uses some software post-sale is one of a copyright holder's exclusive rights, though what do I know; I'm no lawyer), and backing that up with features of their product activation schemes (there's the enforceability, not in courts but in software), but that's moot in the case that the OS you'd be installing is Linux. MacOS is right out, though, even if VirtualBox can emulate Macintosh hardware. -- 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: ClojureScript and lein?
On Tue, Aug 30, 2011 at 2:19 PM, Phil Hagelberg p...@hagelb.org wrote: On Tue, Aug 30, 2011 at 10:10 AM, Ken Wesson kwess...@gmail.com wrote: VirtualBox is free: http://www.virtualbox.org/ Emulators? I hadn't considered those [...] I'd think it especially likely that if there's a free one, there're a lot of software that won't quite work the same as on a separate PC, and will be outright broken in some cases. Virtualbox is not an emulator; it's a virtualization tool. Same difference. Just because the processor hardware doesn't need to be emulated doesn't make it not an emulator. On modern hardware (core 2+) it's capable of running at full CPU speed with a minor I/O perf penalty. On our team we develop almost exclusively in it; there are no emulation quirks. There will be filesystem emulation quirks, though probably not as bad as the Cygwin/Windows impedance mismatch another thread here recently discussed. This might extend into other hardware-I/O-intensive areas of program operation too. Have you ever tried to run a complex Windows program, especially a recent game, in Wine? Well, Cygwin is like doing that with the Linux/Windows roles reversed. VirtualBox will make the interface point closer to the metal than Cygwin, with some big volume image file in the host FS emulating a hard drive rather than just using the host FS as the Linux FS. Anything that depends on low-level behavior of a real disk drive will have problems, and that likely includes fsck, which may run at bootup under some circumstances (such as if the hosted Linux thinks it wasn't shut down normally last session -- and if VirtualBox crashes, which, being Windows software, eventually it will, that's likely to happen; also if there's a garden variety power outage). Database software (for heavyweight enough DBs) also tends to play with disk drives at a low level, for instance by implementing a B-tree right on the platters in a separate partition in lieu of using a file or files in the operating system's FS. The latter could be worked around, by hosting the database from Windows or by using a spare external disk drive (which might not have been a viable boot device, preventing simply installing Linux to it and obviating the need for VirtualBox). MacOS, of course, probably has DRM that examines the hardware to make sure it's running on a genuine Mac. If the emulator doesn't fool it successfully it won't run, and if it does it could be treated in the US as a DMCA violation (stupidly enough this is true even if there's no actual copyright infringement, i.e. the copy of MacOS is not pirated). I wouldn't be surprised if Apple does funny, proprietary things to the boot drives in its hardware that the DRM will check for and that VirtualBox's emulation of a hard drive probably won't pass this test. If you are stuck on Windows without the option of adding an OS to your machine, Virtualbox is a great way to get a nice isolated development environment going. It also has the benefits of being easier to automate, snapshot, and not avoid interfering with the operation of your host. As long as whatever differences do exist, and there will be some, don't trip you up in some manner. A better use might be to install Windows, a web browser, and little else to it, take a snapshot, and use it for surfing, backing up downloaded files and your bookmarks now and again; if you get infected, or want to be really sure of clearing all history, including Flash cookies and any other stuff plugins might squirrel away outside the HTTP cookie mechanism for privacy reasons, restoring a backed up image over top will reset it. Another use would be to run Linux, a server, and ancillary tools, snapshot it, and turn it on; it's a bit more work to get the server back up after any shutdown, but on the other hand if you get hacked the attackers probably can't find their way out of the virtual box and may not even realize they're in one. The stuff in the host is probably safe. Antivirus companies use them now, with old unpatched Windows versions running in them, to test suspicious files people send them. They probably also surf pr0n sites unprotected from wide-open Win98 boxes to see what's out there. Then halt the emulator and dissect the drive image file to see exactly what the infection(s) did, without the infection(s) interfering even if they have rootkit-like qualities. But for development, I'd be worried that the differences (even in performance characteristics) from a normal box could interfere in unforeseen ways. In the worst case, you could end up developing software that works only in VirtualBox-hosted systems. :) -- 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
Re: mutability in the let-form!?
On Sat, Aug 27, 2011 at 6:05 AM, Alan Malloy a...@malloys.org wrote: Stylistically, it's often not very nice to rebind x a number of times; it's better to choose descriptive names for the intermediate steps. But there are certainly times occasions where using the same name can clarify meaning: for example, you're just tidying up x into a nicer form, or canonicalizing it in some way. A common case IME is monkey-patching x to deal with singular values, particularly nil via a binding like [x (if x x (foo))]. -- 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: JVM 7 support (invokedynamic)
On Thu, Aug 25, 2011 at 2:49 AM, Tal Liron tal.li...@gmail.com wrote: Hey folks, I just want to reassure y'all that I am working on this. It took a while to create a test environment: one of the challenges of using invokedynamic is that the Java language does not support it; so the best way to test right now is with ASM 4.0, which is still not officially released. Documentation on the opcode is also somewhat scattered, and mostly out of date, since JSR-292 has changed quite a bit until the final release. The JRuby folk are definitely at the cutting edge of this right (well, after all, JRuby's John Rose is the key mover and architect behind the JSR), and I'm trying to learn from their implementation. Right now I'm working on a code tree outside the main Clojure source, and once that seems to work, I will try to merge it into a branch. So, it's not *quite* as easy as I hoped, but I still think it will be much easier to use invokedynamic in Clojure than in JRuby. I'll keep the mailing list updated on my (slow) progress, and will definitely make the code public once it becomes ... presentable. Just out of curiosity, what will this actually enable? Optimizations? What can we expect might perform faster -- calling closures? Functional function-calls such as map, reduce, etc.? Multimethods, protocols, and things like that? -- 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: Why can't I print new sequence?
On Thu, Aug 25, 2011 at 7:53 AM, octopusgrabbus octopusgrab...@gmail.com wrote: Ken: Thanks for the answer. You're welcome. You're correct about distinct. I'm working through some exercises. Ah. Always good to get to know the language better. -- 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: Making clojure.lang.IDeref a protocol
On Thu, Aug 25, 2011 at 11:40 AM, Stuart Halloway stuart.hallo...@gmail.com wrote: Has there been discussion about making clojure.lang.IDeref a protocol? Someday. The challenge is load order. A lot would have to change to make protocols available early enough in Clojure's bootstrap to allow this. Thinking outside of the box, what about exposing a low level ability to define a Java interface separately somewhere, then erect the rest of the machinery of a protocol around it later? Then IDeref can be just an interface early in bootstrap, but be protocolized late in bootstrap and available in protocol form thereafter. (This could also be applicable to potentially-more-useful interfaces like IFn, ISeq, and Associative, too.) -- 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: I/O
On Thu, Aug 25, 2011 at 6:49 PM, Lee Spector lspec...@hampshire.edu wrote: While slurp and spit are beautifully elegant it's not so elegant to tell slurp how to find the file you want it to slurp. In many other languages/environments there's a concept of the working directory or project directory, relative to which you can specify locations. In Clojure you have to deal with the classpath, outside of the language proper, and many of the common ways of running Clojure programs handle this differently. I don't know if there's a good, general solution to this, but for me (both as a programmer and especially as a teacher) it is definitely a pain point. What about (System/getProperty user.dir)? -- 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: Peculiar transients behaviour
What does zipmap do if the key seq contains duplications? -- 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: Apply concat and mapcat evaluate seqs unnecessarily
On Wed, Aug 24, 2011 at 3:49 PM, Asim Jalis asimja...@gmail.com wrote: I used take 0 as a simple example to illustrate the problem. But in general the standard mapcat evaluates terms than are needed. My f function does a web call and processes the JSON records produced by this call, so each extra call is a significant performance and resource hit. You may be able to wrap each web call in an explicit delay, and construct your lazy seq of these delays, then force the ones you actually want to use. Then the expensive JSON calls won't take place for any element until needed, no matter how far any of the sequence processing functions look ahead, as long as none of them will need to peek inside the delays until outside the problematic mapcat. (So, (mapcat (filter ...)) would be trouble, as the filter predicate may need to force the delays in the inner sequence, but (filter (mapcat ...)) should be ok unless filter is also looking ahead.) -- 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: Why can't I print new sequence?
On Wed, Aug 24, 2011 at 5:58 PM, octopusgrabbus octopusgrab...@gmail.com wrote: (defn f1 [in-seq] (loop [new-seq [] cur-seq in-seq] (if (nil? (first cur-seq)) new-seq (if-not (nil? (x-in-seq (first cur-seq) new-seq)) (recur (conj new-seq (first cur-seq)) (rest cur-seq)) You don't have a second branch for that last if, so the whole thing evaluates to nil if there are any duplicates, which there are. You need an else clause of (recur new-seq (rest cur-seq)). Or you could just use clojure.core/distinct :) -- 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: clojure.java.jdbc: mapping BigDecimal to double
On Tue, Aug 23, 2011 at 9:54 PM, HiHeelHottie hiheelhot...@gmail.com wrote: Are there any future plans to add a mapping api to resultset-seq or is the pattern just to chain any custom mappings after resultset-seq? Is wrapping in (map double ...) too much typing? :) -- 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: Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
On Sun, Aug 21, 2011 at 3:14 AM, Alan D. Salewski salew...@att.net wrote: That presumption is at least partially incorrect. Native apps (cmd.exe, for instance) launched from a cygwin bash command prompt can see environment variables exported by the parent bash process. I never claimed there wasn't a way to *export* them. Indeed, if one can read bash environment variables and set Windows environment variables then one obviously can export them. since clearly bash has a different idea of what an environment variable is, Nope; Yep; bash has, in particular, a different idea of what names are allowed. If it just used an underlying host OS facility one would expect that it would impose no requirements of its own, so a name acceptable by the host would be acceptable by bash given whatever syntactic disambiguation (e.g. quoting or escaping) might be required in some cases to make sure bash recognized the name as being a variable and not something else. Each bash process, in fact, will have it's own environment, which will have been provided by its parent process. Any Unix look-a-like thing running on Windows will need to present a view of a process-specific environment to the *nix-style tools in a way they are prepared to handle (PATH values will be translated, and similar), and the environment constructed for native Windows programs launched by those *nix-style tools should ideally see the values in a way they would expect (at least for important, well-known vars, such as PATH). And this is how things do work with cygwin, from the vantage point of the apps. That's basically what I was saying. There's a translation layer in there, rather than the host environment variables and bash's being identical. Then, (building on sand...) Wrong, and I'll thank you to stop publicly insulting me for no good reason, AND to stop monkeying with the reply-to in an apparent effort to make my posts get sent to the list in two copies. no matter what it's named, if a Windows application uses a Windows environment variable it will be more awkward to manipulate from a Windows port of bash than an emulated native unix environment variable, and likewise more awkward than a true native unix environment variable manipulated on a unix machine and used by a native unix application. Not necessarily true. Yes necessarily true; it's simple logic. Either bash uses the host OS's environment variables or it doesn't. If it doesn't, then using the host's (when separate) is more awkward than using bash's internal ones (and you yourself have complained that it's more awkward). If it does, then most of what you and others said in this thread was wrong, and what I said is moot because it was based on a presumption of some of your claims in that regard having been correct. I noted earlier that Unix and Linux are both permissive in the names allowed for environment variables; nevertheless, in *nix there's a tradition of following established conventions unless there is a good reason not to. Naming environment variables such that they can be manipulated as POSIX shell identifiers is just one example of following a useful convention: And here you again admit a distinction between environment variables and shell variables, this time indicating that they don't even coincide on unix, let alone on Windows. That distinction undermines pretty much everything else you've said, however, and in particular all the gratuitous insults you've lobbed at me on a public mailing list. No good reasons have yet been posited on this thread to use an environment variable named to be incompatible with that established convention, regardless of what is permissible by the host OS. The established convention in question is a UNIX convention and the software you're complaining violates it is WINDOWS software. There IS no Windows convention on naming environment variables compatibly with shell identifiers because there ARE no shell identifiers on Windows, at least not in the same sense as in unix. Windows, and Clojure-CLR, were not written with the convenience of bash users in mind. If there's an impedance mismatch with bash users the problem is with bash being NONnative on Windows, not with the native Windows apps the bash users are finding it awkward to use from in bash! And lest you consider this to be unix-bashing or Windows-promoting, it'd be as invalid, for identical reasons, to complain that a unix tools have an impedance mismatch with a unix-ported Windows tool and blame the unix tools. 1. The OP just wanted to *set* the variable and call Clojure-CLR. That problem is solved. That's not an accurate representation of what the OP wanted, It is an accurate representation of what the original post said, and I'll thank you to stop falsely accusing me of inaccuracy! If that were satisfactory to the OP and other folks who have chimed in since, then we could have dropped this whole thing a while ago. I thought we HAD dropped
Re: Video Slides on Pattern Matching and Predicate Dispatch in Clojure
On Thu, Aug 18, 2011 at 11:00 PM, Meikel Brandmeyer m...@kotka.de wrote: Eh, what exactly does slideshare provide over a PDF put on some server somewhere? Apparently, the ability to annoy the hell out of whoever you try to share it with. -- 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: Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
On Thu, Aug 18, 2011 at 11:05 PM, dmiller dmiller2...@gmail.com wrote: Several comments: (a) 'clojure.load.path' is not new in 1.3. It's been in the code since at least May, 2009. (b) Regarding Dimitre's comment below, I probably did have Java system properties on my mind at the time. I guarantee that I was not thinking of picking Bash-compliant names. I doubt that I gave it much thought at all. (c) It could be changed to something like CLOJURE_LOAD_PATH instead. Would that cause a problem for anyone? Just the ones that want to have something to gripe about. :) And, maybe, the ones who have to go and reconfigure everything when they upgrade ... -- 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: Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
On Wed, Aug 17, 2011 at 4:25 PM, Dimitre Liotev lio...@gmail.com wrote: you can not set and query such a variable in a Bash script. Code has already been posted to this thread that does exactly that. -- 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: Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
On Thu, Aug 18, 2011 at 4:56 PM, D L lio...@gmail.com wrote: On Thu, Aug 18, 2011 at 7:34 PM, Ken Wesson kwess...@gmail.com wrote: On Wed, Aug 17, 2011 at 4:25 PM, Dimitre Liotev lio...@gmail.com wrote: you can not set and query such a variable in a Bash script. Code has already been posted to this thread that does exactly that. Let me rephrase this for you: you can not set and query such a variable in the standard, conventional, predictable Bash way. This is what matters. No point in devising ways to torture users by forcing them to use ugly hacks for something as basic and simple as setting a variable. But the standard way of setting a variable in bash would presumably not, in a Windows port of bash, affect the environment as seen by native programs anyway, since clearly bash has a different idea of what an environment variable is, how it can be named, and so on than Windows does, and so seems to necessarily have a different environment than Windows's. Then, no matter what it's named, if a Windows application uses a Windows environment variable it will be more awkward to manipulate from a Windows port of bash than an emulated native unix environment variable, and likewise more awkward than a true native unix environment variable manipulated on a unix machine and used by a native unix application. But this is all entirely beside the point: 1. The OP just wanted to *set* the variable and call Clojure-CLR. That problem is solved. A claim was mooted that it was unsolvable without renaming the variable, and that claim was decisively proved wrong. 2. Subsequently, a claim was mooted that though it was admittedly possible to *set* the variable it would not be *possible* to read it, and thus to set it to a function of its prior value -- and THAT claim was decisively proved wrong. 3. So now you admit that it IS possible, but instead of leaving it at that, you just change your objection -- AGAIN -- this time to say that it's *too inconvenient*. 4. On top of all of this goalpost-moving by what seems to be either a Sybil attack or a tag-team of opponents ganging up on me, there's the minor little matter of the fundamentally questionable assumption they (you) are making, which is that developers of native Windows applications should be adhering to Unix naming conventions for the convenience of that tiny fraction of Windows users that use a port of bash to Windows as their command shell instead of using native tools such as cmd and Explorer! Taken to its logical extreme, such a position is probably untenable, as it's likely that if you intersected the subsets of names and other practices that would be allowed and convenient for all operating systems you'd wind up with the empty set and become paralyzed into inaction. :) You can't please all of the people all of the time, and apparently the same goes for operating systems. It's generally regarded as acceptable for Windows-native applications to adhere to Windows conventions, unix-native ones to unix conventions, and so forth; and here we have a Windows-native application with an environment variable name that lies within the realm Windows allows to manipulate conveniently, but happens to be awkward to deal with in unix. I'd say that that's too bad for the unix user affected by it, but not a foul by the Windows community, and it's not even the biggest unix/Windows impedance mismatch out there -- how about cr/lf vs. lf? Space-ridden case-insensitive file names that need to be quoted to move to unix, and cause collisions sometimes moving the other way? Name collisions are certainly a larger inconvenience than having to -- my God! -- use sed a little bit. :) -- 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: Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
On Wed, Aug 17, 2011 at 9:48 AM, Alan D. Salewski salew...@att.net wrote: $ /usr/bin/env -- ALJUNK_CRAP1=junk1 ALJUNK.CRAP2=junk2 /bin/bash -c env | grep ALJU ALJUNK.CRAP2=junk2 ALJUNK_CRAP1=junk1 You approached the question from the perspective of one just wanting to launch Clojure-CLR with a 'clojure.class.path' value inherited from the host OS, however that can be made to work. I approached the question from the perspective of one wanting to invoke Clojure-CLR with the ability to manipulate the value of 'clojure.class.path' on-the-fly in a way that is common and natural for *nix folks. And with 'env' it clearly is possible to manipulate the value on the fly, as Stephen pointed out three hours before your post and as you yourself have demonstrated. The OP's problem has been solved; let's move on. -- 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: Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
On Thu, Aug 18, 2011 at 12:32 AM, Alan D. Salewski salew...@att.net wrote: On Wed, Aug 17, 2011 at 01:47:53PM -0400, Ken Wesson spake thus: On Wed, Aug 17, 2011 at 9:48 AM, Alan D. Salewski salew...@att.net wrote: I approached the question from the perspective of one wanting to invoke Clojure-CLR with the ability to manipulate the value of 'clojure.class.path' on-the-fly in a way that is common and natural for *nix folks. And with 'env' it clearly is possible to manipulate the value on the fly, as Stephen pointed out three hours before your post and as you yourself have demonstrated. Aside from the matter that using 'env' is clunky for common command line usage, it is /not/ possible manipulate the value on the fly, generally. There is no in-principle difference between using 'set' and using 'env'. It's just a different three letters here and there in your script. There are at least three common scenarios to consider: 1. Inovking the Clojure-CLR from bash w/o setting or modifying 'clojure.load.path'. Just run it. 2. Invoking the Clojure-CLR from bash, supplying an explicit value for 'clojure.run.path' not based on the existing value, if any. 3. Invoking the Clojure-CLR from bash, augmenting the existing value of 'clojure.run.path' with an explicit value. Use a script that wraps the invocation in a save and set, then a restore, of clojure.run.path; or spawn a subsidiary shell with its own copy of the environment with a short script that sets the environment variable and then runs Clojure-CLR, popping the environment changes on exit. Scenario 3 cannot be addressed by 'env' because it requires manipulation of the existing value of the variable. You aren't honestly claiming that there is no way to extract the value into a bash shell variable, are you? Not after you yourself posted this snippet earlier: $ /usr/bin/env -- ALJUNK_CRAP1=junk1 ALJUNK.CRAP2=junk2 /bin/bash -c env | grep ALJU ALJUNK.CRAP2=junk2 ALJUNK_CRAP1=junk1 So, env | grep clojure.class.path | sed sed code to extract what's after the = goes here | whatever and you can grab the existing value and compute something from it. Couldn't be simpler. -- 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: Spitting out a lazy seq to file???
On Tue, Aug 16, 2011 at 11:26 AM, Thomas th.vanderv...@gmail.com wrote: Hi everyone, I have been struggling with this, hopefully, simple problem now for quite sometime, What I want to do is: *) read a file line by line *) modify each line *) write it back to a different file This is a bit of sample code that reproduces the problem: == (def old-data (line-seq (reader input.txt))) (defn change-line [i] (str i added stuff)) (spit output.txt (map change-line old-data)) == #cat output.txt clojure.lang.LazySeq@58d844f8 Because I get the lazy sequence I think I have to force the execution? but where exactly? And how? The spit function expects a string; you need to pr-str the object. However, that will output it like the REPL would: (line1 line2 line3 ...) You probably want no parentheses, and separate lines. So you'll want something more like (with-open [w (writer-on output.txt)] (binding [*out* w] (doseq [l (map change-line old-data)] (println l The output part is lazy now, so you might want to consider making the input part lazy as well: (with-open [r (reader-on the-input-file) w (writer-on output.txt)] (binding [*out* w] (doseq [l (line-seq r)] (println (change-line l) (note: untested, and assumes suitable reader-on and writer-on functions such as from contrib) Then it will be able to process files bigger than can be held in main memory all at once. -- 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: Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
On Tue, Aug 16, 2011 at 1:20 AM, Alan D. Salewski salew...@att.net wrote: On Tue, Aug 16, 2011 at 12:34:39AM -0400, Ken Wesson spake thus: On Mon, Aug 15, 2011 at 11:13 AM, mrwizard82d1 mrwizard8...@gmail.com wrote: I understand that the 1.3 beta plans to add an environment variable named clojure.load.path to provide a CLASSPATH mechanism for Clojure on the CLR. Although I use Windows, I have installed cygwin because I prefer the Unix tool set to that provided by Windows. Although a Windows console allows one to set environment variables like clojure.load.path, the bash shell does not. Are you sure there isn't some form of quoting or escaping that will make that name acceptable to bash? Identifiers in bash may contain only alphanumeric characters and underscores, and must start with an alphabetic character or underscore; there's no way to get around that with escaping or quoting. Pardon me, but that seems to be missing the point. You don't need a bash-language variable named clojure.load.path, you just need to set a Windows environment variable named clojure.load.path, and the rules for what characters are allowed in the names of Windows environment variables will still be those set by Windows, which apparently permit periods. As far as your bash script is concerned, clojure.load.path probably needn't be anything more than an opaque string passed to the host operating system via a call of some kind -- though that string could conceivably require quoting or escaping where it's embedded as a literal in the script. If bash has its own environment variable system, then that could be confusing you, but then even if you succeeded it wouldn't work; the Clojure tools won't see bash's internal system, only the host OS's, so it's the host OS environment variables you need to get at regardless. -- 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: syntax quoting and namespaces misbehaving in test?
The def special form seems to be a bit strange that way, in that (def sym thingy) seems to do two things: execute a (declare sym) at read or macroexpansion time, even when inside a function definition rather than at top level, and execute an (alter-var-root! sym (constantly thingy)) when actually reached by flow of control. If you want runtime-only def behavior you need to either use the namespace object's intern methods via interop or use (eval `(def ~sym ~thingy)). -- 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: Stanford AI Class
On Tue, Aug 16, 2011 at 6:45 PM, André Thieme splendidl...@googlemail.com wrote: On Aug 13, 11:14 pm, Ken Wesson kwess...@gmail.com wrote: On Sat, Aug 13, 2011 at 1:36 PM, Lee Spector lspec...@hampshire.edu wrote: On the one hand most people who work in genetic programming these days write in non-Lisp languages but evolve Lisp-like programs that are interpreted via simple, specialized interpreters written in those other languages (C, Java, whatever). The ultimate in Greenspunning. :) Exactly! All those people doing GP in C++ end up doing it in Lisp anyway. They write a GP engine that generates trees and manipulates them and then they'll have to write an interpreter for that limited language, which is basically the idea of Lisp. OMG ;) Whereas if you started out with Lisp, you can skip all that and just write: a) a few functions/macros b) something to make/evolve trees of forms whose operator-position symbols name those functions and macros c) (eval evolved-form) and Bob's your uncle. The interpreter you get for free, in the form of the macroexpander and eval. Actually using Lisp is like having library support for your Greenspunning. :) -- 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: Problem with Greeks!
On Tue, Aug 16, 2011 at 7:56 PM, cran1988 rmanolis1...@hotmail.com wrote: I tried (str Γεια!) and i got ! what can I do to fix it ? Set something, somewhere, to UTF-8 that's probably set to ISO-8859-1 or US-ASCII right now. Also, her name would be spelt Λεια, and her famous plea Ηελπ με, Οβι-ωαν Κενοβι! or something like that. :) -- 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: Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
On Mon, Aug 15, 2011 at 11:13 AM, mrwizard82d1 mrwizard8...@gmail.com wrote: I understand that the 1.3 beta plans to add an environment variable named clojure.load.path to provide a CLASSPATH mechanism for Clojure on the CLR. Although I use Windows, I have installed cygwin because I prefer the Unix tool set to that provided by Windows. Although a Windows console allows one to set environment variables like clojure.load.path, the bash shell does not. Are you sure there isn't some form of quoting or escaping that will make that name acceptable to bash? Failing that, can you invoke Windows's setenv from within bash? If it's a .com or .exe it should be possible but if it's a cmd.exe builtin command like dir you'd probably be SOL. (You can invoke cmd.exe with a command to execute, but I expect if that command is setenv the environment change will be popped when cmd.exe exits.) Failing that, too, you could resort to cobbling together your own setenv.exe using Windows APIs and gcc to invoke from your launch script. -- 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: Stanford AI Class
On Sun, Aug 14, 2011 at 8:50 AM, Paulo Pinto paulo.jpi...@gmail.com wrote:
I guess that nowadays many AI systems are mainly programmed in
some kind of specialized DSL.
Sure Lisp based languages are a perfect candidate for it, but the
plain
mention of Lisp brings up some issues that you cannot get rid of, like
the parenthesis.
And what, exactly, is wrong with parentheses?
Put another way: the syntax tree of a program will have some sort of
particular structure. To the extent that parentheses DON'T determine
the sub-branches, something else WILL. What do other languages use for
that something else?
* Other delimiters, either characters as in C's { ... } blocks, whole
words as in if ... fi in some shell languages, or other things.
* Significant whitespace, most commonly in languages that use newlines
to delimit statements (BASIC) but sometimes going much further
(Python).
* Syntax rules where the positions of various things among various
keywords determines the structure.
* Precedence rules among math operators.
Drop the first one (Clojure also uses other delimiters) and what we're
left with is, mostly, icky. Significant whitespace means an editor
line-wrapping or, in some cases, even reindenting code might change
its semantics. Syntax rules and precedence rules burden the developer
with remembering them all, and beyond simple and fairly standardized
rules such as * before + precedence rules tend to be avoided by
defensive use of ... parentheses. The one language family with a small
and regular syntax other than Lisp seems to be Smalltalk, and it
avoids the parentheses, with devastating results: 1 + 3 * 4 comes out
as 16 instead of 13. Yikes! They just use strict left to right
evaluation to avoid having complex rules.
To be honest, while I was at the university I always preferred Prolog
to Lisp, due to the close relationship some our professors had with
Edinburgh's university.
This seems to be a total non sequitur, like saying you always
preferred beef to chicken due to the US/Canada border being wiggly
instead of straight east of North Dakota.
In other words: How, exactly, are your former university's professors
and Edinburgh's university causally related to a personal preference
for Prolog? There's no obvious reason why that would be. Does
Edinburgh's university have a strong focus on Prolog for some reason,
which rubbed off via their professors and your university's
professors to you?
I think it is better that the students learn AI than a new programming
language
with forces them to think in a different way. Learning multiple
concepts at
the same time is not easy and you might loose students along the way
because of it.
Who knows, maybe some of those students will eventually find their way
to
Clojure/Lisp.
If they go into AI, it's very likely that will expose them to Lisp at
some point, yes.
I doubt, on the other hand, that Prolog is a very good language to
use, odd though that may seem. The problem is that an AI you try to
develop in Prolog will probably be strongly influenced by the language
choice towards being a theorem-prover type of system with bells on,
and natural intelligence Does Not Work That Way. Natural intelligence
guesses and intuits and invents whole new concepts to create
simplified models that predict its past sense data, and tests them
against future sense data. Self-aware intelligence adds a simplified
model to predict its own past feelings and behaviors (and has
autobiographical memory so these can be past sense data), and tests
them against future sense data (and, potentially, also against
simulations spawned using the world models -- think about that as you
go to sleep tonight). Formal logical reasoning, Prolog style, is
actually something we had to invent, rather than something we had
innately. I doubt we'd be anywhere near as prone to various mistakes
and fallacies in reasoning if we were based on Prolog! On the other
hand we'd probably not be creative.
In simpler language, logic-based AI has been done to death and
doesn't seem to lead to anything fundamentally new in terms of
software capabilities (i.e., closer to what we can do, able to
automate more that we currently have to do ourselves). Of course it
can be done in principle, since Prolog is Turing-complete, but it may
be easier in some other language.
Lisp, of course, isn't just some other language but a kind of
language-mother due to the ease with which it spawns DSLs, so the best
shot probably actually still lies with Lisp. The most advanced AI we
ever made, able to reason in the most humanlike ways and to invent new
concepts, was Eurisko, and that was programmed in Lisp. In fact,
Eurisko was so promising, and we haven't even come close to equaling
that achievement in the many years since, that I still wonder if the
government or aliens (:)) or time travelers (:)) or someone put the
kibosh on that line of research out of fear of Skynet (:)) or
something.
--
Protege: What is this
Re: Stanford AI Class
On Sat, Aug 13, 2011 at 1:36 PM, Lee Spector lspec...@hampshire.edu wrote: As someone who works on code-modifying AI (genetic programming, much along the lines described above -- which, BTW, I would expect Thrun and Norvig to mention only briefly, if at all... but that's a debate for a different forum) I find that languages that make code manipulation simple and elegant do help one to experiment and develop these kinds of AI systems more easily. But this is true whether the manipulated code is compiled and executed in the normal way or treated as a data structure and interpreted in some other way. On the one hand most people who work in genetic programming these days write in non-Lisp languages but evolve Lisp-like programs that are interpreted via simple, specialized interpreters written in those other languages (C, Java, whatever). The ultimate in Greenspunning. :) -- 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: is my understanding correct for function identity?
On Sat, Aug 13, 2011 at 1:57 PM, Thorsten Wilms t...@freenet.de wrote:
On 08/13/2011 06:45 PM, jaime wrote:
Are there other functions for the same purpose?
I don't see how there could be, for the very same purpose. Though you might
want to consider splitting up functions some more, instead.
I think he means other functions whose main use is as arguments to
HOFs, rather than called directly.
In which case the functions returned by constantly form another
family of such. Though we could get rid of that if we added a reader
macro analogous to #(x) but that expanded into (fn [] x) rather than
(fn [] (x)) as #(x) does. Perhaps #[x]? This could replace constantly,
e.g. #[0] == (constantly 0), but also do a few other things, like
#[[%1 (* 2 %2)]] takes two arguments and producing a vector with one
of the arguments and then the other doubled, which saves relative to
#(vector %1 (* 2 %2)) and makes it more visually clear that it outputs
vectors. On the other hand, the same argument can be made against
#[0], that this looks like it ought to return [0] rather than 0 when
called. On the gripping hand, #{} is accepted as indicating sets,
rather than functions that evaluate to maps. :)
--
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: rebind var for all threads
On Fri, Aug 12, 2011 at 12:36 AM, Sean Corfield seancorfi...@gmail.com wrote: On Thu, Aug 11, 2011 at 6:48 PM, Ken Wesson kwess...@gmail.com wrote: Eh. I now can't seem to actually find any recent post mentioning both it and Android. But mentioning it in connection with Google's app store is another matter. There is no Google App Store. There is an Android Market which is where you get mobile apps for Android devices: https://market.android.com/ There is Google Apps which is their web-based email, calendar and documents for teams: http://www.google.com/apps/ Then there's Google App Engine which is their elastic cloud service supporting Python and Java web applications (with some class restrictions): http://www.google.com/enterprise/cloud/appengine/ Hope that helps clarify this thread's subject matter... That is odd. Google is usually much better about clearly naming things, but here they've more or less got things backwards relative to smartphone industry leader Apple. -- 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: rebind var for all threads
On Fri, Aug 12, 2011 at 10:17 AM, Stuart Sierra the.stuart.sie...@gmail.com wrote: Yes. The compiler probably optimized away the var lookup to an embedded constant. You'll need to use an atom, as Baldridge suggested. The Clojure compiler doesn't optimize anything away. However, in a situation like this: (defn foo [x y] ...) (def bar (partial foo 1)) The binding of `foo` is resolved when `bar` is defined, and never again thereafter. Changing the root binding of `foo` in this case would have no effect on `bar`. That is what I meant, and from what I've heard, in 1.3 this behavior extends to defn if the Var isn't defined with :dynamic true, that is, (defn bar [x] (foo x)) will use a baked-in value of foo rather than do a dynamic Var lookup. That's faster, but doesn't allow dynamic binding to work, and presumably not alter-var-root either. -- 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: Stanford AI Class
On Fri, Aug 12, 2011 at 12:41 PM, daly d...@axiom-developer.org wrote: Clojure has immutable data structures. Programs are data structures. Therefore, programs are immutable. So is it possible to create a Clojure program that modifies itself? Yes, if it slaps forms together and then executes (eval `(def ~sym ~form)) or (eval `(defn ~sym ~argvec ~form)) or similarly, or perhaps uses alter-var-root. (May require :dynamic true set for the involved Vars in 1.3 for functions and such to start using the new values right away -- binding definitely does. In 1.2, alter-var-root should just work. Changes occur as with atom's swap!, so the function passed to alter-var-root may potentially execute more than once.) Alternatively, you can create new functions on the fly by evaling fn forms and use atoms or refs to hold stored procedures in Clojure's other concurrency-safe mutability containers. These need to be called by derefing them, e.g. (@some-atom arg1 arg2). The functions will compile to bytecode and be eligible for JIT the same as ones not created dynamically at runtime, though the reference lookups carry a performance hit on invocation. Clojure can probably be quite a good AI research and development platform. -- 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: Stanford AI Class
On Fri, Aug 12, 2011 at 4:25 PM, daly d...@axiom-developer.org wrote: Consing up a new function and using eval is certainly possible but then you are essentially just working with an interpreter on the data. How does function invocation actually work in Clojure? In Common Lisp you fetch the function slot of the symbol and execute it. To modify a function you can (compile (modify-the-source fn)). This will change the function slot of the symbol so it will execute the new version of itself next time. As I indicated in the earlier post, consing up a new function and eval'ing it actually invokes a compiler and generates a dynamic class with bytecode. It's just as eligible for JIT as a class compiled AOT and loaded the usual Java way. As for your later speculations, whether a history of earlier values is kept is entirely* up to the programmer. They can keep older versions around or not. If they stop referencing one, the GC should collect it at some point (modulo some VM options needed to make unreferenced classes collectible). * The STM, as I understand it, may keep a history of the last few values of a particular ref, if that ref keeps getting involved in transaction retries. But this history isn't accessible to user code, at least without doing implementation-dependent things that could break in future Clojure versions. If you store a lot of big things in refs, it could impact memory and GC performance though. -- 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: Stanford AI Class
(defn f [x] (println hello, x)) (defn g [] (eval '(defn f [x] (println goodbye, x (defn -main [] (#'user/f world!) (g) (#'user/f cruel world.)) Close enough? :) -- 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: lein deps gets error
On Fri, Aug 12, 2011 at 6:53 PM, jayvandal s...@ida.net wrote: I do a lein new hello_world and I get a directory called hello_world. I then try lein deps. I get several lines of errors starting with #! What am I doing wrong? = Microsoft Windows [Version 6.0.6002] Copyright (c) 2006 Microsoft Corporation. All rights reserved. C:\cd cl* C:\clojure-1.2.1cd h* C:\clojure-1.2.1\helloworldlein deps C:\clojure-1.2.1\helloworld#!/bin/sh '#!' is not recognized as an internal or external command, operable program or batch file. C:\clojure-1.2.1\helloworldLEIN_VERSION=1.6.1 'LEIN_VERSION' is not recognized as an internal or external command, operable program or batch file. ... Looks like you're trying to run the unix version on windows. -- 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: rebind var for all threads
On Thu, Aug 11, 2011 at 2:05 PM, Mark Rathwell mark.rathw...@gmail.com wrote: (This is all moot at this point, since the author or Noir has made changes that allow it to be compatible with App Engine.) App Engine. Background: This was with noir version 1.1.0, and appengine-magic version 0.4.3. appengine-magic needs a ring handler, which noir provided with noir.server/gen-handler. However, that handler had a bunch of default middlewares added by compojure.handler/site. ... Compojure. App Engine ... Compojure. Wait, what? You are trying to run a WEB SERVER on a PHONE? This really must be the 21st century ... :) -- 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: rebind var for all threads
On Thu, Aug 11, 2011 at 4:45 PM, Alan Malloy a...@malloys.org wrote: Have you even tried a google search for app engine? It's (a) nothing to do with a phone, (b) fairly well known, and (c) easy to discover even if you've never heard of it. Previous discussions of App Engine here have implied it to be associated with the APIs for Android, a phone OS. I have not directly looked into the matter, though, lacking an Android phone as I do or any current interest in developing for the platform. -- 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: Passing ClojureScript objects to JavaScript functions
On Thu, Aug 11, 2011 at 5:02 PM, Kevin Lynagh klyn...@gmail.com wrote: Alright, thanks for the info. Do you know why an automatic solution is out? I'm trying to use D3 from ClojureScript, but right now all of the clarity I get from Clojure's nicer data manipulation abstractions is lost having to convert to/from JS objects everywhere. At the very least there should be nice functions to call to convert back and forth explicitly, if automatic conversion is out and a reader macro will only work for compile time constants. So one could use @@the-structure for constants, and (to-js the-structure) for anything else, or something of the sort. Or is such a function already there, but considered annoying enough to want to be able to hide it in implicit conversions or short, pithy reader macros? Of course, in the latter case, a reader macro that expands to the function call could work on non-constants, though, as @foo already expands to (deref foo) in normal Clojure and does not require foo to be a compile time constant. -- 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: rebind var for all threads
On Thu, Aug 11, 2011 at 5:47 PM, Sean Corfield seancorfi...@gmail.com wrote: On Thu, Aug 11, 2011 at 2:10 PM, Ken Wesson kwess...@gmail.com wrote: Previous discussions of App Engine here have implied it to be associated with the APIs for Android, a phone OS. Now you've made me curious... *which* previous discussions implied that? Eh. I now can't seem to actually find any recent post mentioning both it and Android. But mentioning it in connection with Google's app store is another matter. Is the app store for more than just Android device apps then? -- 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: rebind var for all threads
On Thu, Aug 11, 2011 at 10:02 PM, Mark Rathwell mark.rathw...@gmail.com wrote: Is the app store for more than just Android device apps then? Apple has one central app store for iPhone/iPad apps, and now even has one for Mac apps. Android's situation I haven't exactly figured out, but I think there is a central app store somewhat managed by Google, but Amazon also has an app store for Android, and I don't know if there are others, or if any carriers have their own stores. And meanwhile half these guys are suing the other half for patent infringement. Anyone with a mobile gadget seems to be being sued, be it a Kindle, a phone, a pad ... What a mess. -- 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: rebind var for all threads
On Wed, Aug 10, 2011 at 3:52 PM, Mark Rathwell mark.rathw...@gmail.com wrote: Is what I am trying to do possible? alter-var-root Handle with care. -- 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: rebind var for all threads
On Wed, Aug 10, 2011 at 4:54 PM, Mark Rathwell mark.rathw...@gmail.com wrote: alter-var-root It is still somehow using the original binding. I am trying change the binding from aot compiled code, would that change anything? Yes. The compiler probably optimized away the var lookup to an embedded constant. You'll need to use an atom, as Baldridge suggested. -- 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: rebind var for all threads
On Wed, Aug 10, 2011 at 5:20 PM, Mark Rathwell mark.rathw...@gmail.com wrote: The lib B function uses blacklisted Java classes, ... Blacklisted??? -- 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: Elegant tools deserve elegant solutions. -- L. E. Gant
On Mon, Aug 8, 2011 at 2:46 AM, Tuba Lambanog tuba.lamba...@gmail.com wrote: I’m having a hard time thinking through the process of generating the candidate suffix set using set forms, and I’m beginning to think I have selected an arduous path (for me). Thoughts? Store the prefixes in a patricia tree, and the reversed suffixes in another patricia tree. For suffixes, start at the end of the word and walk backward while traversing the suffix tree until hitting a leaf. Each node traversed (including the root, which is the empty string) is a potential suffix and you traverse them in short-to-long order, so reverse that to get them in long-to-short order. The case for prefixes is analogous except you start at the start of the word and walk forward while traversing the prefix tree. No suffix and No prefix needn't be handled as special cases; they are just the empty string as suffix or prefix, of length zero. -- 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: Elegant tools deserve elegant solutions. -- L. E. Gant
On Mon, Aug 8, 2011 at 11:41 AM, Tuba Lambanog tuba.lamba...@gmail.com wrote: Hi, Thank you for the tip. It does look like the Patricia tree -- or suffix tree -- is made-to-order for this kind of task. I'm reading up on it. You're welcome. Would there be a Clojure implementation of this technology, I wonder. Even if not, it's probably trivial to slap one together, and test it, in less than a day in Clojure. As for generating your candidate seqs of prefixes and suffixes, just cons onto an initial nil in your reduction* and you'll end up with a seq that, traversed forwards, goes from longest candidate to shortest. For suffixes you'll want to (map #(apply str (reverse %)) the-seq), though, to get the suffixes the right way around (since they'll need to be stored reversed in their tree). -- 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: Concurrency design
If the local bindings will never change, then why not just use
(binding [whatever-setup ...] ...) wrapping the individual test bodies
that need such setup? (Where explicit tear-down is required, you'd
need try ... finally as well, or better yet a macro like with-open,
but using binding instead of let, to abstract out the repeated aspects
of such code. Common setups could become more macros, e.g.
(with-foo-whatsit [some-symbol some-other-symbol] ...).)
If the bindings are to stateful stuff that a sequence of tests will
alter, though, you have more problems. Possible improvements:
* Redesign the whole thing to be more functional and less stateful.
* At least, move as much into pure functions as possible; the pure
functions are easy to test.
* The (remaining) sequences of tests on state will have to run
sequentially, so combine them into a single test that calls the
smaller ones.
You'll end up with something like:
(def results (atom {}))
(def tests (atom []))
(def foo nil)
(def bar nil)
(defmacro deftest ... )
(deftest foo nil
[foo (initialize-some-resource)
bar (initialize-another)]
(the test goes here)))
and that produces something like
(do
(defn foo []
(binding [foo (initialize-some-resource)]
(try
(binding [bar (initialize-another)]
(try
(deliver (@results foo) (the test goes here))
(finally (.close bar
(catch Throwable _ (deliver (@results foo) false))
(finally (.close foo)
(swap! results assoc foo (promise))
(swap! tests conj foo))
whereas
(deftest bar foo ...)
is similar, but with foo instead of nil for the second argument the
bar function body gets wrapped in:
(if @(@results foo)
(do
(body that would have been)
(with nil second arg))
(deliver (@results bar) false))
so when bar is run it blocks until foo has run, and short-circuits to
failing if foo failed, but runs if foo succeeded.
And then there'd be
(deftest baz :subtest ...)
which expands without swap!s or a wrapper -- it just becomes a
function like foo and nothing else. A later test body can do setup,
call baz as a function along with several other subtests, and do
teardown, e.g.
(deftest quux ...
...
(and (baz) (baz2) (baz3)))
which, obviously, short-circuits to failure if any of these fails and
otherwise runs them all and returns baz3's result.
Lastly, you'd have
(doall (apply pcalls @tests))
to run the tests and
(report)
after that, with
(defn report
(doseq [[test result] @results]
(println (:name (meta test)) - @result)))
or whatever. If you want more detailed reports, deftest could put
additional stuff into the metadata of the functions (and have
additional arguments, if necessary).
The above framework seems like it would do what you want: allow tests
to have setup and teardown and simplify that, make the stuff thus set
up be dynamic bindings visible to subsidiary functions, allow tests to
depend on earlier tests and block until the earlier tests complete,
and allow a sequence of tests to be run within a single set-up
environment run sequentially, in a single thread, in that environment.
The major downside is that pcalls is optimized for cpu-bound jobs; if
the tests are I/O-bound you'll want to change pcalls to something
based around Executor instead, with a thread pool however large you
want. The other is that tests that must be run in the same
environment, with just one setup before all the tests and one teardown
after, will be a single unit as far as parallelism goes and will stop
on the first failed test. The framework can be modified to let
subtests create separate result entries, though, and using (let [a
(baz) b (baz2) c (baz3)] (and a b c)) will let you run more subtests
even if one fails, when you know the setup environment won't have been
borked by the failures. Also, tests that should get an exception
require you to explicitly catch the exception exception and return
true, e.g. (try (this-should-throw-something) false (catch
FooException _ true)). You could add a bunch of (expect ...) macros to
simplify further the writing of tests.
If you're trying to use an existing testing framework like midje,
though, you're probably SOL unless the framework developer provides
their own parallel testing support or you can understand the framework
code well enough to marry it to something like the above.
--
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
Re: standalone indentation tool
On Sun, Aug 7, 2011 at 1:44 PM, Eric Lavigne lavigne.e...@gmail.com wrote: The pprint function in the Clojure standard library indents Clojure source code. http://richhickey.github.com/clojure/clojure.pprint-api.html To get the result you are looking for, a tool would need to walk through all the *.clj files in your source directory and, for each file, read in the contents and pprint them back into the same file. Bonus points for careful error checking - printing into an intermediate buffer and reading it back in to check that nothing went wrong before overwriting the original file. This would make a good Leiningen plug-in, and doesn't sound too difficult to write. Er, won't you lose all comments and have reader macros expanded if you use read/pprint to do the transformation? -- 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: ClojureScript Compile errors
On Sat, Aug 6, 2011 at 6:42 PM, Mark Engelberg mark.engelb...@gmail.com wrote: On Sat, Aug 6, 2011 at 2:30 PM, Rich Hickey richhic...@gmail.com wrote: Why all the attention to :use - I thought everyone agreed using it is a bad idea? ... The only benefit I see is that you can avoid a (minimum 2 character) prefix. The other benefit is it saves you from the cognitive load of having to know exactly what namespace every given function comes from in order to use it. For some libraries the burden of knowing which namespace a function comes from is significant (e.g., Incanter). Also, those namespace prefixes really get in the way if you are defining a DSL, or redefining things from Clojure's core (e.g., because you want to use an enriched cond macro). In a nutshell, when working within a specific domain, sometimes you want to take a certain set of functions/macros as primitive to your program, and don't want to constantly have to think of the details of how the library that defines them is structured. +1, and the objections raised to :use don't apply if we require that :only go along with it. (:use [x :only foo bar baz]) could with minimal effort, and probably should, be available to make foo, bar, and baz refer to such primitives. -- 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: Looking for a functional solution for a simple problem
On Wed, Aug 3, 2011 at 7:03 AM, Chris Rosengren christopher.roseng...@gmail.com wrote: Hi, I'm using an iterative function to do this now but I would like to start programming in a more functional style I have an ordered (ascending) distinct sequence 1 4 5 34 36 38 53 55 59 62 How would I write a function in a functional style that returns the 1- gaps (integer directly on either side)? For the above sequence it should return (35 37 54) Thanks. (filter identity (map #(if (= (+ 2 %1) %2) (inc %1)) s (rest s))) oughta do it. -- 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: Re: How to import and use an enum enclosed in an java interface?
On Tue, Aug 2, 2011 at 10:42 AM, finbeu info_pe...@t-online.de wrote: Works! Ken, thx. You're welcome. -- 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: java.lang.StackOverflowError when calling function name instead of recur
On Tue, Aug 2, 2011 at 4:47 PM, David Nolen dnolen.li...@gmail.com wrote:
On Tue, Aug 2, 2011 at 4:43 PM, Trastabuga lisper...@gmail.com wrote:
I just came across the issue of getting the StackOverflowError in the
function reading long file and recursively building a list of data.
After I replaced function name with recur the problem went away.
Hence a couple of questions. It's the programmer's responsibility to
put recur instead of function names where tail-recursion is available?
(Kind of obvious, but then why the compiler wouldn't detect it?)
If tail-recursion is not available and function name has to be called,
how do I deal with stack overflow in this case?
Clojure does not have tail call optimization. You must use recur,
trampoline, or redesign your code around lazy sequences.
David
More specifically, you must use recur when your call chain is:
a - a - a ...
You'll need trampoline for more elaborate cases of mutually recursive
functions, like
a - b - c - a
or even
a - b - a - c - d - b - a
(where clearly a at least has conditional branches that can lead to
tail calls to at least either b or c depending).
Lazy sequences provide another way to do this. For example, suppose
you have a set of functions a, b, c ... and a state machine specified
with a map like {\a {\a b \b d \c q ...} \b {\a c \b a \c d ...} ...}
(as might be used if for some reason you wanted your own homegrown
regular expression implementation), you might implement this with
trampoline using
(defn a [in out]
(if in
(let [new-state ((state-map (first in)) \a)]
#(new-state (next in) (conj out whatever)))
(list out)))
...
(defn process [in]
(apply str (first (trampoline a (seq in) []
or something like that. You might also use lazy-seq:
(defn a [in]
(lazy-seq
(if in
(let [new-state ((state-map (first in)) \a)]
(cons whatever (new-state (next in)))
...
(defn process [in] (apply str (a in)))
though you might also use the higher-level reduce:
(def state-to-letter {a \a b \b ...})
(defn a [ch]
whatever)
...
(defn process [in]
(apply str
(second
(reduce
(fn [[[current-state out] ch]
(let [new-state ((state-map ch)
(state-to-letter current-state))]
[new-state (conj out (current-state ch))]))
[a []]
in
or a low-level loop/recur:
(defn process [in]
(loop [in (seq in) out [] current-state a]
(if in
(let [ch (first in)
new-state ((state-map ch)
(state-to-letter current-state))]
(recur (next in) (conj out (current-state ch)) new-state))
(apply str out
(Note: untested, and the whatevers are presumed to depend on the
state and the current input character, in such a way as to be hard to
replace with just a map lookup.)
Note that all of the above find some way to turn a calls b calls a
calls c calls ... into something sequentially calls a, then b on a's
return value, then a on that value, then c on that value ... and thus
avoids deeply nested stack frames.
In the case of trampoline, trampoline has the behavior that if the
function it's passed returns a new function, it calls that (with no
arguments), and repeats until a non-function return value is
generated. (In the state machine this has the awkward effect of
requiring the vector a returns if it's reached the end of in to be
wrapped in a list, since vectors are callable as functions and
trampoline might therefore call it instead of return it.) Since
functions can be selected programmatically in a functional language,
the state machine can be almost directly encoded in functions, or less
directly using a transition map as above.
Lazy-seq is good for cases like the above where each step is appending
to some growing output sequence. Then you just write each step almost
as you would with plain recursion, returning (cons this-steps-result
(next-step args)), but the whole thing is wrapped in (lazy-seq ...).
The seq is finite if and only if at some point one of the steps
returns nil instead of a cons. In this case that happens when the
input is exhausted. The seq generated is (step-1s-result
step-2s-result step-3s-result ...) and since it's lazy steps are only
performed as the consumer needs more items, and are called
sequentially, rather than nesting. (Technically, each step ends up
returning a delay rather than the cons, and the delay gets forced when
the step's output is needed by the consumer, which triggers the next
step, which produces another delay for the consumer to unwrap later;
so each step returns a delay instead of directly calling the next, and
the caller calls the next by forcing the delay, which turns the chain
of tail calls again into iteration.)
Reduce is generally useful for an iteration that accumulates a result,
in this case a vector. Direct use of loop/recur is also useful
sometimes for iteration.
Note that the trampoline, reduce, and loop/recur
Re: What information does (:key x) convey?
On Wed, Aug 3, 2011 at 1:26 PM, Colin Yates colin.ya...@gmail.com wrote: +1 as well. Surely (start-date voyage) would be more explicit than (start voyage) though meaning there is no ambiguity for me; I would have thought start-location. If it's start-date, then the circular? in the OP can only return true for a nontrivial voyage in case of time travel. :) I would (incorrectly) assume (start voyage) was a mutator :) It does kind of sound like one, though I'd think (start! voyage) would be preferable in such a case. -- 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: Best Way To Remove vector from vector of vectors?
On Tue, Aug 2, 2011 at 7:42 AM, octopusgrabbus octopusgrab...@gmail.com wrote: I'm having trouble with the suggested fix (shortened function name for testing). Here is some test data: (def vv1 [[49 48 47 46 nil 1 2 3 4][5 6 7 8 9 10 11 12 13]]) (defn f1 [all-csv-rows] (let [clean-rows (vec (filter #(and (pos? (count %)) (not (cstr/ blank? (nth % 5 nil all-csv-rows) ) ] clean-rows)) This function is returning (f1 vv1) java.lang.RuntimeException: java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.CharSequence (NO_SOURCE_FILE:0) addr-verify= That's because you're checking integers with a blank? function evidently intended for strings. What are you actually wanting to check the integers for? Being zero? There's a function named zero? for that. -- 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: New to Clojure -- Errors Are Frustrating
On Tue, Aug 2, 2011 at 3:11 AM, recurve7 dan.m...@gmail.com wrote:
Here's one example where recursion and lack of positional error
feedback make it hard for me, as someone coming from Java, to spot the
error (and seeing ClassCastException threw me off and had me
wondering where/how I had done something like that):
user= (defn fac [n] (if (= n 1) 1 (* n fac (- n 1
#'user/fac
user= (fac 3)
java.lang.ClassCastException: user$fac cannot be cast to
java.lang.Number (NO_SOURCE_FILE:0)
This is saying that a user$fac was found where a number was
expected. You have a function called fac in the user namespace -- this
is user$fac to Java. So, you probably tried to perform arithmetic on
a function. It's a math function, so you probably meant to call it and
perform arithmetic on the result, and left out a pair of parentheses.
It is true that the messages commonly encountered could stand to be
better documented on a Clojure site. I'm wondering if we could go
further, though, and make REPL exception printing more informative.
The Java exception gets stored in *e, so someone can always type *e to
retrieve it, or (.printStackTrace *e), etc., so printing an
interpretation of the exception wouldn't render the raw exception
inaccessible.
This suggests trying to parse common exceptions into Clojurish
messages; e.g. the above could be found to be a CCE, then the detail
message parsed to extract the classnames; then a message pieced
together based on those, e.g.
java.lang.Number - a number
clojure.lang.Cons/LazySeq/PersistentList/etc. - a list or seq
clojure.lang.Vector - a vector
w.x$y when a function w.x/y exists - the function w.x/y
...
and the shallowest Clojure function before interop can be dug out of
the stack trace, in the above case clojure.core/*, and the above
message could then come out as
Error: expected a number for *, but found the function user/fac instead.
In the case it's a function in the wrong place, the addendum could be generated:
(Perhaps you meant to call the function, but left out a pair of parentheses.)
The lack of line number information for errors in REPL evaluations is
also an issue. I suggest that when a defn is evaluated at the REPL, it
gets metadata like {:file REPL$user$fac :line 1} where the line number
counts from the defn on down. The message printer can parse the file
name from the exception and if it's REPL$anything parse it as
referring to a REPL evaluation and not an actual file, printing
something like line 1 of user/fac in the OP's instance. IDEs can
also possibly have go-to-error pull up the relevant line in the REPL
backbuffer, searching backwards for the most recent evaluation of
(defn fac ...) in user for instance and then finding line 1 of that.
When the error's in a normal source file, of course, existing behavior
is adequate for the most part (though there are sometimes problems
when macros are involved -- particularly, the line number is commonly
the start of the macro body, though not oddly when that macro is
defn).
Clooj would be a good place to experiment with a friendlier REPL error
reporting system.
--
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 import and use an enum enclosed in an java interface?
On Tue, Aug 2, 2011 at 9:37 AM, finbeu info_pe...@t-online.de wrote:
Hello,
how do I have to use an enum in clojure that is enclosed in an java
interface? I decomplied it in IDEA and I got something like that:
package com.api.test;
public interface Foo {
.
.
static final enum BarType {
public static final ONE, public static final TWO, public static
final THREE, public static final FOUR;
}
}
How do I have to import and use that in clojure?
I need to call a java method with such an enum but I can't get it to work
although I have already done lots of guesswork.
(:import (com.api.test Foo Foo.BarType)) ??
(let [ test (.theMethod myObject BlaBlaType.ONE) ])
Try (.theMethod myObject com.api.test.Foo$BarType/ONE) and let me know
how that works.
--
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: Libraries and build management hell
On Mon, Aug 1, 2011 at 3:02 AM, pmbauer paul.michael.ba...@gmail.com wrote: I might be able to disprove your scurrilous charge if ... I doubt that since your earlier assertion was factually incorrect. If you have a personal problem with me, sort it out in private email or keep it to yourself rather than badmouthing me on the list, please. See mvn install:install-file http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html Not relevant. We were discussing use of lein deps. Wrong again. Not at all. We were, indeed, discussing lein deps. -- 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: timed termination of iterative algorithm
On Sun, Jul 31, 2011 at 10:25 AM, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote: Hello everybody, I would like to have a long running process to return its current solution after some pre-determined amount of time. It so happens that the iteration is happening at a deeper nested function. I would like to have a way to return from this nested function when its time ... How can I do this. Currently I am considering using the throw catch mechanism to do the job. Is there a better way of doing things like this .. . I basically would like to have a non-local return .. something like the common-lisps return-from .. I found return-from equivalent in clojure.. I was hoping there is a nicer way to deal with this when the function calls are quiet deeply nested.. Probably the least messy way to deal with it is to sprinkle (Thread/sleep 0)s through the innermost loops of the algorithm, one in each, and the outermost loop that refines the in-progress result has a try ... catch for InterruptedException that handles it by returning the current approximation. Then have a separate threat that calls interrupt on the calculational thread on a timer, or if a user clicks a Cancel button on a progress dialog, or whatever. This is more or less what InterruptedException is for; and breaking out of an algorithm in an unusual way is the kind of job for which exceptions are well suited, as well as returning from fairly deep up to a specific handler. -- 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: novel feedback is always welcome
On Sun, Jul 31, 2011 at 10:27 AM, Stuart Halloway stuart.hallo...@gmail.com wrote: In principle the line is clear. Everything is fair game. Novel feedback is always welcome. Question small decisions, question big ones. Press hard for quality. The opposite of providing novel feedback is recovering old ground. This takes two (often overlapping) forms: (1) Pushing an agenda when you aren't up to speed enough to be in the conversation. (2) Pushing an agenda when project leadership has said, I understand your feedback and disagree. This is not the direction we plan to pursue. I'd say there's also (3) Covering old ground you didn't know had been discussed before. Though you might lump that into 1; but there's a difference between not up to speed and should know it and not up to speed with no way of knowing it. (3) is most likely coming from a newbie. Another source of (3) would be if the previous discussions all took place elsewhere, such as IRC or the dev list, that the user hasn't been monitoring. You seem to feel that major, already-made design decisions that would require a fork and massive effort to do differently lie on the shalt not question side. What about more minor choices -- for example, which of the three kinds of primitive math overflow behaviors, throwing, auto-promoting, or wrap-around, should be the default? Ken, you are beating a dead horse on 1.3 numerics. No, I was just bringing it up as an example to illustrate something else. But now that you bring it up ... In particular: (1) You think that the overflow defaulting choice is minor, and I think it is fundamental. Actually, what I think is that the default (once you have a BigInt that is about as fast as a boxed Long when the numbers are small) should be to use BigInt except when primitives are specified, and to use checked primitive math then, with unchecked as an option. This would be most compatible with 1.2's numerics behavior, and still provide all 3 options for arithmetic handling. (I also have concerns about the *unchecked-math* flag I heard about somewhere. We can't have +, etc. testing some flag at runtime -- much less fetching a dynamic Var, which is a slow, slow ThreadLocal object at the JVM level -- before each add without losing performance badly. We really need an (unchecked-math (the-math-goes-here)) macro, or something, that affects what functions get used at *compile time* rather than a dynamic Var flag that is set before performing what you hope to be really fast math.) (2) You were unaware of the platform issues in Java that drove us to implement our own BigInt. That arose in connection with a problem with format, not a gripe with arithmetic. That said, Ken's questions on numerics are not unwelcome. It is not realistic for every comer to the mailing list to have encyclopedic knowledge about what has gone before. That would be my category (3) above. :) So nobody should bite anyone's head off for asking a question that has been answered before (particularly if e.g. it is hiding in a deep, convoluted thread and isn't search friendly). Which, unfortunately, is exactly what happened to me with the numerics thing a while back. :P -- 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: timed termination of iterative algorithm
On Sun, Jul 31, 2011 at 12:41 PM, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote: Hi Ken, thank you for your response. Do you think you can give me a quick example of how to extend an Exception to be able to extract the value from the exception when it is caught.. Should I be using gen-class for this? (seems quiet messy to me)... do you have a better suggestion.. Oh, I wasn't suggesting putting the data in the exception. From the sounds of it you have something like (defn outer-loop [...] (loop [x initial-value ...] (recur (compute-new-x x ...) ...))) (defn compute-new-x [x ...] (... (further-computational-steps y ...) ...)) (defn further-computational-steps ...) ... (defn deeply-nested-loop [q z foo] (loop [...] ...)) What I was suggesting was putting some quick thing in deeply-nested-loop that will yield a timeslice and throw InterruptedException if the thread's been interrupted, and in outer-loop catch InterruptedException and handle it by returning the current value of x: (defn outer-loop [...] (loop [x initial-value ...] (let [[new-x ... interrupted?] (try [(compute-new-x x ...) ... false] (catch InterruptedException _ [nil nil nil ... true])] (if interrupted? x (recur new-x ...) -- 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: timed termination of iterative algorithm
Another, perhaps cleaner method leverages more of Java's and Clojure's concurrency tools. (def res (atom nil)) (defn outer-loop [...] (loop [x initial-value ...] (reset! res x) (recur (compute-new-x x ...) ...))) ... (defn do-it [timeout ...] (let [f (future (outer-loop ...))] (try (.get ^java.util.concurrent.Future f timeout java.util.concurrent.TimeUnit/MILLISECONDS) (catch Exception _ (future-cancel f) @res The do-it function returns in at most timeout milliseconds. It returns the most recently generated value of res. If the timeout is reached, the get method of Future throws an exception, which gets caught, and the future-cancel method is called on f to interrupt the actual computation. That will still need to be interruptible though or it will run to completion anyway, using CPU to generate a maximally refined result nobody will ever see. Or worse it may run forever. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Libraries and build management hell
On Sun, Jul 31, 2011 at 9:43 PM, yair yair@gmail.com wrote: On Jul 31, 12:28 pm, Ken Wesson kwess...@gmail.com wrote: Almost being the operative word. One distinct disadvantage is that it makes building your project require a working network connection snip This is not correct. Once the jar has been downloaded after being included in the dependencies, it stays in your local repository and no network connection is required. If you add a new dependency, the network connection is needed. And someone posted something recently about it balking if it's unable to check for updated versions of some things. -- 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: Libraries and build management hell
On Sun, Jul 31, 2011 at 11:57 PM, Sean Corfield seancorfi...@gmail.com wrote: On Sun, Jul 31, 2011 at 7:49 PM, Ken Wesson kwess...@gmail.com wrote: If you add a new dependency, the network connection is needed. If you add a new dependency and you don't already have the JAR downloaded, you need a network connection one way or another to go get that JAR, yes? What if you have the JAR on a disk somewhere, for other reasons, but until now it wasn't a dependency of that particular project? -- 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: Libraries and build management hell
On Mon, Aug 1, 2011 at 12:49 AM, pmbauer paul.michael.ba...@gmail.com wrote: What if you have the JAR on a disk somewhere, for other reasons, but until now it wasn't a dependency of that particular project? Your assertion that dependency management systems are in any way disadvantaged to manual dependency management in terms of SPOF or requiring a network connection is merely incorrect. I might be able to disprove your scurrilous charge if I knew what the heck you meant by SPOF. See mvn install:install-file http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html Not relevant. We were discussing use of lein deps. -- 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: Possible Issue with Listing 11.5 from the Joy of Clojure
On Sat, Jul 30, 2011 at 12:10 AM, Julien Chastang julien.c.chast...@gmail.com wrote: By the way, I still think you need a lock in the count function in the case where the caller tries to invoke the count function on a partially constructed object. I don't think that's possible in this case. As far as code running on the JVM is concerned, either the array does not exist or it does and already has its length field set correctly; you can't be holding a reference to a Java array that is partially constructed in such a manner as to allow data races with the length field. And I don't think Clojure allows holding a reference to a partially constructed type/record either, as you can't put custom code into the constructor that (MyRecord. x y z) calls, just call it and get back a reference to a fully constructed MyRecord. The code above uses reify and actually creates the array *before* calling reify, so I don't think we need to worry about calling count with a somehow still being null, either. -- 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: dynamically generated let bindings
On Sat, Jul 30, 2011 at 7:29 AM, Sam Aaron samaa...@gmail.com wrote: (fn [ args] (let [foo (some logic goes here) bar (some logic goes here) ...] (body goes here))) I just finished implementing a solution and it looks exactly like this. You're absolutely right - this is precisely the pattern I was looking for. What I didn't do, and I think the biggest lesson I've learned from these early macro-fighting days, is to do exactly what you propose: sketch out what the macro should expand to *before* working on the macro itself. That's generally good advice when macro-writing. Thanks everyone once again, You're welcome. -- 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: dynamically generated let bindings
On Sat, Jul 30, 2011 at 9:07 PM, Alan Malloy a...@malloys.org wrote:
(get :foo argmap__5673__auto 42) is the right way to solve this
problem.
Is another way to solve it, yes, and a good one.
Or if, as in the current example, you want to destructure a map with
lots of defaults, simply:
(let [{:keys [foo bar] :or {foo 42}} (parse-whatever)]
...body...)
Or
(let [{:keys [foo bar]} (merge {:foo 42} (parse-whatever))]
...body...)
The defaults map can be a literal emitted by the macro and must be on
the left of the map-returning (parse-whatever) call.
--
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: Libraries and build management hell
On Sat, Jul 30, 2011 at 10:58 AM, Mark Rathwell mark.rathw...@gmail.com wrote: I'm all for a better, easier solution that is better in most ways. What I'm saying is: 1. I don't want to go back to downloading jar files from the websites of all of the libraries I want to use in a project and tracking different versions, no matter how large or small the project is, as suggested in your OP. I think the centralized lein/clojars/github is an improvement over that in almost every way. Almost being the operative word. One distinct disadvantage is that it makes building your project require a working network connection and depends on single points of failure in Clojars and Github. So, network or site outages can delay your own work. Also, development under this model would be difficult on a mobile platform (such as a netbook) whose internet connection is flaky (e.g., up only when there is a free WiFi hotspot within range) or expensive enough to turn off most of the time (cellular data networks). (And both WiFi and cellular are subject to flaky signal strength depending on local conditions, too.) I really think incremental improvements to lein/cake/etc, over time, will yield better results than going back to square one. This is probably true, even given the above issues that can arise with a build process that presumes reliable 24/7 network connectivity. -- 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: Alright, fess up, who's unhappy with clojurescript?
On Sat, Jul 30, 2011 at 10:22 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: I would add that I want to see Rich maintain is grip on the Clojure wheel for a very long time. Consensual decisions are most of the time not the best. They are the result of compromises not based on technical arguments but on people's feelings or political issues. And the result of them tends most often to be something like Java at best, and often closer to C++. Stop hammering on him and if you are not happy with Clojure, find another language that matches your aspirations. They are plenty out there. There is something of an issue here, though: where, exactly, should the line be drawn between thou shalt not question this on the mailing list! and fair game for discussion, presuming as you do that it isn't everything is fair game for discussion if it's not entirely unrelated to Clojure. You seem to feel that major, already-made design decisions that would require a fork and massive effort to do differently lie on the shalt not question side. What about more minor choices -- for example, which of the three kinds of primitive math overflow behaviors, throwing, auto-promoting, or wrap-around, should be the default? I assume not-yet-made choices and easily-tweaked, recentish (still in alpha or beta) things that won't break a lot of existing code fall under fair game. Also, what should the policy be for responding if someone questions a shalt not question anyway? Currently, there's an unfortunate tendency to assume the worst motives and to employ namecalling, particularly the word troll, against possibly-well-intentioned transgressors. I'd suggest that such threads should get a single response, saying that decision's already been made; if you want to make your own fork that does it differently go ahead, and if you want to discuss it there's the clojure-misc google group, but please don't clutter *this* group with it, and otherwise the post should be ignored. Followups by the OP should be ignored. Oh, and there should probably be a pointer to a FAQ of some sort in that initial response answering any likely but why? type questions the OP might have, including what other topics will bring this kind of response?. -- 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: dynamically generated let bindings
On Fri, Jul 29, 2011 at 12:49 AM, Jeff Rose ros...@gmail.com wrote: I don't think it's very typical to pass a form to a function, unless you plan on using eval at runtime. Or it's a function called by a macro to do some processing of forms. -- 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: format and printf can't be used with BigInt
On Fri, Jul 29, 2011 at 1:52 AM, Meikel Brandmeyer (kotarak) m...@kotka.de wrote: Hi, Am Freitag, 29. Juli 2011 01:28:27 UTC+2 schrieb Sean Corfield: Kinda hard since that expression is not valid in 1.3 anyway: ArithmeticException integer overflow clojure.lang.Numbers.throwIntOverflow (Numbers.java:1374) So that code breaks explicitly in 1.3 and in many ways (format) is then the least of your worries... I think this is one of the misunderstandings or points of disagreements (or whatever you want to name it) in this whole discussion: this code is *not* broken. And the expression is also perfectly valid. The function call just throws an exception. This can be handled. Or you use *' which won't overflow but give a BigInt in that case. So you are in full control of what your program does. Nothing is broken here. One just hast to pay the price for special handling. The JVM doesn't allow fast and non-overflow in the same operation. Clojure chose to go the fast route with primitive math. And consequently non-overflow became special handling. So where is the issue? Er, fast would be for primitive integer arithmetic to wrap rather than throw an exception or auto-promote. Both of the latter behaviors require every math op to be accompanied by a test of some sort and a branch (to either the exception-throwing code or the BigInt constructing code). -- 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
Are they scared of us yet?
They've just added with-open to JavaSE: http://download.oracle.com/javase/7/docs/technotes/guides/language/try-with-resources.html -- 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: format and printf can't be used with BigInt
On Fri, Jul 29, 2011 at 2:36 AM, Meikel Brandmeyer (kotarak) m...@kotka.de wrote: Hi, Am Freitag, 29. Juli 2011 08:24:54 UTC+2 schrieb Ken Wesson: Er, fast would be for primitive integer arithmetic to wrap rather than throw an exception or auto-promote. Both of the latter behaviors require every math op to be accompanied by a test of some sort and a branch (to either the exception-throwing code or the BigInt constructing code). The exception throwing check is much faster than boxing each and every number (Java can only do primitive return or Object, so you have to box everything on return.) If you want really fast, there is the unchecked-math flag or the unchecked-* operations. You have really fast, unsafe - fast, safe - slow, safe. Clojure chose the middle path. No one prevents you from deviating to the left or the right via unchecked-* or *'. Yes. I felt the other post may have been unintentionally misleading, by implying that checking and maybe throwing an exception was the fastest path. -- 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: Are they scared of us yet?
On Fri, Jul 29, 2011 at 2:48 AM, Laurent PETIT laurent.pe...@gmail.com wrote: So they decided to go the route of adding a .getSuppressed() (Exceptions) method in Throwable, thus behaving differently from other finally clauses ... ... so now we have a (with-open) whose semantics are not aligned with those semantics of Java 7' try-with-resources statement, wrt exception shadowing from the finally block ... :-/ Easily fixed. We already wrap everything in RuntimeException, right? And it's already been suggested elsewhere that we should probably use a specialized subclass, say ClojureRuntimeException. So, just implement ClojureRuntimeException, add some fields and getShadowed and appendShadowed methods to this, and redefine with-open so that it catches any exception, stuffs it into a ClojureRuntimeException as the cause exception if it's not already a ClojureRuntimeException, and now it's holding a ClojureRuntimeException, closes open resources and appends any thrown exceptions to the ClojureRuntimeException's shadowed list. Then throws that. For one resource, something like this should be emitted: (let [x the-resource] (try ... body that works with x ... (catch Throwable t (let [t (if (instance? ClojureRuntimeException t) t (ClojureRuntimeException. (.getMessage t) t))] (try (.close x) (catch Throwable tt (.appendShadowed t tt))) (throw t (.close x)) There's a couple of tiny leaks (.getMessage could throw something, and (ClojureRuntimeException. ...) could throw OOME, plus the infinitesimal chance of a random VMError cropping up) but it looks solid enough for production use and gives Java 7ish semantics. The exception wrapping code elsewhere can do something similar in terms of wrapping in ClojureRuntimeException and only if it's not already wrapped. It'd be nice to be able to differentiate wrapped exceptions from natural RuntimeExceptions, and not to have the same one get rewrapped umpteen times so that you have a cause chain of half a dozen RuntimeExceptions before the cause exception. Then we can also have (defn unwrap [x] (if (instance? ClojureRuntimeException x) (recur (.getCause x)) x)) and it will unwrap all Clojure's wrapping, and stop right there even if the exception originally caught and wrapped inside Clojure already had a cause exception. -- 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: dynamically generated let bindings
On Fri, Jul 29, 2011 at 6:57 AM, Sam Aaron samaa...@gmail.com wrote: However, something like the following doesn't work: (defn binding-vec [foos] `(vec (interleave ~names ~(take (count names) (repeat '`(count ~foos)) A, because the above code is probably incorrect (I just cobbled it together for the example) and more importantly: B, because the code doesn't return a vec, it returns code that returns a vec. I really seem to be getting my brain in a knot over this. :-( Any illumination would be really appreciated Why not just (vec (interleave names (take (count names) (repeat `(count ~foos)? Of course I assume you eventually want something more complex than just (count foos) as the value for every variable, or why have more than one variable? -- 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: Question regarding structural sharing, records, and maps
On Thu, Jul 28, 2011 at 11:59 PM, Trenton Strong trenton.str...@gmail.com wrote: 1.) Does structural sharing play well with nested structures? With a tree whose nodes are represented by nested maps, if a leaf node is updated with new data, will structural sharing efficiently represent the new version of the tree as all the rest of the tree + modified node? Yes. In fact this should work with records, too -- all the native fields of the record need to be copied for each version, but most will typically be pointers and most of those will typically be to existing objects. Only the ones that were changed will point to new nested objects. So unless your records have huge numbers of predefined fields there shouldn't be much time or memory cost in copying them. 3.) Are there alternatives to a single ref around the root node of the tree that are worth exploring? Probably. Any two changes to the tree will cause one to retry in the single-ref case, unless you're sure all the changes will commute. (Changes to distinct fields where one change doesn't depend on what the other changes will commute, and changes to the same field that don't matter as to sequencing, such as inc and dec, will commute, but otherwise no.) You will probably want something structured more like a database, with tables that are maps and rows that are records or more complex, nested structures, such that most concurrent changes will not affect a common row. The tables can then be refs of maps of refs, with most changes operating on the row-refs. The table refs only need to change if rows are inserted or deleted; those could be bottlenecks, though if all objects have GUIDs as keys in these tables then row insertions and deletions will commute, leaving only the GUID generators for each table. Unfortunately, (let [new-id (commute table-x-guid-counter inc)]) sounds nice but might result in new-id taking on the same value in two concurrent transactions, so you'll need to use alter and GUID generation may be a bottleneck. But it may be much faster than your other, more complex transactions. Be sure to do it separately, e.g.: (let [new-id (dosync (alter table-x-guid-counter inc))] (dosync (commute table-x assoc new-id some-thingy))) You can even use atoms for the guid counters instead of refs, and then the ! in swap! will remind you to get the ID before entering a transaction. Do as much of what's needed to generate some-thingy before the transaction, too -- though if it depends on other refs' values, and those values should be current rather than it being acceptable for them to be values that were there recently but might have changed, then some of the work will need to be done in the transaction. I've considered wrapping each node in a ref and performing updates that way, or possibly taking the async route and dispatching cals using agents, but my experience there is nil. Any insight there? I'd avoid having refs nesting more than two deep. Complex arrangements of cross-references among nodes can create a giant headache in combination with refs and transactions, so using a database approach with table maps, ID token keys, and cross-references to ID tokens rather than objects is often sensible. In particular, complex objects with nested refs effectively have mutable state inside them, which is usually not desired in Clojure. (One can argue, though, that the ref object is not different in principle from the ID token and removes a layer of indirection, and possibly obviates the need to generate IDs from counters that act as bottlenecks -- though, really, the Java new operator's allocation of memory now takes the role of ID generator. I'm given to understand modern VMs do some clever things to make new able to be fairly concurrent, though, such as giving each thread its own subset of the eden generation to allocate in.) -- 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
