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 su
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 p
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
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 o
This may be a dumb question, but is there a way to set up something like
this on my own server, without github ? Or is the code for the github
viewer in the project itself ?
These notebooks look great! I'm really impressed by the work you've been
doing on this.
--
You received this message
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 mess
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 you
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 G
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 d
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 para
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 Nandi
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 constru
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
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 wrote:
> (let [type-pred #()
> bounds-check #()
> contact #()
> full-test
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
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 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
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 makin
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 wrote:
> Exception in thread "main" java.lang.IllegalArgumentException: No value
> supplied for key: 55298
>
> I have to say that this project uses a
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 ex
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
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 b
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 hav
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 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 b
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 tic
I haven't looked at the implementation, but presumably it's
"modifying" one collection, and iterating over the other. If you rely
on the documentation, that gives the implementors the freedom to do
something like swap which collection is iterated over, based on the
size (ie, if your operation is li
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 wrote:
> So... I tried, and failed
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-f
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:
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 multipl
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
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
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 wrote:
> On Thu, Feb 11, 2010 at 10:59 AM, Paul Mooser wrote:
>
> > I struggle fairly often with keeping clojure/co
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) a
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
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 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 receiv
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.pdf&pli=1
It actually mentions clojure briefly at the end, although I'm not
This is something I run into with executors in Java periodically - I
have never understood why there isn't a default implementation
provided which has a blocking queue for tasks which will block on
submission to the queue if it is full. If I'm not mistaken, the
default ones which use bounded blocki
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 wrote:
> I'm
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 wrote:
> On Mon, Nov 9, 2009 at 4:31 PM, Rock wrote:
> > I've been following this thread, and I must say I'
;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 wrote:
> I completely understand the difference between the ISeq interface, and
> the particular implementation (lazy-
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 sidestepp
iders this a bug.
On Nov 4, 5:47 am, Christophe Grand wrote:
> On Tue, Nov 3, 2009 at 7:27 PM, Paul Mooser 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
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 under
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
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
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 -- clear
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 co
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
>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
Group
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 ni
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 invocatio
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, se
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 t
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 tryin
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
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 expl
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 insi
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
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
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
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 wrote:
> Just to make me more enemies ;-), I would prefer, on the other hand,
> find-first over ffirst (I'm not that nostalgic o
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 wrote:
> Paul Mooser writes:
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" gro
Thanks, Christophe. Hopefully I'll have a chance to check it out this
evening.
On Mar 9, 10:29 am, Christophe Grand wrote:
> http://code.google.com/p/clojure/issues/detail?id=93
>
> Paul, you can experiment with the patch if you wish.
>
> Christophe
>
> Christophe Grand a écrit :
>
>
>
>
>
> > O
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 ce
I feel I should clarify that I'm not trying to argue that a cyclic
vector is a great idea - it is something something I was playing with
in the midst of solving an euler problem. What I'm more interested in
is the question of how to accomplish this sort of thing ("proxying" an
existing instance, i
t; 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 wrote:
>
>
>
> > I was playing a
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 obviou
Good point - I actually looked in Collections, but failed to look in
Collection itself.
On Jan 29, 3:55 pm, Kevin Downey wrote:
> actually rhickey showed up on irc and pointed something out:
> ...
--~--~-~--~~~---~--~~
You received this message because you are sub
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 impli
Additionally, I initially found (some #{:y} [:x :y :z]) to be
confusing. The documentation of "some" (and or, in turn) uses the
phrase "logical true" - I initially assumed this to mean actually
true, but I suppose what it means is "not false or nil".
In that case, it makes me think of the degener
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
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
I know this has been discussed on the list before to some extent, but
does clojure by default have any operations which actually do what
"contains?" sounds like it would do, for all collections? I know that
you can easily write something similar using "some", but often times
you just want to find
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)) (re
the program . . . instead of the
> REPL being the program.
>
> On Jan 10, 5:00 pm, Paul Mooser wrote:
>
> > 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
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"
wrote:
> I don't th
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
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
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 implementation
Sorry to resurrect this, but I noticed that there isn't an issue to
track this - is this something unlikely to be fixed officially for
1.0 ? The workaround you posted certainly works for me, but I just
wanted to make sure the actual core.clj filter implementation receives
the fix eventually.
On D
Bingo - that fixed it. Sorry I didn't check that earlier.
On Jan 1, 3:22 pm, Chouser 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 emai
>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 spec
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
e
On Dec 12, 3:15 pm, "Mark Engelberg" wrote:
>And in fact, it turns out that in those languages, uncached lazy lists end up
>rarely used.
Did you mean that the cached lazy lists are rarely used? Or does
everyone actually choose to use the cached ones?
--~--~-~--~~~---
On Dec 12, 6:37 am, Rich Hickey wrote:
> I'm appreciate the time you and others have spent on this, and will
> improve filter, but I'm not sure where you are getting your
> presumptions about lazy sequences. They are not a magic bullet that
> makes working with data bigger than memory transparent
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@googl
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, sen
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. D
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
1 - 100 of 118 matches
Mail list logo
