Re: Encapsulating Local Mutable State
One thing you can do is use 'reify', which will allow you to implement a protocol but also have your state atom hidden in a closure. You'll still be passing an 'object' to all of the protocol methods (obviously), but it won't be the atom itself. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: [ANN] core.async-0.2.371
I think the problem isn't the name - it just isn't clear if a channel which behaves unlike any other channel when closed can qualify as having channel semantics. On Thursday, October 29, 2015 at 2:10:43 PM UTC-7, Alex Miller wrote: > > We are not going to change the name - it is a channel with promise > semantics. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: [ANN] Gorilla REPL 0.3.1
I've made gorilla-repl part of my normal workflow recently, and I've been enjoying great results. With this new version, I'm having trouble loading documents using the normal ctrl-g ctrl-l method. When I hit return after typing the path into the load dialog, it simply closes with no feedback or visible effect. If I type the path into the URL (ie, ?filename=foo/bar) it works fine. Any idea what might be causing this or how I might debug it more effectively ? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: [ANN] Gorilla REPL 0.3.1
Ah, this makes sense. I renamed my worksheets, and it finds them fine. I didn't understand that it was supposed to be showing me a filtered list, since what I was doing worked in a previous version. So, is there now no way to create a worksheet in a subdirectory of the project? I normally keep all of mine in a subdirectory. I have another question regarding how exceptions are rendered. If you happen to evaluate code which generates an exception, the displayed representation contains only a single line. If you try to use clojure.repl and do something like (pst *e), that has the same effect. I have a dumb workaround, but is there a way to get gorilla-repl to show me the full stack trace, so that I can easily debug it in-place ? Thanks again for all of your work on this! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: anyone in Santa Cruz?
I'm also in Santa Cruz. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: [ANN] Session 0.1.3 - A live-coding environment for Clojure
This looks great - I saw your talk at one of the clojure conferences, and I'm glad you've continued to work on this! I'm curious as to whether your approach to rendering is similar to that used in gorilla repl (http://gorilla-repl.org) ? Is it similarly extensible ? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: [ANN] Gorilla REPL 0.2.0 - all new extensible renderer
This looks great, Jony - I look forward to playing with it soon! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: How to transform one data structure to another data structure?
This is very similar to Sean's solution, but all values will be vectors:
(reduce
(fn [acc [k v]]
(update-in acc [k]
#(conj (or %1 []) v))) {}
[[:a 123] [:b 124] [:a 125] [:c 126] [:b 127] [:a 100]])
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Parallelising over a lazy sequence - request for help
Paul, is there any easy way to get the (small) dataset you're working with, so we can run your actual code against the same data? On Saturday, May 25, 2013 9:34:15 AM UTC-7, Paul Butcher wrote: The example counts the words contained within a Wikipedia dump. It should respond well to parallelisation (I have Java and Scala versions that perform excellently) but I've been incapable of coming up with a nice solution in Clojure. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Parallelising over a lazy sequence - request for help
Thanks - when I said small, I was referring to the fact that your tests were using the first 1 pages, as opposed to the entire data dump. Sorry if I was unclear or misunderstood. On Sunday, September 29, 2013 3:20:38 PM UTC-7, Paul Butcher wrote: The dataset I'm using is a Wikipedia dump, which hardly counts as small :-) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure turns 5
Thank you for clojure. Using clojure has exposed me to new ideas and made be a better programmer. I consider myself lucky to be able to use it every day at work. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: lazy-sequences and memory leaks
It's not obvious to me from the code what the problem would be. Have you tried using a profiler to see what kinds of objects account for the memory? When I've run into seq issues and bugs in the past, that was pretty helpful in figuring out the underlying problem. On Feb 27, 8:13 pm, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote: Hi Everybody, I am using lazy-seqs to join two very large csv files. I am very certain that I am not holding on to any of the heads and If I did .. the jvm would be out of memory far sooner than what I am seeing currently. The size of the file is something like 73 G and the Ram allocated to the jvm is about 8G . It seems like a very gradual leak. Has anybody else encountered similar problems? In case some of you feel that my code might be the culprit, the following gist has the source. https://gist.github.com/1929345 Thanks, Sunil. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 list syntax sugar: f(x) notation
I don't see the point of your proposed syntactic change, and I just can't imagine it gaining traction. In my view, there are more pressing and important issues than trying to cater to the needs of people that are scared by (f x) as opposed to f(x). Since programming languages are artificial constructs, a programmer's sense of what is aesthetic usually seems dominated by the languages and tools with which they are familiar. I understand the desire to make clojure into what they already know, but I suspect those people would find greater benefit in approaching something new with open eyes and trying to understand it on its own terms. However, if it has such great value for you, you can always write your own reader which behaves as you like. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Better way to do this ? deep-merge-with-keys
For a project I'm working on, I wanted some variants of merge-with and deep-merge-with that would also provide information about the keys where collisions were occurring. I have (based on minimal testing) a working implementation, but it feels like there should be a simpler way to do this - I ended up copying and minimally modifying the source for merge-with and deep-merge-with, but I would be interested in any improvements people might suggest. In particular, I feel like what I'm doing with the collect function is possibly a bit obtuse, but nothing more obvious came readily to mind. https://gist.github.com/1398181 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 Conj extracurricular activities spreadsheet
Please sign me up (or give me edit access to the document and I'll add myself) for: core.logic / minikanren clojure tooling heroku drinkup D3 and clojurescript clojurescript literate programming Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: a better way to write this
You could try using every-pred to combine your predicates, which I think would be equivalent: (let [full-test (every-pred type-pred bounds-check contact)] ... On Nov 4, 9:51 am, Dennis Haupt d.haup...@googlemail.com wrote: (let [type-pred #() bounds-check #() contact #() full-test (fn [element] (and (type-pred element) (bounds-check element) (contact element)))] (filter full-test (:game-elements @world-atom)) is there a way to write the full-test in a way that doesn't force me to repeat the function constant text pattern inside the and? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Exception handling changes in Clojure 1.3.0
I believe the actual problem comes from things like RT.classForName(), which internally catches a ClassNotFoundException, and then does this: throw Util.runtimeException(e); That ends up just sort of obscuring what the exception is, and you can't just catch ClassNotFoundException - you have to catch the RuntimeException, and then figure out what it really means if you actually have to respond to a specific case. I'm not a particular fan of checked exceptions, but I don't entirely understand the rationale behind this. On Oct 3, 12:27 pm, Stuart Halloway stuart.hallo...@gmail.com wrote: The Google App Engine SDK uses checked exceptions on many of its API methods. In many cases, I want to catch these exceptions and do something Clojure-friendly with them. With Clojure 1.2.x, I had no trouble catching checked exceptions by type, e.g.: (try (some-app-engine-api-methods-called-here ...) (catch EntityNotFoundException ex ...)) This stopped working in 1.3.0. The caught exception does not match EntityNotFoundException; it is now a RuntimeException with the original typed exception chained to it. I don't fully understand the implications of the exception handling changes in 1.3 (https://github.com/clojure/clojure/commit/ 8fda34e4c77cac079b711da59d5fe49b74605553). Does it mean that all exceptions coming in from Java code into Clojure will now be wrapped in an extra RuntimeException? Catching checked exceptions seems to work fine. Try e.g. (try (throw (java.io.IOException.)) (catch java.io.IOException _ caught!)) I suspect something else is going wrong in the GAE example. Can you narrow the code down to a block you can quote in full here? Stu Stuart Halloway Clojure/corehttp://clojure.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: StackOverflowError with lazy qsort of The Joy of Clojure
Looking at the stack trace, I suspect this is the old problem of layering too many filters on top of the same seq. If I understand the issue correctly, when you have enough layers of filter on top of a seq, when you finally try to access elements, as it evaluates each layer, it is going to be making a call for each layer of filter. With enough layers, you'll blow your stack. I've seen people solve these issues by forcing the intermediate seqs, but that doesn't work well for a lazy situation such as this. On Aug 26, 7:42 am, Tassilo Horn tass...@member.fsf.org wrote: Hi all, I'm toying around with the lazy, tail-recursive quick-sort implementation Michael Fogus and Chris Houser present in their book The Joy of Clojure: --8---cut here---start-8--- (in-ns 'user) (defn sort-parts Lazy, tail-recursive, incremental quicksort. Works against and creates partitions based on the pivot, defined as 'work'. [work] (lazy-seq (loop [[part parts] work] (if-let [[pivot xs] (seq part)] (let [smaller? #( % pivot)] (recur (list* (filter smaller? xs) pivot (remove smaller? xs) parts))) (when-let [[x parts] parts] (cons x (sort-parts parts))) (defn qsort [xs] (sort-parts (list xs))) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: StackOverflowError with lazy qsort of The Joy of Clojure
If you search for filter and StackOverflowError in this group, you will find people discussing related issues. On Aug 26, 10:30 am, Tassilo Horn tass...@member.fsf.org wrote: Do you have a link to the issue? I've tried searching for filter or layer at dev.clojure.org, but I can't find anything... -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Radically simplified Emacs and SLIME setup
I had a similar issue with an existing project - it went away when I created a new project and did lein deps. On May 18, 11:39 pm, Tassilo Horn tass...@member.fsf.org wrote: Exception in thread main java.lang.IllegalArgumentException: No value supplied for key: 55298 I have to say that this project uses a clojure 1.3.0 snapshot. Is that supposed to work? And if not, is there some workaround? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Compilation question - why initialize classes when loading for compilation?
I've been working on getting clojure integrated into the build system at work, and it appears that classes are being loaded (which is not surprising to me) and initialized (which was somewhat surprising to me) as part of the compilation process. Does anyone happen to know why this is ? I would have assumed that for the purpose of compilation, it would be sufficient to load classes without initializing them, but I have no real basis for that assumption. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Compilation question - why initialize classes when loading for compilation?
Stuart, thanks for the quick reply. In my particular case, we have a lot of legacy Java code with some (bad) implicit assumptions about initialization order, which is why I became aware of this behavior. It sounds like this is something I'll have to live with ! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Compilation question - why initialize classes when loading for compilation?
Luc, I definitely would prefer to avoid odd side effects or complex dependencies in static initializers. Unfortunately, I'm integrating clojure into an existing system with a large and complex codebase that sometimes violates this - it's very similar to the configuration issue for log4j that you're mentioning, and while it doesn't seem to have any adverse effects, it does result in some alarming warnings being emitted (not by the clojure compiler, but by the Java code which is detecting that something isn't right when it is loaded). On Jan 26, 3:12 pm, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Accessing external resources from static initializers can be problematic at compile time. For example Log4j usually complains that it cannot find its configuration at compile time. This specific case is a minor issue, it does not have any impacts except the two messages printed on stdout (or stderr). Just make sure you are doing simple things in the class static initializers without any odd side effects. -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Compilation question - why initialize classes when loading for compilation?
Thanks for providing some background and cases where you ran into this as well - it's very helpful! Thus far I've been able to justify adding clojure support to our build process in large part due to the fact that it integrates very well, and doesn't require changes to how our build process (or existing code) works. It's still very much being evaluated, and I think it would harm its longer-term chances (I'm speaking specifically of my workplace, and not in general) of acceptance if I have to make many changes to accommodate the clojure compiler specifically. On Jan 26, 3:51 pm, Luc Prefontaine lprefonta...@softaddicts.ca wrote: At least, there's no bad side effects, we had an issue in 2008 with a Spring context being loaded statically in a class called at compile time oups :). Took us some time to realize what was going on, it was exiting (System.exit) if the context could not be loaded. That's the worse case we hit but it was bad enough. Could you provide a System property to wrap the static code to detect if it's compile time or runtime ? That could be a way to avoid mouse traps... There's a special variable in Clojure set by the compiler for this purpose but accessing it from java is another story I think. Passing this to the JVM doing the compilation is by far easier. Of course it might be quite an amount of work to add this in all the classes that do static inits but it could be a workaround for the most problematic cases. Luc P. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Problem with garbage collection? Was Euler 14
That completes without giving me any error. I'm using clojure 1.2.0 on OS X 10.6.6, and the JVM is 1.6.0_22. On Jan 19, 1:42 am, Andreas Liljeqvist bon...@gmail.com wrote: Reposting this from earlier mail about Euler 14. (defn cseq [n] (if (= 1 n) [1] (cons n (cseq (if (even? n) (/ n 2) (+ (* 3 n) 1 )) (apply max-key count (map cseq (range 1 100))) Gives a heap error. cseq is at most 525 elements long. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: which IDEs are you all using?
Last time I tried to use this, I found the plugin for some reason could not see the clojure source jar. It was a real bummer, since I had been hoping to find a nice IDE that would let me debug into clojure's internal classes as well, to get some insight into what was going on. On Jan 10, 6:37 am, Chas Emerick cemer...@snowtide.com wrote: Indeed, I use Eclipse + counterclockwise as well -- to the point of contributing to it of late. IMVHO, the Eclipse + counterclockwise combination is the one that has the most potential in the IDE space (for those of us that can't bear to work with emacs). Check out the v0.2.0 RC[1] that went out a little while ago that includes a vastly-improved network-capable REPL (based on the new nREPL project[2]). Now's the time to give it a roll and provide feedback on the users list[3] or in irc (you can bug me or Laurent [lpetit]). :-) - Chas [1]http://code.google.com/p/counterclockwise/wiki/ReleaseNotes#Version_0... [2]http://github.com/clojure/tools.nrepl [3]http://groups.google.com/group/clojuredev-users On Jan 10, 2011, at 2:54 AM, jamesqiugm wrote: Nobody mentions Eclipse clojure plugin, I use this. Good enough with clojure's REPL. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Tom Faulhaber: Lisp, Functional Programming, and the State of Flow video available
Thanks for posting these for those of us that were not able to make it to the conj! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Out of memory
So, doesn't this represent a bug at least ? I'm sometimes confused when this sort of issue doesn't get more attention, and I'm uncertain what the process is for filing a bug, since my impression is that we are supposed to have issues validated by discussion on the group before filing an actual ticket or issue. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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?
One thing you could do is to use loop and recur as your looping construct - every time you enter into the loop, your variable will be re-bound to the value you used in recur - in this fashion, you can avoid bashing the transient in place. On Nov 8, 1:45 pm, Greg g...@kinostudios.com wrote: So... I tried, and failed, to use transients properly. The function below, new-gen, takes a sequence of nodes and creates a new generation of nodes out of them using the functions transform-left and transform-right. Each node in the sequence has two children, one is created with transform-left, the other with tranform-right. The desired result is a new sequence containing all the children, representing the new generation. The catch is that some of the children are aborted at birth according the following rules: 1) If the child has an existing parent with a value equal to its own, it is left out of the sequence 2) If the child has an existing sibling with a value equal to its own, it too is left out of the resultant sequence The function is listed below: (defn new-gen [a] (let [t (transient [])] (doseq [f a] (doseq [n [(transform-left f) (transform-right f)]] (when-not (contains? #(= (:val n) %) (map :val (parents n))) (conj! t n ;; -- transient bashing!! (distinct #(= (:val %1) (:val %2)) (persistent! t I'm also using modified versions of 'distinct' and 'contains?', the full source for them (and the new-gen function) is available in syntax-hightlighted goodness here: http://paste.pocoo.org/show/288063/ The question is: how do I write new-gen in an elegant way and avoid bashing the transient? 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. Any help is greatly appreciated! - Greg -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Constructing Nested Trees and Memory Consumption
I could be missing something, but since you say you're running into
problems as your data gets large, I think you're possibly running into
2 things:
1. You're reading all the data into memory, and keeping it there, in
the form of the lines from the file.
2. The way you're defining postcodes-from-file results in holding on
to the head of the sequence, meaning parts of the sequence that aren't
being used anymore can't be garbage collected. You probably want to
make this into a function rather than a def, so that it gets created
when you invoke the function, but not bound anywhere that causes it to
be a gc root.
Does that make sense?
On Nov 3, 9:22 am, Paul Ingles p...@forward.co.uk wrote:
Hi,
I've been playing around with breaking apart a list of postal codes to
be stored in a tree with leaf nodes containing information about that
area. I have some code that works with medium-ish size inputs but
fails with a GC Overhead error with larger input sets (1.5m rows) and
would really appreciate anyone being able to point me in the right
direction.
The full code is up as a gist here:https://gist.github.com/661278
My input file contains something like:
SW1A 1,10
SW1A 2,20
...
Which are then mapped to 2 trees:
{S {W {1 {A {1 10}
{S {W {1 {A {2 20}
I then want to continually fold those trees into a master tree. For
the 2 maps above the merged tree would be:
{S {W {1 {A {1 10 2 20}
I'm sure I'm missing all kinds of awesome core/contrib functions to
make it more concise and would appreciate anyone pointing out
alternatives also.
The main problem is that it fails when my input data gets sufficiently
large. On my MacBook Pro it falls over with an input set of 1.5m
records (although a lot of these would be branches from the first few
levels). It reports GC Overhead limit exceeded, although also ran out
of heap size before I upped that.
I assume this is because during the tree reduction it's still
retaining references to nodes eventually causing it to build
continually larger structures?
I've included the reduce function (and how that gets called to produce
results) inline:
(defn merge-tree
[tree other]
(if (not (map? other))
tree
(merge-with (fn [x y] (merge-tree x y))
tree other)))
(def results (reduce merge-tree
{}
(map record-to-tree
postcodes-from-file)))
All help much appreciated,
Paul
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Emacs auto-complete plugin for slime users
I was having this problem, and what solved it for me was to customize the ac-modes variable (using M-x customize-variable RET ac-modes RET) and adding slime-repl-mode to the list. Once I added this, auto- complete gets automatically enabled on my repl buffers as well. Give it a try! On Oct 17, 10:00 am, Preecha P yum...@gmail.com wrote: Same here. It seems like auto-complete-mode doesn't fire up correctly. I tried to hook it using (add-hook 'slime-repl-mode-hook (lambda () (auto-complete-mode t) but it doesn't seems to do anything. I have to open the mode manually. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 bug in range or lazy-seq?
Any chance someone could walk us through how this visibility issue occurs (where the range-based version of primes consumes numbers before they are visible). This really looks like a case where side effects and implementation details are causing what appear to be strange behaviors, based on multiple things that appear to be equivalent (but which clearly are not). I've never gotten things set up yet to be able to debug into clojure internals - maybe this would be a good excuse to do so. On Oct 11, 6:56 pm, Stuart Halloway stuart.hallo...@gmail.com wrote: When a var's definition has a lazy reference to itself, as primes does below, then your results will be dependent on the lazy/chunky/strict-ness of the calls leading to the lazy reference. The functions range, rest, and remove are chunk-aware, so the range-based version of primes consumes a bunch of numbers before its changes become self-visible. Other functions, such as iterate, are not chunked, so the results are visible to primes sooner. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is nil a compile-time literal?
My interpretation is that the hash code issue (if correct) is an implementation detail, and that this should indeed be considered a bug because nil certainly seems like a compile-time literal to me. It's also an especially useful value in the context of something like case. In any case, thanks for your response. On Aug 30, 5:12 pm, Stuart Sierra the.stuart.sie...@gmail.com wrote: case does constant-time dispatch using the hash codes of the test values. Since nil is Java null, it doesn't have a hash code, so case can't handle it. I wouldn't call it a bug, but there is work to be done on extending case to edge cases like this. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Is nil a compile-time literal?
I was surprised today when using nil as the test value for one of the clauses of the new 1.2 case statement that it results in an NPE. Is this a bug, or intended behavior? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Memoizing a recursive function?
Why not simply do: (defn fib [n] (println called with n) (if ( n 2) (+ (fib (- n 2)) (fib (- n 1))) 1)) (def fib (memoize fib)) I inserted the println to verify when we were actually calling the function, and I believe this works - fib only seems to get invoked a single time for any given n. Is this solution incorrect in some way? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Simple clojure and contrib install, with SLIME ... ?
I struggle fairly often with keeping clojure/contrib/slime up to date on my machine - it seems that every time I update it, something fundamental has broken (like build.xml going away in contrib). There are a few things that seem to try to make this easier (like clojure- mode's install-clojure, or ClojureX) but they also seem unable to keep up with the speed of some of the changes that are happening (or, quite possibly, I'm using them incorrectly or ineffectively). What are other people doing to maintain their installations? Is there some simple way to keep all of these projects up to date? Or do people simply not update all of these projects often? Thanks for any help! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Simple clojure and contrib install, with SLIME ... ?
I just have a hard time keeping it working when I update. I understand that being on the bleeding edge is rough, but it's hard for me to think that this isn't especially frustrating for new users, who I suspect will find that most tutorials or guides to setting up clojure with slime (for example) aren't going to work at all. On Feb 11, 11:07 am, Richard Newman holyg...@gmail.com wrote: What are other people doing to maintain their installations? Is there some simple way to keep all of these projects up to date? Or do people simply not update all of these projects often? I suck it up. Fortunately I was in the process of switching to Leiningen when contrib suddenly moved to Maven, but I can't say I like it -- IMO there was nothing wrong with ant for contrib, which has no dependencies! Swank-clojure I have checked out from GitHub, and I rebuild as appropriate when switching between 1.1 and 1.2 (which seem to produce incompatible compiled code). -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Simple clojure and contrib install, with SLIME ... ?
Thanks a lot for your reply, Phil - I had no idea it was deprecated. I'll make an effort to do what you've suggested! On Feb 11, 1:29 pm, Phil Hagelberg p...@hagelb.org wrote: On Thu, Feb 11, 2010 at 10:59 AM, Paul Mooser taron...@gmail.com wrote: I struggle fairly often with keeping clojure/contrib/slime up to date on my machine - it seems that every time I update it, something fundamental has broken (like build.xml going away in contrib). There are a few things that seem to try to make this easier (like clojure- mode's install-clojure, or ClojureX) but they also seem unable to keep up with the speed of some of the changes that are happening (or, quite possibly, I'm using them incorrectly or ineffectively). M-x install-clojure has been deprecated for quite some time now. If you work from the swank-clojure readme you should be able to get a usable setup with no headaches since it doesn't involve compiling code locally anymore. The CI server at build.clojure.org handles compilation issues for you, and only the stable versions of the elisp libraries are present on ELPA since those don't change very much any more. http://github.com/technomancy/swank-clojure If there are problems with the instructions there please bring them up on the mailing list or file a bug. but it's hard for me to think that this isn't especially frustrating for new users, who I suspect will find that most tutorials or guides to setting up clojure with slime (for example) aren't going to work at all. Outdated documentation is an annoyance for any project. I've kept the official docs up to date, but there are so many blog posts out there that point people towards methods that don't work any more; there's not much that can be done about that. Just pay attention to the posting date when you are looking for things like this; if you find a post that's over six months old you might need to think twice. -Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Simple clojure and contrib install, with SLIME ... ?
Sadly, it looks like trying to follow the ELPA instructions to get package.el going on my emacs (carbon emacs) on the Mac doesn't actually work - I'll have to debug into it later to figure out what's actually going on, but unfortunately, for now, it's another dead end. On Feb 11, 1:59 pm, Paul Mooser taron...@gmail.com wrote: Thanks a lot for your reply, Phil - I had no idea it was deprecated. I'll make an effort to do what you've suggested! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Interesting ICFP slides from Guy Steele -- Organizing Functional Code for Parallel Execution
I ran across this on reddit this morning, and thought people on the group might find it interesting: http://docs.google.com/viewer?url=http%3A%2F%2Fresearch.sun.com%2Fprojects%2Fplrg%2FPublications%2FICFPAugust2009Steele.pdfpli=1 It actually mentions clojure briefly at the end, although I'm not sure what it said was right (that lists were represented as trees in clojure). Nonetheless, the slide deck is pretty interesting. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Interesting ICFP slides from Guy Steele -- Organizing Functional Code for Parallel Execution
Yeah, I'm aware of the tree nature of many clojure data structures, but just wasn't sure that applied to actual lists. On Feb 10, 12:06 pm, André Ferreira greis...@gmail.com wrote: What he said is basically right, only instead of list it's called vector. Not sure if vector branching is 64 or 32. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: clj-peg v0.6 released
At some point, hopefully someone will write an open-source parsing library with liberal licensing terms for clojure. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Fine-grained locals clearing
I can't express how thrilled I am that you did this work.Thanks so much - since I've run into a few of these classes of bugs, I'll see if I can switch over to new and try to run against some big data sets and give some feedback, if I can find the time. On Dec 10, 6:10 am, Rich Hickey richhic...@gmail.com wrote: I'm happy to announce I have implemented this fine-grained locals clearing in the compiler, in the 'new' branch. It should automatically cover all cases in which the code doesn't explicitly reuse the head - including non-tail usage, destructuring etc. In short, such cases should 'just work' from now on. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Running out of memory when using loop/recur and destructuring
I imagine he's just busy. At this point, I plan to create a ticket on assembla, if that's possible - I think I just need to create a login and then file it. On Nov 9, 2:07 pm, John Harrop jharrop...@gmail.com wrote: On Mon, Nov 9, 2009 at 4:31 PM, Rock rocco.ro...@gmail.com wrote: I've been following this thread, and I must say I'm puzzled that Rich hasn't said anything at all about this issue yet. It seems important enough to hear his own opinion. My observation over the past few months is that Rich has long absences away from the list, busy with other things. Maybe he cloisters himself sometimes to go on uninterrupted, focused development binges? It would explain why Clojure has grown and matured as rapidly as it has. :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Running out of memory when using loop/recur and destructuring
It does make me wonder, however, if having the lazy-seq cache things is sort of conflating laziness and consistency, since as you point out, not all ISeq implementations do any sort of caching. I wonder if it would be interesting to decompose it into 'lazy- seq' (uncached), and 'cached-seq'. I understand that this is unlikely to ever happen, but it occurred to me last night when I was idly thinking about this. On Nov 4, 2:03 pm, Paul Mooser taron...@gmail.com wrote: I completely understand the difference between the ISeq interface, and the particular implementation (lazy-seq) that results in these problems. It would be fairly straightforward, I think, to write some kind of uncached-lazy-seq which doesn't exhibit these problems, but I've felt that is sidestepping and issue and introduces issues of its own. On Nov 4, 1:16 pm, Chouser chou...@gmail.com wrote: Both those examples retain the head, but since 'incs' isn't a lazy-seq, the intermediate values can be garbage-collected. Note the difference between the seq abstraction and the lazy-seq implementation. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Running out of memory when using loop/recur and destructuring
Well, I care (conceptually) more about the fix being made, rather than the exact timeframe. If we had to wait until clojure-in-clojure, I think I could live with that, since the issue can be readily avoided. We'll see if Rich has a chance to chime-in to acknowledge whether or not he considers this a bug. On Nov 4, 5:47 am, Christophe Grand christo...@cgrand.net wrote: On Tue, Nov 3, 2009 at 7:27 PM, Paul Mooser taron...@gmail.com wrote: The real solution would be pervasive locals clearing but I seem to remember Rich saying he'd like to delay such work until clojure in clojure. What's the procedure for creating a ticket for this? Is it at least acknowledged that this IS a bug? It's better to wait for Rich's opinion on this problem before creating a ticket. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Running out of memory when using loop/recur and destructuring
I completely understand the difference between the ISeq interface, and the particular implementation (lazy-seq) that results in these problems. It would be fairly straightforward, I think, to write some kind of uncached-lazy-seq which doesn't exhibit these problems, but I've felt that is sidestepping and issue and introduces issues of its own. On Nov 4, 1:16 pm, Chouser chou...@gmail.com wrote: Both those examples retain the head, but since 'incs' isn't a lazy-seq, the intermediate values can be garbage-collected. Note the difference between the seq abstraction and the lazy-seq implementation. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Running out of memory when using loop/recur and destructuring
Ah -- I hadn't understood that when using destructuring, that subsequent bindings could refer to the destructured elements. I should have, since clojure only has let*, and this behavior seems consistent with that, for binding. Eeww. It seems like quite a thorny issue to solve, even if simple to describe. What's the procedure for creating a ticket for this? Is it at least acknowledged that this IS a bug? I don't see it in the list of assembla tickets for clojure. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Running out of memory when using loop/recur and destructuring
In the particular case given below, I'd assume that during the invocation of print-seq, the binding to s (the head of the sequence) would be retained, because my mental model for the execution environment of a function is that it is the environment in which they were declared, extended with the bindings for their parameters. So, anything inside that function execution should have a reference to that environment, and I would expect those bindings to exist until the function has completed. I seem to recall that in clojure's implementation, environments aren't reified as such, but I believe the behavior is the same. If certain JDKs are smart enough to avoid this, I consider that an implementation detail of that JDK, and thus (as with most optimizations), it's not something you should depend upon for correctness. I can't dispute your point that subtle bugs can occur with seqs, but I think that in most cases, it isn't that bad. I'm hopeful that as we find these kinds of bugs in core clojure forms, that we can get them addressed. Most of the bugs of this sort that I've introduced in my own code have been relatively straightforward to diagnose and debug. On Nov 3, 2:47 pm, Brian Hurt bhur...@gmail.com wrote: I agree. I don't like having to ditch seqs. And producers bring their own downsides- for example, being imperative constructs, they open the door for race conditions on multi-threaded code in a way that seqs don't. If anything, producers have a more-limited range of applicability than seqs, or even iterators, do. Also, polluting the meme-space with three constructs which are very similiar, but subtly different, is also a problem I'm not happy with. But here's an example of the sorts of problems we were hitting. OK, we all know that doseq doesn't hold on to the head of the seq. But what if I write: (defn print-seq [ s ] (doseq [ x s ] (println x))) Does this code hold on to the head of the seq (in the argument to the function)? I'm honestly not sure- and strongly suspect that the answer depends upon (among other things) which JVM you run the code on (and which optimizations it will perform), and how long the code has been running (and thus what optimizations have been performed on the code). And even if it doesn't, then I have no doubt that with a little complication, I can develop code that does (or at least might) hold on the head of the seq unnecessarily. Which means this is not only an issue for the original writer of the code, but also the maintainer. It's not clear. If you know that millions of records are as large as you're going to see, then seqs are the right tool- and if you load everything into memory, oh well. If the number of records might creep into the billions or trillions, then seqs (with their risk of wanting to keep everything in memory) are a bad choice IMHO. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Running out of memory when using loop/recur and destructuring
I understand the pragmatism of your approach, but it's really unfortunate. Seqs are a really convenient abstraction, and the ability to model arbitrarily large or infinite ones (with laziness) is really useful. In my opinion, only using seqs when all of the data can be fit into memory really undermines the value of the abstraction (by narrowing its usages so severely), and also makes laziness far less useful (except possibly as a way to amortize costs over time, rather than as a way to model infinite things). This path has been well-tread, but the danger of hanging on to the head of the list is due to the caching behavior of lazy seqs, which is important for consistency - otherwise, walking the same seq twice might result in different results. As with most engineering efforts, there are trade-offs, but I've been willing to accept the extra caution I need to employ when dealing with lazy seqs. I've run into a few of these kinds of bugs over time, and I'm guessing it's generally because in my uses, I'm dealing with millions of records, and far more data than I can fit in memory. I'm not sure that this indicates that seqs are the wrong tool in this instance (as you seem to say), but the answer isn't clear to me. On Nov 3, 1:20 pm, Brian Hurt bhur...@gmail.com wrote: We finally said don't use a seq unless you don't mind all the elements being in memory! and wrote a producer class. The producer class is similar to a normal Java iterator, in that getting the next element updates the state of the object- however maps and filters are applied lazily, and there is an additional close function which says that no more elements need to be produced (allowing for the closing the underlying file descriptor, for example). I disbelieve in golden hammers. Seqs (aka lazy lists) are incredibly useful in a lot of places, and I'm glad that Clojure has them. On the other hand, there are times and uses where seqs are the wrong tool to use. Of course, the same can be said of producers. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Running out of memory when using loop/recur and destructuring
I'm a little surprised I haven't seen more response on this topic, since this class of bug (inadvertently holding onto the head of sequences) is pretty nasty to run into, and is sort of awful to debug. I'm wondering if there's a different way to write the loop macro so that it doesn't expand into an outer let form. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Running out of memory when using loop/recur and destructuring
This is great advice, of course. On the other hand, I feel it's important to be explicitly clear about which forms will hold on to (seemingly) transient data. Certain things are explicitly clear about this (such as the docstring for doseq), and this particular case is unfortunate because in the common case, loop doesn't hold on to the reference. I think the inconsistency in this case is dangerous, especially since loop/recur is the generic iteration construct. On Nov 2, 12:59 pm, John Harrop jharrop...@gmail.com wrote: In the meantime, remember that it's always worth trying to implement seq-processing in terms of map, reduce, filter, for, and friends if possible, or lazy-seq, before resorting to loop/recur. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Running out of memory when using loop/recur and destructuring
Good job tracking down that diff -- upon looking at it, unfortunately, I obviously don't understand the underlying issue being fixed (the inter-binding dependencies) because the old code basically matches what I would think would be the way to avoid introducing this in an outer let form -- clearly the old code must have significant or subtle issues of its own! On Nov 2, 10:39 am, Christophe Grand christo...@cgrand.net wrote: Thus this commit allows to write (loop [[x xs] s y xs] ...) but introduces this head-retention behaviour. Right now I can't see how loop can be made to support both cases. Hopefully someone else will. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Running out of memory when using loop/recur and destructuring
I actually restructured my code (not the toy example posted here) to avoid the destructuring, and was disappointed to find it also eventually blows up on 1.6 as well. I'm reasonably certain in that case that I'm not holding on to any of the sequence (since I don't refer to it outside the invocation for the initial value of the loop, so I'm still hoping people can help me suss this out. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Running out of memory when using loop/recur and destructuring
A user on IRC named hiredman had the excellent idea (which should have occurred to me, but didn't) to macroexpand my code. A macro expansion of (loop [[head tail] (repeat 1)] (recur tail)) results in: (let* [G__10 (repeat 1) vec__11 G__10 head (clojure.core/nth vec__11 0 nil) tail (clojure.core/nthnext vec__11 1)] (loop* [G__10 G__10] (clojure.core/let [[head tail] G__10] (recur tail So, if I'm interpreting this correctly, it appears if you destructure in this way, there is going to be a reference to the seq held outside the loop itself. Does this mean, then, that this kind of heap explosion is inevitable using destructuring with large lazy seqs? It's hard for me to believe that is the case, and I'm definitely not a macro expert, so I'd be happy to be shown to be wrong. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Running out of memory when using loop/recur and destructuring
From looking at the source code the loop macro, it looks like this might be particular to destructuring with loop, rather than being related to destructuring in general ? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Running out of memory when using loop/recur and destructuring
I was working with a large data set earlier today, and I had written a loop/recur where I was passing in a huge seq to the first iteration, and I was surprised when I ran out of heap space, because I was very careful not to hold on to the head of the seq, and I though that loop ended up rebinding all of its params (and didn't hold on to the initial values). When I run the following code: (defn loop-test [] (loop [[head tail] (repeat 1)] (recur tail))) It will blow the heap on a 1.5 JDK, but I can't seem to make that happen under a 1.6 JDK. I ran into a previous issue that was similar (with respect to only manifesting on an older JDK), and it turned out to be a bug in clojure (fixed in svn 1153). I noticed that this doesn't occur if I don't use destructuring: (defn loop-test2 [] (loop [s (repeat 1)] (recur (rest s This version seems to run forever on either JDK, using a constant amount of heap space. Is this behavior due to some artifact of destructuring I'm not aware of (or something else I'm missing), or is there a bug? If it sounds like a bug, can anyone else reproduce? Thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Bitfields access in Clojure
Is it safe to assume that you can extract the key ordering from the literal map the user specified ? Or am I misunderstanding ? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 in Clojure?
Since clojure is a compiled language, and is going to just end up generating java bytecodes, I wouldn't expect it to be particularly slower if it was written in itself. Maybe that's naive ? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Reminder: Bay Area Clojure User Group meeting in SF during JavaOne (6/3) with Rich Hickey
I wanted to say thank you to everyone involved in setting this up - Tom and Amit for organizing, and everyone who presented. It was fun to get a chance to see what other people are doing in clojure, and to get a preview of what Rich has been working on and to hear his thoughts on near-to-mid term directions for the language. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Help with Math Question
For a general non-commutative operation, I'm not sure you can do this without keeping extra state around. You can clearly cheat by accumulating state as you run reduce, and then as the last reduce step perform the actual computation, but that isn't any better than the original problem you're trying to solve. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Swank broken at r1369
I believe you're running into the fact that add-classpath doesn't work in the same way that it used to since r1369. Basically, the swank paths are failing to be added to your classpath at runtime - you can get around this either by reverting to an older version of clojure, OR you can pass an explicit classpath including the swank path(s) when you launch clojure in the first place. I posted about this previously, and I'm hoping the behavior of add- classpath will either be restored or clarified in the future. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Classpath problem with r1369 ?
Thanks for the reply, Rich - I'll have to see if I can find another way to get this to work. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Classpath problem with r1369 ?
Thanks for the reply, Rich. I'll have to see if I can find another way to make this work, but it has been really nice so far having the ability to add things to the classpath that weren't specified at launch time. Most of what I am doing is in fact at a REPL, because I have clojure embedded inside of a running app, and up until now I've used the whole add-classpath mechanism to dynamically load or access code that I may use in an ad-hoc fashion but which I don't want to have static dependencies on in general. Anyway, as you say, I can always continue to use the 1.0 release, and once your modularity changes are completed, I can see how that fits into my situation. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Classpath problem with r1369 ?
Is anyone having contrary results, or does anyone know of a way to call add-classpath and have it actually work with an up-to-date trunk build of clojure ? This basically breaks my common usage of clojure, because it requires me to pass all class paths to the app upon launching, which isn't always practical in my environment. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Classpath problem with r1369 ?
I've been using clojure for a while at this point, and the approach I've settled on launches clojure using -cp clojure.jar, and then my user.clj file contains code that loads a bunch of thing into my classpath. After updating to r1369, which made some changes to classloaders that I don't claim to understand, this approach does not seem to work anymore, and even from a simple repl I'm not able to use add-classpath to any noticeable effect. Is this a bug, or is there some other way to use add-classpath in order to achieve the result I want ? Thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: I got to use Clojure at work today !!!
It's actually fairly straightforward. In my (ordinary java) application, I create a thread which loads a clojure program passed on the command line (I don't have the source in front of me, but if you need it, I can give you a hand), and that program typically contains something like the following: (require 'swank.swank) (swank.swank/start-server /dev/null :port 4005 :dont-close true) Then I can simply connect to a running instance from emacs by running: M-x slime-connect Hope that helps ! On Mar 17, 12:23 am, Tassilo Horn tass...@member.fsf.org wrote: Paul Mooser taron...@gmail.com writes: Hi Paul, I've been using clojure in a similar way at work. I run a swank server in a separate thread inside of a running application instance, and I can connect to it remotely using SLIME. It works pretty well! I could benefit from such an approach, too. Could you elaborate a bit on how to do this? Here we normally develop in Java using the Eclipse IDE. What do I have to do to start a swank server when I run one of our apps? Bye, Tassilo -- Chuck Norris once roundhouse-kicked a ten dollar bill into 200 nickels. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: filter1 interesting?
I think I prefer find-first as well, rather than ffilter. I worry that ffilter isn't clear enough, and reads too similarly to filter. On Mar 16, 7:51 am, Laurent PETIT laurent.pe...@gmail.com wrote: Just to make me more enemies ;-), I would prefer, on the other hand, find-first over ffirst (I'm not that nostalgic of some Common Lisp-like abbreviations :-) No, really, ffirst is just 3 characters shorter than find-first, and looks like a typo at first glance. -- Laurent 2009/3/16 André Thieme splendidl...@googlemail.com On 16 Mrz., 13:14, Rich Hickey richhic...@gmail.com wrote: On Mar 14, 11:26 am, Stuart Sierra the.stuart.sie...@gmail.com wrote: I've added a seek function to clojure.contrib.seq-utils: (defn seek Returns the first item of coll for which (pred item) returns logical true. Consumes sequences up to the first match, will consume the entire sequence and return nil if no match is found. [pred coll] (first (filter pred coll))) Sorry to jump in late, but one problem with seek is that it is a homophone of seq. Did anyone consider ffilter or find-first? In that case I would vote for ffilter. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: I got to use Clojure at work today !!!
I've been using clojure in a similar way at work. I run a swank server in a separate thread inside of a running application instance, and I can connect to it remotely using SLIME. It works pretty well! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is proxy the right tool for this job ? Cyclic vector ? Proxy bug ?
I haven't done much beyond verify that the error is gone, but it appears that your patch solved my immediate issue. Thanks for the quick fix, Christophe! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is proxy the right tool for this job ? Cyclic vector ? Proxy bug ?
Timothy, thanks for explaining - I respond to one specific part below: Interop with Java is a real strength of Clojure. But doing so is less useful for learning Clojure and more useful for learning Java. Feel free to pursue it, Java interop is certainly not wasted effort/ knowledge. It certainly doesn't violate the spirit of Clojure, my words were intended in relation to writing Euler solutions in a non- Java way. The fact that IPersistentVector is a Java interface is rather incidental. To me, dealing with the core abstractions provided by clojure (which are sometimes codified as Java interfaces), and learning how to extend them in certain circumstances, is not only germane, but it's actually vital to using the language effectively. With regard to writing Euler solutions in a non-Java way, I'm just trying to write them in my clojure way. :) In any case, I appreciate the help and insights. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Is proxy the right tool for this job ? Cyclic vector ? Proxy bug ?
I was playing around with some project euler problems, and I was thinking that the cycle function has an analog for vectors. I implemented a short simple method with the right behavior (at a simple surface level): (defn cyclic-vector [v] (fn [x] (v (mod x (count v) However, this obviously does not implement IPersistentVector. Is there any easy way to implement something like this, and delegate the rest of the behaviors to the base vector object ? I realize this is probably possible with proxy, but I have not successfully made it work yet - proxying the IPersistentVector interface results in the following for me: (proxy [clojure.lang.IPersistentVector] []) java.lang.ClassFormatError: Duplicate method namesignature in class file clojure/proxy/java/lang/Object$IPersistentVector (NO_SOURCE_FILE: 2) Is this an issue with proxy, or am I using it incorrectly ? I removed any extraneous code of my own, since the error occurs with just the minimal proxy usage shown above. I'm on trunk, revision 1326. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is proxy the right tool for this job ? Cyclic vector ? Proxy bug ?
I actually mentioned the cycle function in my message, and that's what I was using, but the original question came up because accessing the nth item in a list takes linear rather than constant time. I'd be interested to hear how what I was attempting violates the spirit of clojure. I was trying to work within the bounds of an existing abstraction, and to implement my changes in such a way as to not break other things that consume that abstraction. Incidentally, I don't believe the error I'm getting from proxy has anything to do with IPersistentVector being an interface, since you can clearly do: (proxy [clojure.lang.IFn] []) and that works fine (although obviously is not related to solving my particular problem). On Mar 8, 5:20 pm, Timothy Pratley timothyprat...@gmail.com wrote: For your eueler problem consider using lazy functions cycle and range: user= (take 15 (cycle (range 5))) (0 1 2 3 4 0 1 2 3 4 0 1 2 3 4) Or is there some other behavior you need to create? Regarding proxy your main problem is that IPersistentVector is an Interface (no implementation) so you would have to specify every method. More sensibly you could proxy the concrete implementation PersistentVector, however it does not have an empty constructor so you would need to figure out exactly what you want to do. user= (proxy [clojure.lang.PersistentVector] []) java.lang.IllegalArgumentException: No matching ctor found for class clojure.proxy.clojure.lang.PersistentVector I would advise against proxying for this problem as it is complex and not in the spirit of solving the problem in Clojure. Regards. Tim. On Mar 9, 9:13 am, Paul Mooser taron...@gmail.com wrote: I was playing around with some project euler problems, and I was thinking that the cycle function has an analog for vectors. I implemented a short simple method with the right behavior (at a simple surface level): (defn cyclic-vector [v] (fn [x] (v (mod x (count v) However, this obviously does not implement IPersistentVector. Is there any easy way to implement something like this, and delegate the rest of the behaviors to the base vector object ? I realize this is probably possible with proxy, but I have not successfully made it work yet - proxying the IPersistentVector interface results in the following for me: (proxy [clojure.lang.IPersistentVector] []) java.lang.ClassFormatError: Duplicate method namesignature in class file clojure/proxy/java/lang/Object$IPersistentVector (NO_SOURCE_FILE: 2) Is this an issue with proxy, or am I using it incorrectly ? I removed any extraneous code of my own, since the error occurs with just the minimal proxy usage shown above. I'm on trunk, revision 1326. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Alternatives to contains?
Well, sorry for bringing it up again, but the reason I did so is that
uncommonly confusing because of the name, especially considering how
good the names in clojure are in general. I know not everything can be
clear without reading the documentation, but it was only clear to me
that contains? was not what I wanted because the docs explicitly
stated that it would never search linearly for a value.
I have no problem with higher order functions (obviously), but to me a
recurring theme in functional programming is separating structural
concerns from the code itself. I think it's such a common task to want
to know if a collection contains something that it is very sensible to
provide a function which perform that task for every collection - when
something happens all the time, in almost any program of significant
size, it is often worth giving that something a name.
I realize that Rich has concerns (from reading previous threads on
this subject) about having functions which have widely varying
performance (from constant to linear time) depending on the sort of
collection, but to me it seems very natural to have the performance of
a lookup operation depend on the kind of collection you're looking in.
I would not expect any method that operated on lists to have anything
but linear time, and similarly I'd expect hash table lookups to
provide operations in constant time (or constant time, with
clojure's maps).
Obviously code like (some #{x} coll) works, but creating a set to use
as a way to search a list to find if it contains an item doesn't
scream clear to me - I suppose idioms aren't always chosen for
clarity of expression, or perhaps I'm merely not one of the initiated,
yet.
On Jan 29, 2:48 pm, Chouser chou...@gmail.com wrote:
I thought we had beaten this one entirely to
death:http://groups.google.com/group/clojure/browse_thread/thread/ff224d2b8...
And yet it lives!
What is the drawback of the (some #{:y} [:x :y :z]) idiom? Is it too
verbose? Too slow? Too flexible? Too good a re-use of existing
functionality? Too helpful in opening ones eyes to the possibilities
of sets and higher order functions?
And if you really don't want to use it (why again?) there is
clojure.contrib.seq-utils/includes?, so why not use that?
--Chouser
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Alternatives to contains?
Well, sorry for bringing it up again, but the reason I did so is I
find the name uncommonly confusing, especially considering how good
the names in clojure are in general. I know not everything can be
clear without reading the documentation, but it was only clear to me
that contains? was not what I wanted because the docs explicitly
stated that it would never search linearly for a value.
I have no problem with higher order functions (obviously), but to me a
recurring theme in functional programming is separating structural
concerns from the code itself. I think it's such a common task to want
to know if a collection contains something that it is very sensible to
provide a function which perform that task for every collection - when
something happens all the time, in almost any program of significant
size, it is often worth giving that something a name.
I realize that Rich has concerns (from reading previous threads on
this subject) about having functions which have widely varying
performance (from constant to linear time) depending on the sort of
collection, but to me it seems very natural to have the performance of
a lookup operation depend on the kind of collection you're looking in.
I would not expect any method that operated on lists to have anything
but linear time, and similarly I'd expect hash table lookups to
provide operations in constant time (or constant time, with
clojure's maps).
Obviously code like (some #{x} coll) works, but creating a set to use
as a way to search a list to find if it contains an item doesn't
scream clear to me - I suppose idioms aren't always chosen for
clarity of expression, or perhaps I'm merely not one of the
initiated, yet.
On Jan 29, 2:48 pm, Chouser chou...@gmail.com wrote:
I thought we had beaten this one entirely to
death:http://groups.google.com/group/clojure/browse_thread/thread/ff224d2b8...
And yet it lives!
What is the drawback of the (some #{:y} [:x :y :z]) idiom? Is it too
verbose? Too slow? Too flexible? Too good a re-use of existing
functionality? Too helpful in opening ones eyes to the possibilities
of sets and higher order functions?
And if you really don't want to use it (why again?) there is
clojure.contrib.seq-utils/includes?, so why not use that?
--Chouser
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from 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: Alternatives to contains?
I understand that sets or hash maps are more efficient structures for lookups. However, in certain cases (especially if I'm programming something interactively), I have either short lists or data which is naturally a list that will be faster to walk through than to convert it to a set (which implicitly assumes I'll walk through it). Anyway, point taken, but I'm not sure that completely addresses the question I'm posing. On Jan 29, 3:23 pm, Achim Passen achim.pas...@gmail.com wrote: My guess is that the omission of includes? in core is not an oversight after all, but an incentive to pick the right data structure for the task at hand. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Alternatives to contains?
Good point - I actually looked in Collections, but failed to look in Collection itself. On Jan 29, 3:55 pm, Kevin Downey redc...@gmail.com wrote: actually rhickey showed up on irc and pointed something out: ... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: newbie Q: what's wrong with this?
Clojure supports functions with multiple arities (http://clojure.org/ functional_programming). Assuming you don't actually care if you call the function with a vector, you can do something like this: (defn sum ([] 0) ([acc r] (if (nil? r) acc (recur (+ acc (first r)) (rest r) Not sure if that is precisely what you want or not. On Jan 23, 9:58 am, wubbie sunj...@gmail.com wrote: Thanks Jason. Anyway I'd like to have (sum) returns 0 so I used [ more]. Is there any way to specify 0 or more args? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: SLIME: trouble with java.lang.OutOfMemoryError
After talking to Jeffrey Chu, it seems like what is actually happening is possibly fairly obvious (in retrospect) - the java process runs out of heap space, and there's not even enough memory to keep swank- clojure working properly. Jeffrey tried some examples with just a plain REPL (without SLIME), and managed to get a dead REPL after causing an out of memory error, so there may be more fundamental lower level things going on, and it's not clear that this can really be addressed on the SLIME side. I'm not sure what a good solution to this problem would be, but I thought I'd post an update for anyone who was curious what the actual issue was. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: SLIME: trouble with java.lang.OutOfMemoryError
Yeah, I'm not really sure how I think the problem would be ideally solved. It would just be nice for an interactive programming environment to be able to recover from all exceptions that happen at a higher level than the VM itself. On Jan 10, 12:20 pm, Christian Vest Hansen karmazi...@gmail.com wrote: I don't think it is possible to define a way to deal with heap saturation that is general enough to cover all programs written in Clojure, and therefor I don't think this is something that the Clojure runtime should deal with at all. Personally, I only know of two ways to handle OutOfMemoryErrors: 1) let the program blow up and hope someone notices or 2) look at your body, pick the limb you are least likely to be needing pretty soon and cut it off (aka. free some memory) and _then_ yell for help through some hopefully reliable channel. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
SLIME: trouble with java.lang.OutOfMemoryError
I was playing around earlier while following Mark Engelberg's blog post, and I found that to my surprise, when I exhaust the heap (java.lang.OutOfMemoryError), it basically fails to pop up the window that gives me the exception (where you can normally abort or throw the cause), and the REPL itself only shows ; Evaluation aborted and is non-responsive (sometimes it will show the exception in the REPL itself). In order to resolve this, I've tried the following steps: - update swank-clojure to latest - update SLIME to latest - update clojure itself to latest None of these help. Other exceptions I've deliberately caused, such as an NPE, work as expected with SLIME. Can anyone else reproduce this behavior ? In the past, specifically when playing with filter, I have exhausted the heap many times with clojure, and SLIME has always worked perfectly - I'm not sure when this behavior was introduced but I haven't been able to track down exactly when it started happening. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: (alength nil) = java.lang.IllegalArgumentException: More than one matching method found
Well, I'm guessing that the multiple methods exception is due to the fact that the value of null in Java is not typed - that is to say, there is no such thing as a null String versus a null Integer - null is just null. If you pass a value of null to something that has multiple implementations, it's probably finding it can't determine which one it should call with just null (or nil, in clojure). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Trivial use of pmap results in RejectedExecutionException ?
Hi there, I've been playing around with a few different approaches to writing concurrent programs in clojure, and I was surprised that a trivial use of pmap results in a RejectedExecutionException: (pmap #(* % %) (range 0 10)) This exception tends to happen in java when there is a thread pool executor which uses a bounded blocking queue - when the queue is full, instead of blocking insertions to the queue, it throws this exception instead. I haven't dug into the actual clojure agent behaviors to see what is happening at a lower level, but is anyone else seeing this? (Please note that if I use the alternate implementation of pmap on the Refs and Transactions page of clojure.org, it doesn't throw any exceptions.) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Trivial use of pmap results in RejectedExecutionException ?
From a quick glance at the sources, I would not expect the scenario I described above to result in this. I'm going to see if I can wrangle a debugger into working with clojure (JSwat doesn't seem to perform well on my system, and I'm hoping I'll have better luck in Eclipse), and then see why specifically the executor used by the agents is having this issue on my system. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Trivial use of pmap results in RejectedExecutionException ?
Bingo - that fixed it. Sorry I didn't check that earlier. On Jan 1, 3:22 pm, Chouser chou...@gmail.com wrote: Works for me, SVN 1193 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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 issue with nth
I think this might just be a JVM version issue. I can reproduce this issue with a 1.5 JVM, but I can't reproduce it with 1.6. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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 issue with nth
Nice job finding it ...! Once I could not reproduce it on JDK 6, I stopped looking for a real answer. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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 issue with nth
This does NOT occur if I do this directly from the repl (ie, java -cp clojure.jar clojure.lang.Repl), but it DOES happen if I am accessing the repl through SLIME. Does anyone know why this might be ? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: memory issue with nth
I believe my analysis was incorrect. Never mind! On Dec 9, 1:23 pm, Paul Mooser [EMAIL PROTECTED] wrote: This does NOT occur if I do this directly from the repl (ie, java -cp clojure.jar clojure.lang.Repl), but it DOES happen if I am accessing the repl through SLIME. Does anyone know why this might be ? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Running out of memory when using filter?
Is there a place we should file an official bug, so that Rich and the rest of the clojure people are aware of it? I imagine that they may have read this thread, but I'm not sure if there is an official process to make sure these things get addressed. As I said in a previous reply, it's not clear (to me, at least!) how it matters if the function is holding on to the rest, since one first and rest have been evaluated for a lazy cons cell, it sets f (the function) to null. I realize that the sequence that represents rest at that time might have a derivative version of the original sequence (presumably one link further down the list!), but it has been my assumption that it would not hold on to the whole thing forever, just as long as it needs to, which seems correct. If someone understands exactly what it is that is holding on to a reference to the whole sequence, once we have a first match, can someone explain the exact mechanism that is causing it, and why nulling out f has no effect? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: memory issue with nth
Is there a way to access the bytecode that a given expression compiles into? I'm curious if it would make it easier to file a bug report on the JVM on any affected platforms. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Running out of memory when using filter?
I can, and what it has is the elements you might expect for something defined in the context of filter: coll pred coll is a lazy-cons, and is the start of a chain of a larger number of lazy conses. One thing that is interesting is that it does not appear to be the head of the sequence - it's near the head, but not the head, as far as I can tell. pred is the predicate I passed in, and I can see that it definitely does not itself maintain a reference to the sequence, at least according to the heap profiler. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Running out of memory when using filter?
On Dec 6, 5:45 am, Chouser [EMAIL PROTECTED] wrote: This may not be worth much, but can you see the data members of that object? It's not itself the head of a cons chain, presumably, so I'm wondering if the data member that *is* at the head has a useful name. I can, and it has the elements you might expect for something defined in the context of filter: coll pred coll is a lazy-cons, and is the start of a chain of a larger number of lazy conses. One thing that is interesting is that it does not appear to be the head of the sequence - it's near the head, but not the head, as far as I can tell. pred is the predicate I passed in, and I can see that it definitely does not itself maintain a reference to the sequence, at least according to the heap profiler. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Running out of memory when using filter?
On Dec 6, 9:37 am, MikeM [EMAIL PROTECTED] wrote: A while back I posted an experimental patch to capture each form that is compiled into a fn. This might be useful in your case, where you have identified a function but don't have details on it. Here's the thread:http://groups.google.com/group/clojure/browse_frm/thread/e63e48a71935... Thanks Mike, this sounds like a possible avenue for me to explore. At this point I'm not even introducing any anonymous functions of my own anymore, as far as I know - maybe I can use your patch to help debug what is really going on. Thanks for the help. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Running out of memory when using filter?
On Dec 6, 4:35 pm, Stephen C. Gilardi [EMAIL PROTECTED] wrote: The fn in question is likely the one in the macro expansion of the lazy-cons inside filter. As a next step, I would try replacing the call to doseq with the equivalent loop/recur: That's a good idea, Steve - I didn't totally understand the code you included, but I do always forget that clojure has destructuring in its binding forms, so I rewrote it like this, which I believe should be fine (correct me if I am wrong): (defn splode2 [index-path] (with-local-vars [doc-count 0] (loop [[document rest-documents] (filter my-filter-pred (document-seq index-path))] (when document (var-set doc-count (inc @doc-count)) (recur rest-documents))) 'done)) This blows up exactly the same, with exactly the same object (clojure.core$filter__3364$fn__3367) referencing the big chain of lazy- conses. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Running out of memory when using filter?
You reproduced it for sure -- On Dec 6, 5:58 pm, MikeM [EMAIL PROTECTED] wrote: Next, I tried this (since your app filters the seq from a map): (defn splode2 [n] (with-local-vars [doc-count 0] (doseq [document (filter #(= % 1) (map inc (range n)))] (var-set doc-count (inc @doc-count))) 'done)) and it blows up (out of memory) with (splode2 1000) I went ahead and dug around through the heap again, and found it's exactly the same thing that's holding on to all the memory, so this is definitely the same problem. I also saw your subsequent example which uses a different anonymous function which does NOT blow up, and that's very interesting. I'm not sure why this would be, but it seems that filter ends up holding on to the collection its filtering internally from the point at which it first matches - I think the second one doesn't blow up because it doesn't happen until almost the end. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Running out of memory when using filter?
I think I understand. The lazy-cons that filter is constructing maintains a reference to the whole coll in its tail so that it can evaluate (rest coll) when it is forced. Hmmm! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Running out of memory when using filter?
On Dec 6, 8:38 pm, puzzler [EMAIL PROTECTED] wrote: Maybe LazyCons shouldn't cache. Make LazyCons something that executes its function every time. For most things, it's not a problem because sequences are often traversed only once. If a person wants to cache it for multiple traversals, he can explicitly call cache-seq on it. Is caching really the problem here? I'm curious. Looking at LazyCons.java, I see that it uses an IFn f generate the rest, and saves the value (a seq) in _rest. I assume that the function f is what is actually holding a reference to the whole collection (it may actually be the version of the function that the _rest contains, but I'll get there in a moment). At this point, once we have a value for _first and _rest, it doesn't seem like there's any value to having a reference to f. The code seems to agree with me, because once _rest has been set, it sets f to null. However, clearly there is still a problem here, based on all the different code samples in the thread which exhibit the bad behavior. I'm just not sure which of our analyses are correct yet, either. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: memory issue with nth
I also have this problem, unless I set my heap to be substantial - going up in increments of 128M, I need to have at least a 768M heap for this to not occur. That seems completely crazy, but the rest of you are saying you don't have this issue. Maybe it's time to start looking at what platforms we are running, and how much memory you have the JVM configured to use? If people have their heap set to be large enough, they might not realize this is happening, or if it is a bug on a subset of platforms, then that might explain it as well. I'm running on OS X Leopard, and I've tried both the 1.5 and 1.6 JVMs. I don't normally pass any non-standard memory size arguments to the VM unless I expect I'll need it for something I'm doing. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Running out of memory when using filter?
I'm continuing to try to suss this out, so I decided to run with a memory profiler. I'm seeing tens of thousands of lazy conses accounting for hundreds of megabytes of memory, which perhaps implies I'm holding on to a reference to them somewhere, but I just don't see how, since as I showed above, I am only referring to these sequences in the context of doseq. I'll post an update if I find a smoking gun. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
