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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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 #()
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
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
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
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
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
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
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
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
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)
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,
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
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
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 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
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,
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 --
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
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
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
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
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,
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
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
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
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
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
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
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
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
:
(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
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'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
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
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
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
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
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
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 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
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
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))
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
1 - 100 of 104 matches
Mail list logo
