Re: unexpected behavior catching exceptions within a go block
On Monday, October 27, 2014 9:25:30 PM UTC-6, Wei Hsu wrote: > > This gist illustrates a problem I'm having where the channel is closed > after running into an exception, even if I put a try/catch block around the > block that generates the exception: > > https://gist.github.com/yayitswei/d80d51ee29dc5e2c1117 > > How do you handle exceptions when processing items asynchronously from a > queue? > Failing preconditions throw AssertionError, which is not a subclass of Exception. That is why it's not being caught. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Large File Processing] What am I doing wrong?
On Monday, January 20, 2014 11:55:00 PM UTC-7, Jarrod Swart wrote:
>
> I'm processing a large csv with Clojure, honestly not even that big (~18k
> rows, 11mb). I have a list of exported data from a client and I am
> de-duplicating URLs within the list. My final output is a series of
> vectors: [url url-hash].
>
> The odd thing is how slow it seems to be going. I have tried implementing
> this as a reduce, and finally I thought to speed things up I might try a
> "with-open and a loop-recur". It doesn't seem to have done much in my
> case. I know I am doing something wrong I'm just not sure what yet. The
> best I can do is about 4 seconds, which may only seem slow because I
> implemented it in python first and it takes a half second to finish. Still
> this is one of the smaller files I will likely deal with so I'm worried
> that as the files grow it may get too slow.
>
> The code is here on ref-heap for easy viewing:
> https://www.refheap.com/26098
>
> Any advice is appreciated.
>
This part: (some #{hashed} already-seen) is doing a linear lookup in
`already-seen`. Try (contains? already-seen hashed) instead.
- Chris
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Job Spam] Write Clojure at Rally Software in Boulder, Colorado
Rally Software is hiring. Rally is a SAAS provider of web-based agile project-management software. Over the past couple of years, we have been writing many of our back-end services in Clojure. You should come and work here. The team I work on does infrastructure projects, dealing with things like authentication, data storage, and real-time messaging. We spend our days pairing in Emacs (sometimes remotely via tmux), solving real-world problems (like performance, scalability, and security), discussing and designing solutions, and occasionally watching clips from bad 80's movies on the projector. There are six developers on our team now, but we have more work than we can handle - that's why we need you. We are looking for experienced polygot developers. Beyond that, I won't waste your time with a laundry-list of technical requirements. As always, a link you your github can help a lot (but is not required). Rally is hiring in several locations (see the link, below), but working on an all-Clojure team currently requires relocating to beautiful Boulder Colorado, which is a great city and is no longer under water, I swear. Here is an official link - it doesn't mention Clojure yet, but does a good job of selling you on the many benefits of working here: https://www.rallydev.com/careers/open-positions Feel free to email me off-list with questions, or send me your resume and I'll get it into the right hands. - Chris Perkins -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: much lower recursion depth with memoization
On Sunday, September 22, 2013 5:28:37 PM UTC-6, John Lawrence Aspden wrote: > > This recursion limit really is quite nasty. I could probably live with > 4000, but 200? And why would memoization make it worse anyway? > > > The factor of 20-or-so smaller recursion limit comes not from memoize directly, but from apply, which appears to use a relatively enormous amount of stack space. I suspect that since AFn.applyToHelper dispatches on up to 20 arguments, that stack space for all 20 is always used, even if you only pass, say, one argument. - Chris Perkins -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: XML namespace parsing - any movement?
On Wednesday, September 18, 2013 6:35:40 PM UTC-6, Korny wrote: > > So, the background - there is a page about fuller xml support at > http://dev.clojure.org/display/DXML/Fuller+XML+support - > > Currently none of the xml parsing options support this - the best I've > found is https://github.com/grammati/eksemel but it hasn't been touched > in 2 years, and the last commit mentioned "embarrassingly slow" :) > > I am the author of eksemel, and you're right that I no longer work on it (I no longer use XML much, if at all). I don't recall exactly how slow it was - I think my performance measurements were pretty superficial. Probably the biggest problem with it at the moment is that it eagerly instantiates whole documents in memory, rather than lazily like data.xml, so is unusable for very large documents. I do have a CA on file, so if you feel inclined to extract any of the code into a patch for data.xml, you are certainly welcome to do so. Having put in the work, I would love to see this code get into a state where it could actually be useful to someone. Unfortunately, I don't anticipate having much time to do so myself in the near future. - Chris Perkins -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: why can I re-use local variables if Clojure is immutable?
On Tuesday, April 2, 2013 1:09:25 PM UTC-6, larry google groups wrote: > > > If Clojure is suppose to emphasize immutability, why can I do this: > > kiosks-clojure.core=> (let [ > #_=> mega (+ 1 1) > #_=> mega (+ 1 mega) > #_=> mega (+ 1 mega) > #_=> mega (+ 1 mega) > #_=> mega (+ 1 mega)] > #_=> mega) > 6 > > I might as well be writing PHP code. > > Does anyone actually write Clojure code like this, or is it considered bad > form? > > It's perfectly fine. In fact, I would argue that it's bad form to invent new local names when you don't need them. As others have said, there is nothing mutable happening here. Rebinding a local shadows the previous local of the same name, but does not change it in-place, as many other languages do. I realize that seems like a hand-wavy distinction, but it has practical consequences. See here for an example: http://chrisperkins.blogspot.com/2011/04/clojure-does-not-have-variables.html -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: seeking namespace-aware xml lib
On Monday, July 16, 2012 3:53:21 PM UTC-4, bsmith.occs wrote: > > TL;DR: I'm looking for a Clojure library that round trips XML+namespaces > through Clojure data structures and back again. > > I began an effort to solve this problem quite some time ago; it is here: https://github.com/grammati/eksemel It is based on the design outlined here: http://dev.clojure.org/display/DXML/Fuller+XML+support I haven't touched it in a long time, but I do intend to work on it again on that mythical future date known as "some day". The biggest drawback, I think, is that it is not lazy like data.xml, so can run out of memory parsing large documents. Also, I did some perf testing and found it to be quite slow, but I never found time to investigate why. I hope it's useful to you. - Chris Perkins -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Memory issues processing large lazy sequences
On Thursday, June 7, 2012 1:53:30 PM UTC-4, Tom Hume wrote: > > Hi > > I'm trying to generate a sequence which corresponds to a breadth-first > search of a very wide, deep tree... and I'm hitting memory problems when I > go too far along the sequence. Having asked around on the IRC channel and > looked here, the number 1 cause of such problems is inadvertently holding > onto the head; but I can't see where I'm doing this. > > (dorun (take 2000 (add-layer))) > take holds on to the head, because that is what it returns. Try changing take to drop. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Parallel doseq?
On Thursday, May 24, 2012 3:17:56 AM UTC-4, Cedric Greevey wrote: > > On Thu, May 24, 2012 at 3:00 AM, Sean Corfield wrote: > > On Wed, May 23, 2012 at 11:37 PM, Cedric Greevey wrote: > >> Replacing (range 10) with (take 10 (iterate inc 0)) didn't change > >> anything. It's still not parallelizing. > > > > My point was that when you replace (range 10) with (range 100) in your > > code, it prints numbers up to 31 and no more. You didn't try that, I > > presume? > > Sounds like pmap is *really* broken. (doall (pmap identity x)) should > realize every element of x, surely, just like (doall x)? > > Unfortunately (pmap identity ...) won't do what you want. The only computation that will be parallelized is the call to identity. To pmap, the for-expression is a black box - just a seq - it cannot reach into it and parallelize its insides. It can only consume it sequentially. The meat of pmap is this: (map #(future (f %)) coll) That must produce each element of coll (in this case, the for-loop), in order, *before* passing it to future. Also, pmap is not broken; the problem with the code you pasted is simply an errant closing paren. You had (do (doall (pmap ...) nil)), where you meant (do (doall (pmap ...)) nil). Apparently doall has a two-arg version, which is news to me :) - Chris Perkins -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Pulling constants out of interfaces
On Monday, April 30, 2012 12:19:00 PM UTC-4, Philip Potter wrote: > > Note that, even though this works, $ is not a valid character in a > clojure symbol. > > See > http://groups.google.com/group/clojure/browse_thread/thread/5af5d892f2e84212/0c5dc6b6a1578f07?#0c5dc6b6a1578f07 > > > and http://clojure.org/reader > > So: is the behaviour discussed intentional? If so, should $ be made > explicitly valid in symbols? > > I wouldn't put too much stock in what it says at clojure.org/reader - it hasn't been updated in a long time. The implementation is probably a more definitive definition of what characters are allowed. Consider, for example, that according to that page, ">" is not a legal character, but the threading macros, -> and ->> have been in core for ages. I doubt that those are suddenly going to be removed one day when Rich notices that they are illegal :) - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Getting started with lein-cljsbuild
On Thursday, April 19, 2012 3:03:53 AM UTC-4, Evan Mezeske wrote: > > That's great news that you got it to work. I can't make any sense of the > stack trace you're seeing with "lein deps", though, unfortunately. > > Other than installation, does the plugin seem to work (e.g. "lein > cljsbuild once", etc)? I haven't tested it under Windows myself, and > people have had trouble with it in the past (albeit with older versions of > the plugin). > >> >> On Windows, "Could not find the main class: and." invariably means that a classpath was not quoted somewhere - the "and" being from "Documents and Settings". eg: java -cp C:\Documents and Settings\username\.lein\plugins... etc - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: newline question
http://stackoverflow.com/questions/8707679/how-to-get-suppress-m-characters-in-my-clojurebox-emacsw32-repl-connected-to -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Creating parsers in clojure
There is an example of parser for a very small subset of SQL in one of the unit tests for imparsonate, here: https://github.com/grammati/imparsonate/blob/master/test/imparsonate/test/core.clj - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 parser generator library
Here is one I wrote a while ago. https://github.com/grammati/imparsonate It's not "finished" (is open-source software ever really finished?), so I don't know whether it will do what need it to. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 def, vars, and binding
You should be calling Thread.start in the clojure version, not Thread.run. Your set-timeout is just blocking for a while and then running the passed-in function on the caller's thread. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Implementing an interface with core/proxy results in UnsupportedOperationException
You may want to dig a little deeper into why reify was not working for you. As far as I can tell, the classes created by reify do have a public, no-arg constructor, as you require: user> (-> (reify Runnable (run [_])) type .getConstructors seq) (# #) - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Pretty-print with metadata
Good catch! I was about to add this to my personal toolkit of "generally useful random crap" (every programmer has one of those, right?). I'll make sure to cover that edge-case. Thanks. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Pretty-print with metadata
By looking at pprint.clj, I have come up with something that seems to work.
No "hacking" is necessary - the code in pprint is impressively clear and
extensible. It's obviously designed to allow exactly this sort of
extension to the printing mechanism.
user> (defn ppm [obj]
(let [orig-dispatch pprint/*print-pprint-dispatch*]
(pprint/with-pprint-dispatch
(fn [o]
(when (meta o)
(print "^")
(orig-dispatch (meta o))
(pprint/pprint-newline :fill))
(orig-dispatch o))
(pprint obj
#'user/ppm
user> (ppm elt)
^{:xmlns {"a" "http://aaa/"}, :xmlns-decls {"a" "http://aaa/"}}
{:tag :foo,
:attrs {},
:content
[^{:prefix "a", :xmlns {"a" "http://aaa/"}}
{:tag :bar, :attrs {}, :content [], :uri "http://aaa/"}
^{:xmlns {"a" "http://aaa/"}}
{:tag :blah,
:attrs {^{:prefix "a"}[:x "http://aaa/";] "y"},
:content [],
:uri nil}],
:uri nil}
nil
user>
Works great! Tom F. is officially my clojure-hero-of-the-day.
thanks,
- Chris
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Pretty-print with metadata
Thanks Meikel. So I guess from your reply that there is no built-in way to do this, right? The objects I'm trying to inspect can be deeply nested maps and vectors, and I want to see all the metadata - not just on the root object. I guess I would have to either re-implement some of the logic of pprint, or hack pprint itself to respect *print-meta*. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Pretty-print with metadata
Is there a way to pretty-print an object with its metadata? If I (set! *print-meta* true) at the REPL, I can see the metadata. If I use (pprint thing), I can see the structure much more easily. How can I do both? - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Proxies and overriding protected methods
On Monday, January 16, 2012 6:12:34 AM UTC-5, Chris Perkins wrote: > > Norman, > > Finalize is a protected method, so you can't call it. You get the same > error trying to call finalize on anything - it has nothing to do with proxy. > > user> (.finalize (Object.)) > No matching field found: finalize for class java.lang.Object > > - Chris > Oops, ignore that - haven't had my morning coffee yet :) I see that you are trying to make finalize accessible by overriding it. Agreed that it seems like it should work. Assuming that proxy can successfully override other protected methods, you should probably log a bug. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Proxies and overriding protected methods
Norman, Finalize is a protected method, so you can't call it. You get the same error trying to call finalize on anything - it has nothing to do with proxy. user> (.finalize (Object.)) No matching field found: finalize for class java.lang.Object - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: delayed recursive macro expansion?
You should be able to just change your macro to a function, remove the backtick, and change (try ~expr ...) to (try (eval expr) ...). - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 attach debugger on clojure's repl ?
On Saturday, December 3, 2011 9:50:21 AM UTC-5, Sam Aaron wrote: > > > I never did manage to get ritz working. I believe the issue was with ritz > <-> cake (I still use cake for Overtone hacking). However, now that cake > and lein are going to be united, we can just focus on lein support for the > future. > > Alternatively, George Jahad has updated CDT (The Clojure Debugging > Toolkit) to work with Clojure 1.3 which I'm testing out at the moment. He > gave me a demo at the conj and it was insanely cool and worked perfectly. > Yeah, I just got CDT working this morning too, but I wanted to try ritz as well to compare/contrast. Does anyone know what the key differences are? Do cdt and ritz do more-or-less the same things? - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 attach debugger on clojure's repl ?
On Friday, September 23, 2011 8:00:36 AM UTC-4, Sam Aaron wrote: > > > > > I'd be very happy to write up a "Getting Started" tutorial on the ritz > wiki if I can get things working. > > Sam > (two months later) Not to publicly shame you or anything, Sam, but... how's that tutorial coming along? :))) Seriously - did you ever manage to get ritz working? I would like to try it, but I really need a "for dummies" guide. I think I have followed the instructions to the letter, but when I run lein ritz I see this: % lein ritz Listening for transport dt_socket at address: 37460 user=> Swank server listening on local port 4005 Note the user=> prompt - I don't think that should be there. Then, when I run "slime-connect" (which I assume is the missing step in the ritz readme between "lein ritz" and "set a breakpoint"), I see: Versions differ: 2010-11-13 (slime) vs. 20101113 (swank). Continue? Simultaneously, another prompt appears over in the terminal (not in emacs): Listening for transport dt_socket at address: 37460 user=> Swank server listening on local port 4005 user=> I answer yes to the "Continue" question, but no repl opens in emacs. I can enter something at the user=> prompt in the terminal, but it doesn't respond. Any idea where I went wrong? - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Can't get the debugger cdt run
I realize now that I just pasted the warning, but I was getting a class loading exception too. > > I seem to have solved it with this, in my project.clj: :extra-classpath-dirs ["/usr/lib/jvm/java-6-sun/lib/tools.jar"] I still get the warning, but it works now. Thanks Edmund. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Can't get the debugger cdt run
On Saturday, December 3, 2011 12:16:43 AM UTC-5, Sean Corfield wrote: > > On Fri, Dec 2, 2011 at 12:37 PM, George Jahad > wrote: > > The easiest way to use cdt is from emacs, as described here: > > http://georgejahad.com/clojure/swank-cdt.html > > Could you add a note to clarify that connecting "as usual" to a swank > server is via the Emacs slime-connect command since I had to ask on > IRC? > > This is the first time I've tried CDT and I have to say, I'm very > impressed with how easy it is to use! Thank you!! > -- > So I guess you didn't get this error then? user> (require '[swank.cdt :as d]) warning: unabled to add tools.jar to classpath. This may cause CDT initialization to fail. Anyone know how to fix that? - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: noob question about error with tail recursion
(recur (rest lista) ...) here: ^^^ lista is always the same thing. You probably meant (recur (rest rst) ...). - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: [ANN] Avout: Distributed State in Clojure
Wow. It will take a while to digest this before I can even dream of what possibilities this opens up. In the meantime, a couple of simple questions: 1) On the avout.io site, is the diagram of conflicting transactions correct? It looks to me like the red arrow is in the wrong place (and it doesn't match the description below it, points 5 and 6). 2) Contributing: pull requests or patches? (not that I have one yet :) If patches, where do they go? thanks, - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Error running Clojure 1.3 on OSX 10.6.8
It looks like those instructions are a bit out of date. The download does not contain a "clojure.jar" - it contains "clojure-1.3.0.jar". Just put that after -cp, and it should work. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Drift 1.4.0 released.
My guess would be a clojure version mismatch, based on the stacktrace. Have you tried changing your project to use clojure 1.2.1? - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Can't build clojure cloned from github - 2 tests failed - when running from cygwin
I suspect that Windows users are a minority here, and cygwin users are a minority of that minority :) So I'm sure that help with maintaining cygwin compatibility would be appreciated. You should start by sending a contributor agreement: http://clojure.org/contributing - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Can't build clojure cloned from github - 2 tests failed - when running from cygwin
On Monday, November 21, 2011 11:27:04 AM UTC-5, Michael Jaaka wrote: > > Then I entered into Clojure project, used: M-x clojure-jack-in (almost > there!!!) > And got exception: > > Unable to resolve symbol print-doc. > LOL :-) > Any suggestions? > Do you have the latest version of swank-clojure? Look in ~/.lein/plugins - it should be version 1.3.3 - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Can't build clojure cloned from github - 2 tests failed - when running from cygwin
I'm far from being an expert on this stuff, but I did go through all the same frustration as you are going through, about 2 years ago, so I'll try to help. I think you have an old version of clojure-mode. The default archive that comes with package.el is at http://tromey.com/elpa. It contains an old clojure-mode. marmalade-repo contains the new version. Try doing M-x package-list-packages, and then search the list for clojure-mode - it should be version 1.11.4. Put the cursor beside that, press i (for install), then x (for execute). Then restart emacs. Let me know if that works. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Can't build clojure cloned from github - 2 tests failed - when running from cygwin
"In a project" just means that the active buffer in emacs is a file under the project root. When you do clojure-jack-in, it will start from the current file's directory, and look up through parent directories until it finds a project.clj file. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Can't build clojure cloned from github - 2 tests failed - when running from cygwin
On Monday, November 21, 2011 9:27:00 AM UTC-5, Michael Jaaka wrote: > > > now as tutorial on https://github.com/technomancy/clojure-mode states used: > > M-x run-lisp > > > and got Searching for program: no such file or directory, lisp > > > any help? > > > Try using the instructions from the next section of that page, entitled "SLIME". $ lein plugin install swank-clojure 1.3.3 M-x clojure-jack-in # from inside a project Make sure you are in a project when you run clojure-jack-in. Initially, you can just do "lein new dummy-project", then open the generated project.clj in emacs, change the clojure version to 1.3, and then run clojure-jack-in. That should get you a repl. Also you may need a "lein deps" in there somewhere. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Review my code - delay-map
Meikel, That's very helpful. You and I took essentially the same approach - wrap a "real" map and delegate most operations to it. You used deftype, which I was afraid to try because there seemed to be too many interfaces and too many methods to implement, so I used proxy and APersistentMap to get some of it for free. I see from your code that there aren't nearly as many as I had feared. Your code has helped me to answer most of the questions I had. Thanks, - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Review my code - delay-map
I'm trying to implement this: I want an object that behaves just like a
normal clojure map, except in one very specific case - if a value is a
Delay, then getting that value out of the map will force it.
Other than that one difference, it should be indistinguishable from a
regular map (or as close to indistinguishable as is reasonable).
After some false starts, I have most of an implementation.
(defn delay-map
"Wraps the given map such that any value that is a Delay will be
forced when extracted."
[& [m]]
(proxy [clojure.lang.APersistentMap
clojure.lang.IObj
clojure.lang.IEditableCollection] []
;; This method implements the "real" funtionality:
(valAt
([k] (force (get m k)))
([k not-found] (force (get m k not-found
;; These methods are to preserve the type by returning
;; new delay-map instances when required.
(assoc [k v]
(delay-map (assoc m k v)))
;;(assocEx [k v] ???)
(without [k]
(delay-map (dissoc m k)))
(withMeta [md]
(delay-map (with-meta m md)))
;; boilerplate - just delegate:
(containsKey [k] (contains? m k))
(count [] (count m))
(entryAt [k] (.entryAt ^clojure.lang.Associative m))
(iterator [] (.iterator ^java.util.Map m))
(meta [] (meta m))
(seq [] (seq m))
(asTransient []
(throw (Exception. "I don't know how to implement this yet.")))
))
I also made a couple of macros to help out:
(defmacro lazy-map [& keyvals]
(when (odd? (count keyvals))
(throw (Exception. "lazy-map requires an even number of forms")))
(list
`delay-map
(into {}
(for [[k v] (partition 2 keyvals)]
[k (if (and (list? v) (symbol? (first v)))
(list `delay v)
v)]
(defmacro lazy-assoc [m & keyvals]
`(delay-map (merge ~m (lazy-map ~@keyvals
This mostly seems to work they way I want:
user> (def m (lazy-map :normal-value "hello"
:delayed-value (do (println "working...")
(Thread/sleep 2000) "hi")))
#'user/m
user> m
{:normal-value "hello", :delayed-value #}
user> (:delayed-value m)
working...
"hi"
user> (:delayed-value m)
"hi"
Now, my questions are:
1) Does proxy seem like the right way to do this (as opposed to reify,
etc.)?
2) What is assocEx (from IPersistentMap), and do I need to implement it?
3) Any idea how I could implement asTransient (or whether I should)?
4) Is there a way in clojure to find out what methods are abstract in a
class (i.e. APersistentMap)? I struggled for a while trying to figure out
which methods I needed to write - eventually I just had Eclipse generate a
java class for me with method stubs.
5) Most importantly: good idea? bad idea? If so, why? Are there any holes
in this that I'm not seeing. Are there ways that a user could accidentally
turn a delay-map into a regular map (I know of one: (into {} my-delay-map))?
Finally, in case you're wondering why I want this: I was reading through
the code of a large, complex web application, and I realized that there are
two competing forces at work when considering performance:
1) If there is data that you will need in several places, you want to avoid
calculating it repeatedly.
2) If there is data that you will not need at all, you dont' want to
calculate it at all.
Take session-state as an example. Suppose there is a session-store library,
and as a consumer of it I have to call a function, say (get-session), when
I want to use it. Maybe I end up calling that function in half-a-dozen
places. That's wasteful. So I do the smart thing and use Ring middleware
that loads the session only once and adds it to the request map. Then I can
pull it out when I need it, and it's only loaded once. But what if I never
need it for a particular request? Then I have loaded it for nothing.
In other words, point 1 above encourages us to put stuff in the map
pre-emptively, and point 2 encourages us not to.
If the request map was a delay-map, then session state could be loaded
exactly one time or zero times, as required, transparently to the consumer.
Existing code that extracts :session from the request would still work, but
now code-paths that do not use :session do not pay the cost of loading it.
Anyway, that's just the example that motivated the idea. Whether it turns
out to be useful in practice remains to be seen.
thanks,
- Chris Perkins
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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 do I store/read data with function references in it?
It looks like your (:foo d) is a symbol. ((:foo d) 4 5) is trying to look itself up as a key in the map you provided, which is 4. Since that's not a map, the lookup fails and it returns the default value you provided: 5. It's very forgiving that way :) As for your main question, about how to serialize functions, someone else will have to answer - as far as I know, you just can't do that. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Open source Clojure projects
There are lots. You could start browsing from here: https://github.com/languages/Clojure - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 passing a function into a function
The problem is that inside your timed-agent function, "test-func" is not a function - it is a one-element sequence containing your test function. That's what using & in the arguments vector does. Try it like this: (defn timed-agent [limit timed-func & [test-func]] ...) - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Code problem: setting an atom from a deref'd atom that's inside a let.
On Tuesday, October 25, 2011 12:00:04 PM UTC-4, Tim Robinson wrote:
>
> This code probably will not make a whole lotta sense since I reduced
> it down to show only the problem at hand, but I'm hoping someone can
> explain why this doesn't work the way I expected it would:
>
> => (def data (atom {:k1 "v1" :k2 "v2" :k3 "v3"}))
> #'user/data
>
> => (def flag (atom nil))
> #'user/flag
>
> => (defn oops! []
> (let [x1 (atom (hash-map))
> v1 (filter
> #(let [xv1 (@data %)]
>(if (= xv1 "v1")
>(swap! x1 assoc :k1 "other")))
>(keys @data))
> rxv (reset! flag @x1)]
> (println v1)))
>
> => (oops!)
> (:k1)
> nil
>
> => @flag
> {}
>
> I had expected this flag would now hold the value from x1, but instead
> it's empty.
>
> No, it's not empty - it holds the value that x1 had at the time you swapped
it, which is an empty map.
Later, the x1 atom had its value changed, by then it was too late to affect
flag. Specifically, x1 changed only when you printed v1, thus forcing
realization of the lazy sequence that filter returned.
Make sense?
- Chris
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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 treatment of integers and longs
On Saturday, October 22, 2011 4:31:29 PM UTC-4, Luc wrote:
>
> Where's the contract breach here ?
>
Glad you asked. Consider the following clojure session (1.3), shortened for
your reading pleasure:
map-1 => {-1 :yo}
map-2 => {-1 :yo}
key-1 => -1
key-2 => -1
Just some simple maps and values, right?
(= map-1 map-2) => true
(= key-1 key-1 -1) => true
Yup, they're the same. But:
(map-1 key-1) => :yo
(map-2 key-1) => :yo
(map-1 key-2) => :yo
(map-2 key-2) => nil
Oops! Despite being "equal", the two maps behave differently. Why?
(class map-1) => clojure.lang.PersistentArrayMap
(class map-2) => clojure.lang.PersistentHashMap
(class key-1) => java.lang.Integer
(class key-2) => java.lang.Long
Unless I am mistaken, the difference between an ArrayMap and a HashMap is
supposed to be an implementation detail - an optimization. I'm sure that
they shouldn't have different semantics. But when hashCodes and equality do
not agree, this is the sort of thing that can happen.
Note that I'm not claiming to have any deep insights into what's broken and
what's not, either in Clojure or in Java. All I'm saying is that claiming
anything along the lines of "Clojure is not Java, so we can do whatever we
want - contracts do not apply" does not lead to sane map behavior. Those
contracts were created for a reason.
To be honest, I've sort-of lost the plot of how this is related to the
boxing-ints-as-Longs issue, but that's probably due to both my lack of
expertise in this area and to the generous glass of whiskey I had while
watching Megamind with my kids this afternoon. But I digress. The point I
think I was trying to back up is "if clojure changes equality semantics, it
should change hashcodes to match". That sounds right to me.
- Chris
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Rich Hickey: "Simple Made Easy" from Strange Loop 2011
Wow. Easily the best conference talk I have seen... well, ever. Executive summary: "Mutability is bad for your complection." :) - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 treatment of integers and longs
Perhaps I can clarify why the 1.3 behavior is confusing. For those who have focused on issues like "primitives need to be boxed, therefore you get a long" - I think you are missing Nathan's point. Here is what changed about boxing in 1.3: Clojure 1.2: (class (Long/parseLong "1")) => java.lang.Long (class (Integer/parseInt "1")) => java.lang.Integer (class (Short/parseShort "1")) => java.lang.Short (class (Byte/parseByte "1")) => java.lang.Byte (class (Float/parseFloat "1")) => java.lang.Float (class (Double/parseDouble "1")) => java.lang.Double Clojure 1.3: (class (Long/parseLong "1")) => java.lang.Long (class (Integer/parseInt "1")) => java.lang.Long (class (Short/parseShort "1")) => java.lang.Short (class (Byte/parseByte "1")) => java.lang.Byte (class (Float/parseFloat "1")) => java.lang.Float (class (Double/parseDouble "1")) => java.lang.Double So the issue is not "why do primitives get boxed at all?" - it is "why are primitive ints, uniquely amongst all primitive types, singled out and boxed as a wrapper type that is not the analogue of their primitive type?" I suspect that this is what Nathan is objecting to. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 "wonky" behavior
Note: I forgot to preface that with "I think..." :) Upon experimenting briefly, it turns out I was wrong about how Clojure works (that seems to happen a lot with me). A declare/def defines a var even when it's not executed! user> (defn xxx [] (declare yyy)) #'user/xxx user> yyy # Well, I learned something today. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 "wonky" behavior
To put it another way: a top-level "do" is special-cased to compile and then immediately execute each contained form, in order. Any other top-level form, such as "list", will be fully compiled, including all contained forms, and only then executed. In this case, the defn cannot compile because the preceding declare has not yet executed - it has only compiled. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Type hints and records
Tangentially: In this particular case, reflection isn't strictly necessary because toString is a method of Object. In theory, the compiler could special-case Object's methods and never do reflection, right? In practice, I don't know if it's worth the effort, although it's certainly a little surprising that (.toString thing) can be 100 times slower than (str thing), at least until you know what's going on there. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: About metadat and #^ macro.
Alan, I'm with you on this one. Reflection is so much slower that sometimes I wish clojure had a different syntax for reflective method invocation. For example: 1) Make reflection an automatic error (not even a warning), and 2) Use another syntax (let's say double-dot, for the sake of argument) to mean "I'm OK with this being done via reflection." (.foo bar) => error (.foo ^SomeType bar) => fast (..foo bar) => probably slow Of course, something this fundamental is unlikely to change, so I guess I should just get used to setting *warn-on-reflection* :) - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Should intern work within a try block?
Nothing to do with try - clojure is trying to compile the whole top-level form. Same thing happens with any top-level form (other than do, which is special). user> (do (intern *ns* 'foo 23) foo) 23 user> (when true (intern *ns* 'bar 44) bar) ; Evaluation aborted. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Equality comparison in 1.3
core.clj currently contains two definitions of =, one of which is commented out. The active one has this docstring: "Equality. Returns true if x equals y, false if not. Same as Java x.equals(y) except it also works for nil, and compares numbers and collections in a type-independent manner. Clojure's immutable data structures define equals() (and thus =) as a value, not an identity, comparison." and the commented-out one has this: "Equality. Returns true if x equals y, false if not. Same as Java x.equals(y) except it also works for nil. Boxed numbers must have same type. Clojure's immutable data structures define equals() (and thus =) as a value, not an identity, comparison." Sounds to me like the second one was intended to be the new docstring. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Equality comparison in 1.3
Ok, I follow you now. That makes sense. Sort-of :) On the other hand, it's only inconsistent if you consider clojure's = to map to java's .equals method, but it does not: user=> (clojure-version) "1.2.1" user=> (= 3 3.0) true user=> (.equals 3 3.0) false So it doesn't really violate the contract for java's Map, which tells us that if a.equals(b), then they must have the same hash, and so a and b cannot both be keys. If you think of clojure's = as a looser sort of equivalence, then it's not a problem. I think. In any case, the 1.3 behavior does feel weird in sometimes: user> (def i 3) #'user/i user> (def j 3.0) #'user/j user> (< i j) false user> (> i j) false user> (= i j) false OK, that kind-of freaks me out... :) - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Equality comparison in 1.3
Luc,
I think you are mistaken.
user=> (clojure-version)
"1.2.1"
user=> (def m {3.0 :a 3 :b})
#'user/m
user=> (get m 3.0)
:a
user=> (get m 3)
:b
user=> (= 3 3.0)
true
user=>
Do you have another example?
- Chris
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Equality comparison in 1.3
Follow-up question: Can someone explain the rationale behind the change to = semantics between integers and floating-point numbers? I have read the design page ( http://dev.clojure.org/display/doc/Documentation+for+1.3+Numerics), but all it seems to have is this somewhat cryptic description: "It compares values in a type-independent manner, but not between floating points and integer types. This allows numbers to be used as map keys with correct semantics." I have been playing with floating-point map-keys in 1.2, trying to find some behavior that seems like incorrect semantics, but I haven't found anything odd. What sort of incorrect semantics is this change trying to correct? - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Equality comparison in 1.3
Stuart, The documentation is clear (to me) about comparing numbers directly - that part is fine. My question was about whether there is an equivalent of the new == comparison that works on containers with floating-point numbers inside. I had guessed that == would recursively compare the contents with "loosely typed" comparison, so that, for example (== [23] [23.0]) would be true, but it does not. Is there an equality comparison that does this? I couldn't find any mention of one in the numerics docs, but maybe missed it. thanks, - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Equality comparison in 1.3
I am trying to upgrade some code to 1.3, and I'm not sure how to do the
equivalent of a 1.2-style equality comparison.
user> (= {:foo 23} {:foo 23.0})
false
This used to be true. I see that = is now documented to compare same-type
numbers only, but == can be used for 1.2-compatible comparisons. However:
user> (== {:foo 23} {:foo 23.0})
; Evaluation aborted.
== only seems to work on numbers.
How can I upgrade code that expects 1.2-compatible equality comparisons? Or
do I need to change my expectations of what is considered equal in clojure?
- Chris
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Mocking out namespaces
On Friday, September 16, 2011 3:12:49 PM UTC-4, Brian Hurt wrote: > > > > On Thu, Sep 15, 2011 at 6:42 AM, Chris Perkins wrote: > >> On Wednesday, September 14, 2011 11:19:13 AM UTC-4, Brian Hurt wrote: >>> >>> Say I have two name spaces, A and B, with A depending on B. I want to >>> test namespace A, replacing module B with a mock B for testing purposes- >>> preferably without having to load B at all (B sucks in a bunch of stuff, >>> like dependencies on databases and external web sites and etc. that I don't >>> want to deal with in testing). What is the easy, clojure-approved, >>> mechanism for doing this? I tried: >>> >>> How *should* I structure this code for testing? I was assuming the > natural way to do this is to make A, B, and C separate name spaces but maybe > this is wrong. > > The problem isn't just *writing* the code- I need to be able to change this > code later, and have some assurance it still works. So "load it up into a > repl and play with it" isn't a viable solution. > > Or is clojure code just not testable/maintainable? > > Brian > > I don't have a detailed answer because I haven't done much mocking myself, but I'm confident that it's possible. The reason for my confidence is that references from one namespace to another live in Vars, which are mutable. Here's a very simple example: I made a namespace "a" containing a function "a-fn", which just calls b-fn in namespace b. Then I created a "mock-b" that defines a different b-fn. user=> (require 'a) nil user=> (a/a-fn) "real b" user=> (require 'mock-b) nil user=> (alter-var-root #'b/b-fn (constantly mock-b/b-fn)) # user=> (a/a-fn) "mock b" Note that the behavior of a-fn has been altered at runtime. I can imagine a mocking utility that, given a namespace (eg: "b"), and a mock namespace (eg: "mock-b"), would go through the vars in mock-b and call alter-var-root on all the matching vars in b before calling a test suite. In fact, I wouldn't be surprised at all to find this on github somewhere. Not much detail there, but I hope this helps somewhat. - Chris user=> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Mocking out namespaces
On Wednesday, September 14, 2011 11:19:13 AM UTC-4, Brian Hurt wrote: > > Say I have two name spaces, A and B, with A depending on B. I want to test > namespace A, replacing module B with a mock B for testing purposes- > preferably without having to load B at all (B sucks in a bunch of stuff, > like dependencies on databases and external web sites and etc. that I don't > want to deal with in testing). What is the easy, clojure-approved, > mechanism for doing this? I tried: > > > my-project |-- src | |-- A.clj | |-- B.clj | -- mocks | |-- B.clj |-- testdriver.clj # Run with the real B: java -cp clojure.jar:src clojure.main testdriver.clj # Run with the mock B: java -cp clojure.jar:mocks:src clojure.main testdriver.clj I don't know if my ascii-art directory tree makes any sense at all, but the point is that if you put "mocks" earlier in the classpath than "src", then the mock B should get loaded instead of the real one. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Creating instances of types not known at compile time
On May 9, 1:49 pm, Alan wrote: > On May 9, 9:50 am, Chris Perkins wrote: > > A mild gripe: we're in a language that doesn't make us use ugly names > like klass and clazz. Some will disagree with me for sure, but I think > it's more readable to simply use the symbol "class" when you're > talking about a class. If you disagree, by all means continue to use > klass; I'm just trying to prevent someone sticking with old java > habits because they don't realize they have a choice. Good point. Old java habits is exactly the problem. I'll give myself a smack on the hand with a ruler :) - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Creating instances of types not known at compile time
On May 9, 8:00 am, Simon Katz wrote:
> I'm trying to implement a function similar to new, but where
> the type is not known at compile time -- so I want to evaluate
> the first argument.
>
> With the help of Google, I found the approach used in new*
> below:
>
> (ns dynamic-new)
>
> (defn new* [type-name-as-symbol & args]
> (clojure.lang.Reflector/invokeConstructor
> (resolve type-name-as-symbol)
> (to-array args)))
> Now my questions:
>
> Q1. Is this basically the right approach, or is there some other
> way to implement new*?
>
Is there a reason that you need to pass a symbol, rather than the
Class object itself? eg:
(defrecord Foo [a b])
(defn new* [klass & args]
(clojure.lang.Reflector/invokeConstructor klass (to-array args)))
(new* Foo 23 "hello")
#:user.Foo{:a 23, :b "hello"}
- Chris Perkins
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Reading clojure code of larger domain specific projects
On May 9, 2:21 am, Christian Schuhegger wrote: > Hello list, > > I have a question that perhaps may be relevant for more people. I > strongly believe that reading code of other people is an undervalued > discipline of all developers. Typically it just happens as a side > effect of working in a project with other people. Like that a style of > development evolves in a programming language community. > > You may think of projects written by other people what you like (well > done, poorly done), but I believe that it is always beneficial to read > code written by other people. I've done that in C++ and Java quite a > bit (ACE framework, TAO orb, STLport, Java Swing libraries, Java > Spring libraries, Apache Commons libraries, JBoss SEAM, ...). > > I am writing programs in Common Lisp since 1995, but up to now I never > worked in Lisp projects with more than me being involved. There are > definitely many well written Lisp projects out there and books like > PAIP may definitely help, too, but I was wondering if there are any > larger domain specific open-source projects written in Clojure out > there that you would recommend for reading as some sort of best > practice guide? I was thinking about leiningen or cake, but I would > prefer projects that are closer to fulfilling a business purpose than > a technical purpose like a build system. If the project then also > would have a good documentation then that would be perfect :) > > Any suggestions from your side? > I have been thinking for while that it would be great to have something equivalent to book clubs for reading code. A group could meet weekly, all having read the same moderate-sized project, and discuss. I wonder if this could be made to work as a web-app, where you can sign up, state your areas of interest, and have a weekly reading assignment emailed. Then you could meet on IRC or something. Just a thought. Having said that, I don't have any specific suggestions for you, but I'm also interested in seeing what answers you get. - Chris Perkins -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Closures in macros
On May 3, 5:22 pm, André Thieme wrote: > Some of the limitations: > 1. (defmacro x [] `(let [a# ~(atom 0)])) > > 2. (defmacro y [] `(let [a# ~(comp inc inc)])) ; from that link > > 3. (defmacro z [] `(let [a# ~((fn [x#] (fn [] x#)) 0)])) > > All three calls fail, (x) and (y) and (z). > I see no plausible reason why it *should* be that way. I do - because most of the time, embedding an object in code is accidental, caused by messing up the quoting and unquoting. I would prefer that evaling something that cannot be produced by the reader be an error. I can see that in some cases, having eval pass unexpected types through unchanged can be useful, but I think it would be much more common for it to result in hard-to-debug errors, especially for beginning macro writers. - Chris Perkins -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Can this function be simpler?
On Mar 10, 12:46 pm, Damien Lepage wrote:
> Hi
>
> I wrote a function to transform a variable number of arguments into embedded
> maps.
> Here is what it does:
>
> > (enmap 1 2)
> {1 2}
> > (enmap 1 2 3)
> {1 {2 3}}
> > (enmap 1 2 3 4)
> {1 {2 {3 4}}}
> > (enmap 1 2 3 4 {5 6 7 8})
>
> {1 {2 {3 {4 {5 6, 7 8}
>
> Here is my implementation:
>
> (defn enmap [arg & args]
> (if-let [more (butlast args)]
> (let [k (last more), v (last args)]
> (if-let [even-more (butlast more)]
> (apply enmap arg (concat even-more (list (hash-map k v
> (enmap arg (hash-map k v
> (apply hash-map arg args)))
>
> Two things bother me:
>
> - Is there a way to make this function less complicated? without
> recursion maybe?
> - Is there something simpler than (concat even-more (list (hash-map k
> v)) to append an element at the end of a sequence?
>
I sure hope so, because I don't even understand how that works ;-)
How about this:
(defn enmap [arg & more]
(if more {arg (apply enmap more)} arg))
- Chris
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Rebinding Defs
On Mar 9, 7:31 am, Chris Perkins wrote: > On Mar 8, 6:59 pm, Timothy Baldridge wrote: > > > If in a namespace I bind a var: > > > (def foo 3) > > > And then later on in my program re-bind that var: > > > (def foo 1) > > > Will all parts of my program instantly see that update? How is it > > possible to have any sort performance when we're basically having a > > namespace function lookup for every single function call? > > To reiterate what others have said - referencing something that has > been def'd is a two-hop lookup. The first is to follow the symbol, > through the namespace map, to get the Var instance. This is the part > you are concerned about, but it happens at compile-time, so it's all > good. The second hop is to follow the pointer that's in the Var. This > currently (in 1.2) happens at runtime, but it's pretty cheap (just a > pointer deref, I think). In 1.3, this part too will happen at compile- > time unless the var is specifically marked as :dynamic. > After writing this, I started to wonder whether I really know what I'm talking about, and it turns out I don't :) I checked the code, and my understanding of what is changing in 1.3 was wrong. It does still do the pointer-deref at runtime - what it doesn't do (for non-dynamic vars) is check to see whether it's thread-bound. So it saves an AtomicBoolean.get(). I wouldn't have thought that would save enough time to be worth it, but I guess maybe it does. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Rebinding Defs
On Mar 8, 6:59 pm, Timothy Baldridge wrote: > If in a namespace I bind a var: > > (def foo 3) > > And then later on in my program re-bind that var: > > (def foo 1) > > Will all parts of my program instantly see that update? How is it > possible to have any sort performance when we're basically having a > namespace function lookup for every single function call? > To reiterate what others have said - referencing something that has been def'd is a two-hop lookup. The first is to follow the symbol, through the namespace map, to get the Var instance. This is the part you are concerned about, but it happens at compile-time, so it's all good. The second hop is to follow the pointer that's in the Var. This currently (in 1.2) happens at runtime, but it's pretty cheap (just a pointer deref, I think). In 1.3, this part too will happen at compile- time unless the var is specifically marked as :dynamic. I wonder what will happen in 1.3 with code that does the "declare first" thing: (declare foo) (defn bar [] (do-critical-loop (foo))) (defn foo [] (do-stuff)) Will it suddenly be "slower" (relative to other code). IOW, will it continue to run at 1.2 speeds (presumably "declare" will create a :dynamic var?), while code that puts functions in the "right order" will get magically faster? - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: arithmetic progression
On Mar 8, 10:26 am, Fred Concklin wrote: > Tests whether list is arithmetic progression. > > Thoughts, feedback: > > (defn arithmetic-progression? [intlist] > "tests if list is arithmetic progression." > (apply = > (map > #(apply - %) > (partition 2 1 (reverse intlist) > You lose the benefit of laziness when you use reverse. That won't matter in the case where the input actually is an arithmetic progression, because you'll have to check the whole sequence anyway. But when it's not an arithmetic progression, you want to bail out and return false early. How about: (defn arithmetic-progression? [intlist] "tests if list is arithmetic progression." (apply = (map - (rest instlist) intlist))) You'll probably want to add checks for special cases, like an empty or one-element sequence, too. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Unpredictable behavior of Protocol Extension
On Feb 28, 10:49 am, Rich Hickey wrote: > On Feb 28, 2011, at 8:32 AM, Chas Emerick wrote: > > > I agree with your sentiment. This has been discussed before here: > > >http://groups.google.com/group/clojure-dev/browse_frm/thread/fb3a0b03... > > > That discussion pretty quickly wandered into the weeds of whether > > this sort of usage of protocols was intended or not, fundamentally > > programmer error or not. There is as yet no input from clojure/core > > on either question. Maybe someone would like to weigh in on the > > issue here? > > Yes, sorry I wasn't available to chime in then. Reply is here: > > http://groups.google.com/group/clojure-dev/msg/2dbd690c7b509b63 > > Rich I would vote for a stopgap measure in 1.3 to make the selection of an implementation repeatable across JVM instances. It's fine if it's still arbitrary, as long as I can determine experimentally what the behavior is, and rely on that behavior to happen again next time I run my program. This would solve the most painful part of the problem, while allowing someone to come up with a brilliant idea for a proper solution for 1.4 or beyond. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Unpredictable behavior of Protocol Extension
I am wondering whether this is a known issue. I made the mistake of extending a protocol to two interfaces, and then calling it with an object that implements both. (defprotocol Foo (foo [x])) (extend-protocol Foo clojure.lang.Sequential (foo [x] "sequential") clojure.lang.Associative (foo [x] "associative") ) (dotimes [_ 10] (println (foo []))) You might expect this to print "sequential", or you might expect it to print "associative", or you might expect an exception. Any of the these behaviors would seem reasonable to me. However, what it actually does is behind door number 4 :) It randomly chooses one of "sequential" or "associative" for each run of the JVM. Within a JVM, once it has chosen, it continues to choose the same value forever, but in a new JVM process it chooses randomly again. This caused me a long debugging / hair-pulling-out session because within my slime repl, my code consistently behaved one way (which, by luck, happened to match with my mistaken expectations at the time), but at the same time my unit tests seemed to be passing or failing without rhyme or reason as I frantically tweaked my code over and over. I don't know, or particularly care, which behavior clojure chooses in the case of ambiguity like this, but it sure would be nice if it was predictable. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Problems with lazy-xml
On Feb 11, 5:07 am, Marko Topolnik wrote: > http://db.tt/iqTo1Q4 > > This is a sample XML file with 1000 records -- enough to notice a > significant delay when evaluating the code from the original post. > > Chouser, could you spare a second here? I've been looking and looking > at mktree and siblings for two days now and can't for the life of me > find out why it would eagerly parse the whole contents of an element > as soon as I acces its struct! The code looks perfectly correct. Just guessing, but is it something to do with this (from the docstring of parse-seq)? "it will be run in a separate thread and be allowed to get ahead by queue-size items, which defaults to maxint". Doesn't sound like it's actually lazy unless you explicitly specify a queue-size. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: struct type info
On Nov 27, 6:24 am, Sunil S Nandihalli
wrote:
> Hello,
> I would like to know if it is possible to find out the name of the
> structure from its instance. my attempt to use the function class is not
> giving me any useful info. It kept saying that it is a structmap and
> nothing more...
> Regards,
> Sunil
Structures created with defstruct or create-struct do not store a
name. They only store the keys.
If you look at the source of defstruct:
user=> (source defstruct)
(defmacro defstruct
"Same as (def name (create-struct keys...))"
{:added "1.0"}
[name & keys]
`(def ~name (create-struct ~...@keys)))
you can see that the name is not even passed to create-struct. Only
the keys are. So the struct type cannot tell you its name.
- Chris
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Regarding The Implementation of 'merge-with'
On Nov 26, 7:42 am, Stefan Rohlfing wrote:
> Dear Clojure Group,
>
> Today I took a closer look at the 'merge-with' function of Clojure
> Core and changed some parts to better understand its implementation.
>
> Now I still have two questions regarding the following code:
>
> (defn my-merge-with [f & maps]
> (when (some identity
> maps) ;; question 1
> (reduce (fn [acc m]
> (let [key (key (first m)) val (val (first
> m))] ;; question 2
> (assoc acc key (if-let [old-val (get acc key)]
> (f old-val val)
> val
> {} maps)))
>
> (my-merge-with + {"t" 1} {"a" 1} {"c" 1} {"g" 1} {"g" 1} {"g" 1} {"a"
> 1} {"c" 1} )
> ;; {"g" 3, "c" 2, "a" 2, "t" 1}
>
> Question 1:
> (when (some identity maps)
>
> This expression from the original implementation checks if the
> provided coll is empty.
> However, why not just use (when (empty? maps) or (when (seq maps)
> instead?
It has the effect that calling (merge-with f nil), or (merge-with f
nil nil nil), returns nil rather than an empty map. I guess that's the
reason for it.
> Question 2:
> In order to return the key of a map consisting of one key/value pair I
> have to use the 'first' function, otherwise an exception will be
> thrown:
>
> (key {:a "a"})
> ;; clojure.lang.PersistentArrayMap cannot be cast to java.util.Map
> $Entry
> ;; [Thrown class java.lang.ClassCastException]
>
> (key (first {:a "a"}))
> ;; :a
>
> I understand that 'key' expects a java.util.Map$Entry object, but how
> exactly does using 'first' accomplish this?
>
Calling seq on a map returns a sequence of Map$Entry objects (which
look a lot like two-element vectors, but are not quite the same).
first calls seq.
- Chris
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: using symbol macros from clojure.contrib.macro-utils does not seem to bind the &env environment variable correctly in the nested macro calls
On Nov 26, 12:25 am, Sunil S Nandihalli wrote: > I just realized that we don't need to use the with-symbol-macros when using > symbol-macrolet .. but the problem persists all the same.. I have modified > the gist to reflect this change.. > Sunil. > > On Fri, Nov 26, 2010 at 10:35 AM, Sunil S Nandihalli < > > sunil.nandiha...@gmail.com> wrote: > > Hello everybody, > > I am not sure if this is the expected behaviour .. or I am using it > > incorrectly .. The code is pasted at > >https://gist.github.com/716293. > > > (ns symbol-macro-problem > > > (:require [clojure.contrib.macro-utils :as m])) > > > (defmacro sym-macro [& body] > > > `(m/symbol-macrolet [begin :begin > > > end :end] > > > (m/with-symbol-macros > > > (println begin) > > > ~...@body > > > (println end > > > (defmacro display-local-bindings [] > > > `(do ~@(map (fn [x#] (list 'println [`'~x# x#])) (keys &env > > > (sym-macro > > > (let [x 10] > > > (display-local-bindings))) > > > the above form is not passing the correct &env variable to the nested > > macros .. It is turning out to be nil. The above code just prints > > > :begin > > :end > > > while > > > (let [x 10] > > (display-local-bindings)) > > > prints > > > [x 10] > > > I was expecting the code > > > (sym-macro > > (let [x 10] > > (display-local-bindings))) > > > to print > > > :begin > > [x 10] > > :end > > > but this is not happening since the &env variable that is being passed to > > (display-local-bindings) is nil when called inside a sym-macro > > can somebody help me understand this. > > > Thanks, > > Sunil. It seems to me that it is probably because the code in macro-utils walks down through the forms and manually calls clojure.core/ macroexpand-1. That calls clojure.lang.Compiler/macroexpand1, which is where the local bindings are normally inserted calls to macros (i.e. the display-local-bindings macro in this case). But it is being called too soon - the compiler has not yet had its chance to walk down through the enclosing forms and collect the local bindings, so it doesn't know what they are. I'm pretty sure that macro-utils predates the addition of the &env paramter. Since macro-utils takes such an aggressive approach to macroexpansion - essentially reimplementing it entirely - it is not too surprising that it would become out of sync with the built-in expansion mechanism. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: ANN: Gloss, a byte-format DSL
On Nov 23, 3:24 pm, Zach Tellman wrote:
> On Nov 23, 12:12 pm, Chris Perkins wrote:
> > I have only taken a quick look, so maybe I'm misunderstanding the
> > intent, but it's not clear to me how you would use this for sending
> > and receiving structured data from, say, a C program.
>
> > Taking your example from the wiki:
>
> > (def fr (compile-frame {:a :int16, :b :float32}))
>
> > Let's say I want to talk to a C program that speaks in structs, like
> > this:
>
> > struct Foo { short a; float b; }
>
> > The problem is, the C program cares about order - the short comes
> > before the float. How does the Clojure program know what order I need
> > the fields in, since I have specified the format with a map; an
> > unordered data structure? Is there another way to specify a structure
> > where order of the fields matters? If so, why have two ways of doing
> > it? Or am I just missing something?
> >
> Good question. The solution didn't make the cut for my initial
> release, but will be added soon. My plan is to have an (ordered-
> map ...) frame which encodes and decodes the keys in the given order.
> So for C interop, the frame would be
>
> (ordered-map :a :int16, :b :float32)
>
> An alternative would be to just turn any vector which is alternating
> keys and types into an ordered-map, but that seems a bit too magical.
>
> Zach
>
I would humbly submit that perhaps you should just go for ordered
formats, always. For example, a vector of two-element vectors could be
the canonical format:
[[:a :int16] [:b :float32]]
Then you could add some macro-sugar to make it pretty:
(struct :a :int16 :b :float32) => (compile-frame [[:a :int16]
[:b :float32]])
The reason I say this is both to simplify (have only one way to
specify a format), because I can envision people getting quite far
down a path of relying on the byte-ordering coming out of compile-
frame, simply due to the fact that clojure uses PersistentArrayMap for
small maps, giving the illusion that they are ordered. Then one day
they confidently add that Nth field to their struct definition (where
N appears to currently be 10), and suddenly they have byte-soup coming
out.
With always-ordered formats, there just seems to be less room for
error.
Just my 2c.
- Chris
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: ANN: Gloss, a byte-format DSL
On Nov 23, 12:03 pm, Zach Tellman wrote:
> When writing Calx [1], I discovered it was a huge pain to deal with
> mixed C datatypes in Java. When writing Aleph [2], I discovered the
> problem increases by a factor of ten when dealing with streams of
> bytes. In an attempt to alleviate my own pain, and hopefully help a
> few other people out, I've written Gloss, which can transform a simple
> byte-format specification into an encoder and streaming decoder.
>
> A full writeup can be found athttps://github.com/ztellman/gloss/wiki.
>
> A few people have already asked me how this differs from protocol
> buffers, so I'll preemptively answer that protocol buffers are a fixed
> format that cannot be used to interface with external systems. Gloss
> is less performant than protocol buffers, but is also much less picky
> about formats.
>
> If anyone has any questions, I'd be happy to answer them.
>
Looks very useful, Zach. Thanks.
I have a question.
I have only taken a quick look, so maybe I'm misunderstanding the
intent, but it's not clear to me how you would use this for sending
and receiving structured data from, say, a C program.
Taking your example from the wiki:
(def fr (compile-frame {:a :int16, :b :float32}))
Let's say I want to talk to a C program that speaks in structs, like
this:
struct Foo { short a; float b; }
The problem is, the C program cares about order - the short comes
before the float. How does the Clojure program know what order I need
the fields in, since I have specified the format with a map; an
unordered data structure? Is there another way to specify a structure
where order of the fields matters? If so, why have two ways of doing
it? Or am I just missing something?
Thanks,
- Chris
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Error message specifies wrong line # in source file if function lacks argvec.
On Nov 18, 11:09 pm, Ken Wesson wrote: > I got this oddity while debugging a Clojure sourcefile today: > > user=> > # declaration loop should be a vector (io.clj:55)> > user=> > You're misinterpreting the error message. It's not trying to tell you that the parameters to loop should be a vector - it's trying to tell you that the symbol "loop" was used where you should have used a vector. Try this: user=> (defn foo (loop [] 1)) java.lang.IllegalArgumentException: Parameter declaration loop should be a vector (NO_SOURCE_FILE:0) user=> (defn foo (xyz [] 1)) java.lang.IllegalArgumentException: Parameter declaration xyz should be a vector (NO_SOURCE_FILE:0) You're hitting this line from core.clj (the very last line, coincidentally): (throw (IllegalArgumentException. (str "Parameter declaration " (first bad-args) " should be a vector"))) I have no idea about the line-numbering thing, though. - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 rewrite code to avoid "bashing transients in-place"?
On Nov 8, 4:45 pm, Greg wrote: > > I must say it would be really nice if this was considered kosher.. as it does > work just fine. It would also be useful to know why transient bashing is > frowned upon. > It's not that it's "frowned upon" - it simply doesn't work. Functions that operate on transients (conj!, assoc!, etc) return the modified data-structure, just like their non-transient counterparts. It just so happens that due to an implementation detail, they sometimes return the same instance, modified in-place, that you passed to them. The key word there is "sometimes" - you can't count on that behavior. If you have been working with small collections, and "bashing in-place" is working for you, you've just been lucky. Your luck will not last ;) - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.xml questions
On Oct 30, 2:52 am, Shantanu Kumar wrote:
> Hi,
>
> 1. I notice there is just the "parse" function mentioned as
> public:http://clojure.github.com/clojure/clojure.xml-api.html
>
> I used the other functions in clojure.xml (emit, emit-element) and the
> var 'element' -- they appear to work fine for me. Are they just
> undocumented or not guaranteed to be maintained in future versions of
> Clojure?
I'm pretty sure emit is undocumented for a reason - the stuff it emits
is not, in general, valid XML. Use it at your peril.
user=> (clojure.xml/emit {:tag :foo :content ["<&>!!!"]})
<&>!!!
- Chris
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Strange behavior of PersistentTreeMap
On Oct 23, 2:10 pm, andrei wrote: > I modified procedure a bit to see interim results, and it's output > confused me even more. > > (defn replace-map > "Replaces substrings in s from (keys m) by (vals m). " > [s m] > (loop [cur-str s, ks (keys m)] > (if (empty? ks) > cur-str > (let [replaced (.replace s (first ks) (m (first ks)))] > (println "STR BEFORE: " cur-str "; STR AFTER: " replaced) > (recur replaced > (rest ks)) > > Can anybody explain what's going on? I'm very very confused. You're calling replace on the original string every time. You want (.replace cur-str ...) rather than (.replace s ...). - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Python like hash-map constructor (a.k.a. dict)
On Oct 14, 11:54 am, Henk wrote: > (I did some small benchmarks on this), while the list comprehension > itself is much faster than python... Not an answer to your question, but: depending on what you mean by "much faster", there is a good chance that you measured the clojure for expression doing nothing. You should wrap it in a doall or dorun to get a proper timing (like a generator in Python). Eg: for me, the following are almost exactly the same speed (~45ms): user=> (time (dorun (for [i (range 10)] [i (* i i)]))) "Elapsed time: 45.965679 msecs" C:\Users\chris>python -m timeit "[(i,i*i) for i in range(10)]" 10 loops, best of 3: 45.5 msec per loop - Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Macro Implementation: I Don't Understand This Error Message
On Oct 1, 3:59 am, Stefan Rohlfing wrote:
> I wanted to expand the 'infix' macro presented in chapter 7.3.1 of
> 'Clojure in Action' to handle nested s-expressions:
>
> My first version did not work:
>
> (defmacro my-infix [expr]
> (if (coll? expr)
> (let [ [left op right] expr]
> (list op (my-infix left) (my-infix right)))
> expr))
>
> ;; Test:
> (my-infix ((3 * 5) - (1 + 1)))
>
> ;; Wrong number of args (1) passed to: user$my-infix
> ;; [Thrown class java.lang.IllegalArgumentException]
>
> I would love to know why the first version 'my-infix' throws an
> exception. Can anybody give me a hint? I hope the answer could give me
> a better understanding of how macros work.
I think I can explain - someone correct me if I'm wrong.
The problem occurs while my-infix is being compiled. As the compiler
works its way into the body of my-infix, it comes across a call to
something called my-infix. Intuitively, you would expect that since my-
infix is a macro (or is it? more to come), the compiler would call it
then-and-there - but how could it? my-infix hasn't even finished
compiling, so how could it possibly be called?
So my next thought is that it should be an error - and this may very
well be true. But it seems that what actually happens is that the my-
infix var is in a sort of intermediate state - it exists, which is why
the compiler doesn't complain, but it has not yet been flagged as
being a macro. Try this:
(defmacro ct-prn [expr] ; compile-time prn
(prn (eval expr))
expr)
(defmacro my-infix [expr]
(ct-prn (meta #'my-infix))
(if (coll? expr)
(let [ [left op right] expr]
(list op (my-infix left) (my-infix right)))
expr))
(prn (meta #'my-infix))
Here's what I get printed out:
{:ns #, :name my-infix}
{:macro true, :ns #, :name my-infix, :file "C:\\Temp\
\temp.clj", :line 5, :arglists ([expr])}
So while compiling, my-infix is not yet flagged as a macro, so the
call to it gets compliled into a regular, run-time call to a function.
Still this seems like it should be OK - what's up with the "Wrong
number of args (1)..." stuff? Isn't 1 the right number of args for my-
infix?
Actually, it's not. That's becuase the compiler inserts a couple of
extra implicit arguments to all calls to macros. So in fact, my-infix,
at runtime, expects 3 arguments. Check this out:
user=> (defmacro foo [x] x)
#'user/foo
user=> (foo 23)
23
user=> (def foo2 (var-get #'foo))
#'user/foo2
user=> (foo2 23)
java.lang.IllegalArgumentException: Wrong number of args (1) passed
to: user$foo (NO_SOURCE_FILE:0)
user=> (foo2 23 34 45)
45
I hope that makes it clearer. I certainly feel like I understand
macros a little better after figuring this out.
As for what exactly the two implicit args to macros are - I don't
know. Someone else will have to explain that.
- Chris
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Life on the bleeding edge
On Jun 28, 12:21 am, Mark Engelberg wrote:
> OK, I just tried building clojure-contrib pointing at a clojure.jar
> built from the current master branch. I get the same errors (on
> Windows). Here are more details:
>
> Testing clojure.contrib.test-io
>
> FAIL in (test-as-url) (run-test9074812622524104689.clj:45)
> expected: (= (URL. "file:/foo") (as-url (File. "/foo")))
> actual: (not (= # #))
>
> FAIL in (test-relative-path-string) (run-test9074812622524104689.clj:45)
> absolute path strings are forbidden
> expected: (thrown? IllegalArgumentException (relative-path-string (str
> File/sepa
> rator "baz")))
> actual: nil
>
> FAIL in (test-relative-path-string) (run-test9074812622524104689.clj:45)
> absolute File paths are forbidden
> expected: (thrown? IllegalArgumentException (relative-path-string (File. (str
> Fi
> le/separator "quux"
> actual: nil
>
> Testing clojure.contrib.test-profile
>
> FAIL in (test-print-summary) (run-test9074812622524104689.clj:45)
> doesn't blow up with no data (assembla #31)
> expected: (= "Name mean min max count sum\n"
> (with-ou
> t-str (print-summary {})))
> actual: (not (= "Name mean min max count sum\n"
> "Na
> me mean min max count sum\r\n"))
Clojure-contrib tests have not passed out-of-the-box on Windows for
many, many months. I run maven with -Dmaven.test.skip=true as a
matter of course (and every time I do, I feel a little guilty for not
stepping up to contribute fixes for the tests instead - some day...).
- Chris
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Leiningen documentation review?
On Jun 18, 1:21 pm, Phil Hagelberg wrote: > On Fri, Jun 18, 2010 at 8:20 AM, Chris Perkins > wrote: > > This sentence in the README: "On Windows you can download lein.bat" > > contains a link to an old and busted version of lein.bat that can only > > lead to tears and misery for new users :) > > Oh right; I will update that to point to the master branch instead of stable. > > I'm trying to move away from using my personal web site, so the > instructions now point to the Github Downloads section instead. Does > that work OK? I just tried out the instructions from lein.bat on master, and it works beautifully. Thanks, Phil. Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Leiningen documentation review?
On Jun 17, 12:24 am, Phil Hagelberg wrote: > Mostly I'd like feedback on the > tutorial:http://github.com/technomancy/leiningen/blob/master/TUTORIAL.md > > But if you've got some time to look over the readme, that would be > great too:http://github.com/technomancy/leiningen/blob/master/README.md > This sentence in the README: "On Windows you can download lein.bat" contains a link to an old and busted version of lein.bat that can only lead to tears and misery for new users :) Could you either update it to point to a newer version of lein.bat, or at least upload leiningen-1.1.0-standalone.jar to http://repo.technomancy.us/ - I think that's all that's required in order to make the old instructions workable. Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: beginer jedit problem
On Apr 29, 2:05 am, Marko Srepfler wrote: > Same error > C:\clojure>java -cp jline-0.9.91.jar;clojure.jar jline.ConsoleRunner > clojure.main > Exception in thread "main" java.lang.ClassNotFoundException: > clojure.main Does it work without jline? eg: just "java -cp clojure.jar clojure.main". I've never used jline, so I'm afraid I can't help much, but I would recommend using ClojureBox for your repl. Even if you don't want to edit your files in Emacs, it's worth getting ClojureBox just for that. - Chris Perkins -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: beginer jedit problem
On Apr 28, 4:56 am, Marko Srepfler wrote: > C:\clojure-1.1.0>java -cp jline-0.9.91.jar:clojure.jar You need to separate your classpath entries with a semicolon, not a colon. - Chris Perkins -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Any window user familiar with clojure-contrib development ?
On Apr 26, 9:10 pm, gary ng wrote:
> Hi,
>
> I am wondering if there is any windows user who is familiar with
> clojure-contrib project.
>
> The reason I asked is that I encountered quite some issues when trying to
> build my own copy of clojure-contrib(on windows). That includes:
>
> 1. I cannot clonehttp://github.com/richhickey/clojure-contrib.gitas it
> would die in the middle for some item(i.e. certain git hash object) not
> found. I have to use git:// instead
> 2. Even after successful cloning, certain files seems to be suffering from
> the CRLF/LF conversion issue, I have to turn off git's CRLF auto conversion
> or else the newly cloned tree would already been showing changes(while the
> diff shows lines deleted then added with no noticeable difference, which I
> traced to the CRLF).
> 3. Then while building clojure-contrib, certain tests failed which based on
> the test log is again about the odd case of file system naming("file:/foo <>
> 'file://C:/foo") and CRLF <> LF
>
I have the same problems, but I work around them. Using the git:
protocol works, setting "git config core.autocrlf false" followed by
"git checkout -- ." seems to get around the line-endings problem, and
using "mvn -Dmaven.test.skip ..." gets around the failing tests.
One of us (meaning Windows users) really should step up and start
contributing patches for those tests... um, anyone? anyone? I guess
I should get around to talking to my boss about signing that CA -
should only take a few months to get past the lawyers, I hope :) Oh,
the joys of working for a big company.
- Chris Perkins
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: sorted-set-by drops elements
On Apr 16, 8:25 am, Razvan wrote:
> Hi,
>
> Is this the intended behavior?
>
> (sorted-set-by (constantly 0) 1 2 3 4) returns #{1}.
>
> I would expect the set to contain all the elements, and the comparator
> to only affect sort order.
I expected the same thing at first, but the behavior appears to be
consistent with Java collections, so it's probably intended:
user=> (def s (java.util.TreeSet. (proxy [java.util.Comparator] []
(compare [a b] 0
#'user/s
user=> s
#
user=> (seq s)
nil
user=> (.add s 1)
true
user=> s
#
user=> (.add s 2)
false
user=> s
#
- Chris Perkins
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: CSV Lib
On Apr 13, 10:33 am, Stuart Halloway wrote: > And here's a challenge for you: Use protocols to describe a minimal > contract for CSV parsing, then show how protocols solve the expression > problem by letting you backfit to existing Java libs without wrappers > or adapters. It would make the best screencast ever. :-) I'll counter with a challenge to you, Stuart - explain what the heck you just said in a way that a dummy like me can understand :) Really, I have so far been unable to wrap my head around the whole defprotocol thing - I just don't get what the point of it is. A concrete example explaining the "why" would help a lot. - Chris Perkins -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe, reply using "remove me" as the subject.
Re: A syntax question: positional & keyword
On Apr 7, 5:41 am, Laurent PETIT wrote:
> I think defnk is deprecated by the new feature mentioned by Stuart.
Do you mean to say that this:
user=> (defnk f [a b :c 1 :d 2] [a b c d])
#'user/f
user=> (f 3 4 :d 7)
[3 4 1 7]
is deprecated in favor of this:
user=> (defn g [a b & {:keys [c d] :or {c 1 d 2}}] [a b c d])
#'user/g
user=> (g 3 4 :d 7)
[3 4 1 7]
Eeek, I certainly hope not.
- Chris Perkins
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
To unsubscribe, reply using "remove me" as the subject.
Re: Leiningen, Clojure and libraries: what am I missing?
On Mar 4, 8:33 am, Jan Rychter wrote: > I haven't hacked on new Clojure stuff for the past two months or > so. Now, having updated my repositories, I find that everybody just > dropped ant and moved to leiningen. > How do people deal with this? I don't have any good answers for you; I just want to say "I feel your pain". The situation is worse on Windows, where I can't even get leiningen to work at all. Luckily I'm only working on one clojure project, so I just copy clojure.jar and clojure-contrib.jar into my project's lib directory, as well as a faked version of swank-clojure.jar (just a zipfile of swank source, renamed to ".jar"). That works well enough for me. Then I have a tiny little Rakefile that builds a classpath string from the contents of lib/, and has two tasks: run tests, and start a repl (which I rarely use anymore, since I got swank-clojure working). > As a more general observation, I think that a large part of Perl's and > Python's success was a unified way of dealing with libraries. There > are certain directories where you can drop libraries and expect them to > work (be found). There is ONE way of running the VM (one script, blessed > by the language creator). Then on top of that there is CPAN, which plugs > into that, downloading dependencies and dropping libraries into those > well-known directories. It isn't perfect, but it works, and is > predictable. Actually, I have noticed a move towards using tools like virtualenv for Python projects, precisely because depending on system-wide libraries makes it too non-obvious exactly what your external dependencies are, as well as creating potential version conficts. -- Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: What is EvalReader?
On Feb 19, 4:32 am, timc wrote: > Is #= an undocumented reader macro character? > Interesting - I had never heard of it either. It appears to allow you to execute code at read-time. user=> (read-string "(foo (+ 2 3) bar)") (foo (+ 2 3) bar) user=> (read-string "(foo #=(+ 2 3) bar)") (foo 5 bar) I guess the ability to disable it with *read-eval* is something to do with reading from an untrusted source. I can't, off the top of my head, think of how I would use this. I thought the ability to run code at macro-expansion time was cool enough - now I find out I can do it at read-time too! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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-contrib on Windows
On Feb 16, 5:51 pm, Ram wrote: > I'm having an issue compiling clojure-contrib on Windows. > > I downloaded the code from the git repository and when I run Maven, > after compilation it runs through the test suite fails in test-io: > > FAIL in (test-as-url) (run-test5405918110152723544.clj:47) > expected: (= (URL. "file:/foo") (as-url (File. "/foo"))) > actual: (not (= # #)) > > I'm guessing someone expected UNIX style filenames in this test case > and not Windows filenames, but that is besides the issue. The issue is > that the jars aren't actually generating themselves. Am I missing > something? If I am, its probably something really dumb. Yes, contrib has had some failing tests on Windows for a while now. You can tell maven to ignore the tests and install the jars anyway: mvn -Dmaven.test.skip=true install Chris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
