If you want complete, detailed doc strings for all of Clojure and its
libraries, I am sorry to say I do not have that for you.
I do have detailed doc strings for a small fraction of the Clojure symbols
(20 out of 591), and am planning to write more as I have time.
If you want to use them from a
Andrey:
I am no lawyer, but the following answer on this QA page about the Eclipse
Public License suggests that if you take code from an EPL-licensed project
(which java.jdbc is), then the project in which you include it must also be
licensed under the EPL (whch clj.jdbc is currently not, as far
You might be hitting a bug in Clojure 1.5.1 where it incorrectly attempts
to access elements in an empty stack trace, which I have seen occur. This
should be fixed in Clojure 1.6.0 alpha releases:
http://dev.clojure.org/jira/browse/CLJ-1102
Andy
On Tue, Dec 17, 2013 at 9:14 AM, Dmitry Groshev
Most often, you don't add type hints to code you :use or :require. You
disable the warnings, or accept that you will see a slew of them, or if you
only want to see them in your own code but not in libraries you use, remove
:warn-on-reflection true from your project.clj, and edit your source files
Mark Engelberg's Instaparse most likely does not have the same feature set
as Regexp::Grammars (I haven't checked in enough detail to learn the
differences), but they do likely have features in common:
https://github.com/Engelberg/instaparse
Andy
On Mon, Jan 6, 2014 at 9:04 PM, gvim
.
Go squash some bugs!
Andy Fingerhut
--
--
You received this message because you 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
Sean:
Eastwood's current use of :arglists for :wrong-arity linter checking is
definitely 'at odds' with the way java.jdbc and some other libraries use it
for clearer documentation of fn/macro args.
I would recommend leaving :arglists as-is for java.jdbc, and wait for the
next version of Eastwood
Nicola can answer more authoritatively, as I haven't checked that part of
tools.analyzer recently, but I am pretty sure that the :arglists with
things like doc-string? attr-map? are simply treated as if they were normal
positional arguments, with no 'guessing' that they are optional due their
:
Interesting - but there must be some sort of magic there since otherwise
every call to defn would be flagged, since its :arglists implies it has 6
arguments. And in fact, there's nothing there indicating that the body is
in fact the body.
On 14 January 2014 18:56, Andy Fingerhut andy.finger
There is this list of Clojure user groups:
http://dev.clojure.org/display/community/Clojure+User+Groups
You can go to meetup.com and search for Clojure. There are several
meetings per month in the Bay area, in San Francisco and San Mateo, usually.
There is also the #clojure IRC channel, which
Why did you add that to your repositories?
You can do 'lein install' to install a project into your local Maven repo,
and by default Leiningen will check for local copies of JARs in your local
Maven repo before going out to the Internet to look for them.
Andy
On Thu, Jan 23, 2014 at 9:35 AM,
Banned from the Clojure group for reason of spamming.
Andy
On Thu, Jan 23, 2014 at 1:11 PM, Sean Corfield s...@corfield.org wrote:
This company has been spamming various technical lists lately with this
same generic promotion. Can a moderator please report them for spam and ban
them?
As Jim already mentioned, you can use == to compare numbers for equality,
but you must be cautious with equality for floating point numbers, as the
tiniest bit of roundoff error will cause = and == to be false for such
comparisons.
For =, there are effectively 3 'categories' of numeric values in
There *is* a first post moderation policy in place for this group -- it has
been in place for years, I think. I have been a moderator for over a year
now.
There are many moderators. It only takes 1 moderator to OK a message for
it to be posted. This may be a case of moderator education on
It is defined in the project 'reply', used by Leiningen for 'lein repl'
tasks:
https://github.com/trptcolin/reply
That in turn depends upon a cd-client library for sending requests to the
clojuredocs.org web site and doing some parsing on the responses received:
easy way I've missed to figure this sort of thing out in the
future?
On Tue, Jan 28, 2014 at 10:34 AM, Andy Fingerhut andy.finger...@gmail.com
wrote:
It is defined in the project 'reply', used by Leiningen for 'lein repl'
tasks:
https://github.com/trptcolin/reply
That in turn depends
://dev.clojure.org/display/design/Better+hashing
Andy
On Sat, Nov 2, 2013 at 9:44 AM, Andy Fingerhut andy.finger...@gmail.comwrote:
A few minutes ago I finished copying, pasting, and doing a little
reformatting on Mark Engelberg's document on the subject.
http://dev.clojure.org/display/design
While most of the functions and macros in Clojure core with a ? at the end
take 1 arg, there are several that take two:
contains? every? extends? identical? instance? not-any? not-every?
satisfies?
That list might not be complete. But you would not be breaking any
traditions I know of to have
I tried to reproduce this behavior with the following environment, and
didn't get this error. You may want to provide similar information for
your environment in case it helps someone else track down the problem:
Mac OS X 10.8.5
Oracle Java 1.7.0_15
Clojure 1.5.1
Leiningen 2.3.4
The following in
You may also use a let form wrapped around your entire defproject if you
want to avoid the duplication of code present in your example.
Andy
On Fri, Feb 7, 2014 at 8:22 AM, Lee Spector lspec...@hampshire.edu wrote:
On Feb 5, 2014, at 11:42 PM, Michał Marczyk wrote:
This returns
This might be too detailed a point, but I wanted to mention that while you
will always get the same order for the same collection (same as determined
by identical?, or Java ==, i.e. it is the same object in memory), you are
*not* guaranteed to get the same order for collections of the same type
It is working as designed.
If you do not want this, consider using sorted sets / sorted maps, where (=
s1 s2) implies (= (seq s1) (seq s2)).
Or, perhaps another programming language would be more to your liking.
Andy
On Sat, Feb 8, 2014 at 4:10 PM, Andy C andy.coolw...@gmail.com wrote:
Alex's suggestion is a good way to determine whether the 10k clj-tuples in
a set case is being sped up by the new hash function -- just look at the
variety of values of (hash x) for all x's in the set and see whether it is
significantly more unique hash values in 1.6.0-beta1 than with 1.5.1.
As
I am not sure about ClojureScript, but in Clojure/Java you can use
alter-var-root to change the definition of load-libs, which is called by
both require and use. You can use alter-var-root to change the definition
of any function you want in clojure.core or any other namespace. I
wouldn't
Have you looked at core.rrb-vector, which implements Relaxed Radix Trees
for vectors that implement subvec and concatenating two arbitrary vectors
in O(log n) time?
https://github.com/clojure/core.rrb-vector
Unless I am missing something, the fast concatenation is what you are
trying to
There are likely to be common ways of writing data transforms that happen
to return the same identical object as they were given, because
'primitives' like assoc often do.
I don't know of anyone who intentionally relies upon this behavior for
correctness of their code, and would strongly advise
transformed data structure is identical to the
original, but a large fraction of the sub-structures are, so if you do a
diff like comparison of an older structure and a newer one, you will find
many identical sub-structures.
Andy
On Wed, Feb 26, 2014 at 6:14 PM, Andy Fingerhut andy.finger
Anyone who has a good working example of this can add it to
clojuredocs.orgin a few minutes, if they are so inclined:
http://clojuredocs.org/clojure_core/clojure.core/case
I know that within 5 seconds of reading this one or more people will
complain that the site is out of date. It is true
What your code is doing is sometimes called bashing transients in place.
See some discussion here:
http://clojuredocs.org/clojure_core/clojure.core/assoc!
As explained there, you should always use the return value of assoc!, just
as you would always use the return value of assoc.
Andy
On Thu,
The Clojure lint tool Eastwood (https://github.com/jonase/eastwood) uses
this {:declared true} metadata to distinguish between a declare followed
later by a def on the same var (no warning) from a def followed later by
another def on the same var (when it issues a warning).
declare is also an
That is true for maximum matching (weighted or not) in bipartite graphs.
Max (weighted) flow methods do not work for matchings in general graphs.
Andy
On Tue, Mar 18, 2014 at 9:31 AM, Jason Felice jason.m.fel...@gmail.comwrote:
I thought matching was a dual of max flow, so weighted matching
discovered, and their
causes documented, while testing Eastwood on most of the Clojure contrib
libraries, Clojure itself, and over 35 other open source libraries.
Go squash some bugs!
Andy Fingerhut
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post
Regarding Michal's comment of using BST (binary search tree)-based
dictionaries, Clojure does already have sorted-maps and sorted-sets that do
this, for comparable keys/elements.
A nice hybrid of the nearly-O(1) typical case of hash maps/sets, and
simultaneously protecting against the cases where
In case it isn't clear, I don't think such drastic changes could ever hope
to be done in a reasonable time frame for Clojure 1.6.0. Probably better
to have a different thread for this if there is interest in discussing it.
Andy
On Thu, Mar 20, 2014 at 10:03 AM, Andy Fingerhut
andy.finger
:
clojure.tools.analyzer, being replaced by:
#'clojure.tools.analyzer.utils/record?
We've had to disable :wrong-arity due to our use of java.jdbc / congomongo
but our code - including all our Expectations tests - is clean of lint
otherwise!
Sean
On Mar 20, 2014, at 8:02 AM, Andy Fingerhut
I haven't read all of your code, but note that the Haskell algorithm says
it takes a sequence of random values where the first is in the range
[0,n-1], the second in the range [0,n-2], third in [0,n-3], etc. Your
repeatedly call here:
That is odd. This is a shot in the dark, and probably unhelpful because I
do not know a good way to verify whether my guess is true, but perhaps the
seqFrom method went from being small enough to be inlined by your JIT
before that change, to being too large to consider for inlining after the
The version published at http://clojure.org/cheatsheet has been updated to
the latest version, with new functions and macros added to Clojure 1.6
marked with (1.6) before them.
There is a link near the top of that page Download other versions with
tooltips that links to a page with several other
One argument for default value of *print-length* being nil: Plenty of
people print Clojure data structures to files and later read them back in.
The data would be corrupted if *print-length* was a too-small numeric value
for your particular data. It might not be obvious until much later that
you
Back of the envelope meaning that you thought about the implementation and
are estimating, or you have measurements?
Either way, I agree that there are definitely use cases where non-lazy
processing can give performance improvements. Probably even relatively
common use cases.
Cases where lazy
the known issues in the README first.
Jonas Enlund, Nicola Mometto, and Andy Fingerhut
--
You received this message because you 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
Sorry I am not taking the time to try out the change for you and see
whether it makes the desired difference in performance happen, but I do
know that the ^double type hint on return values should be on the argument
vector, not on the var. So instead of your abs-diff, try this, and
similarly for
Paul, can you double-check the result you are getting from (format '%-9s'
12345) ?
For example, wrap it in a call to count, i.e. (count (format '%-9s'
12345)). I get the expected string back from format, and the expected
length of 11 characters, on all of these Clojure/JVM/OS combos I tested:
then?
On Sunday, 6 April 2014 13:42:40 UTC-6, Andy Fingerhut wrote:
Paul, can you double-check the result you are getting from (format
'%-9s' 12345) ?
For example, wrap it in a call to count, i.e. (count (format '%-9s'
12345)). I get the expected string back from format, and the expected
Forcing small bits of computation to be done in parallel using the tools
Clojure and the JVM have at hand, e.g. pmap, future, etc., which rely on
creating JVM Thread objects, tends to slow things down rather than speed
things up, because the extra overhead of creating threads and waiting for
them
/clojure.core/future
Andy
On Thu, Apr 10, 2014 at 4:35 PM, Cecil Westerhof cldwester...@gmail.comwrote:
2014-04-10 16:45 GMT+02:00 Andy Fingerhut andy.finger...@gmail.com:
Forcing small bits of computation to be done in parallel using the tools
Clojure and the JVM have at hand, e.g. pmap, future
I haven't used it myself, but noted that Alex Miller used
http://ohours.orgfor allowing others to schedule meetings with him.
Andy
On Fri, Apr 11, 2014 at 9:08 AM, Timothy Washington twash...@gmail.comwrote:
Hey Marcus,
If you have Google Calendars, you can use that, and invite people to
I don't have time right now to look at the details of your implementation,
but can answer at least one of your questions.
Clojure's normal PersistentHashMap data structure does create a new object
for every key you remove (with dissoc), add, or modify the value for (with
assoc). So if a single
://github.com/flatland/ordered
https://github.com/amalloy/ordered
Andy
On Mon, Apr 14, 2014 at 12:36 PM, Andy Fingerhut
andy.finger...@gmail.comwrote:
I don't have time right now to look at the details of your implementation,
but can answer at least one of your questions.
Clojure's normal
I have added a script that uses the Java version of the benchmark
programs to generate the large files that were in the distribution
file I gave a link to earlier, so it is much smaller. I've also
published it on github and added a COPYING file that makes the
licenses more explicit (revised BSD
I've got.
Thanks,
Andy
On Jul 30, 11:00 am, Andy Fingerhut andy_finger...@alum.wustl.edu
wrote:
I'm gradually adding a few more Clojure benchmark programs to my
repository here:
git://github.com/jafingerhut/clojure-benchmarks.git
The one I wrote for the reverse-complement benchmark is here
I like it. I can see significant use of these to help speed up some
of the benchmark programs I've been hacking on:
git://github.com/jafingerhut/clojure-benchmarks.git
and more importantly, that means they can be good in optimizing useful
code, too :-)
I was pondering this question If a pure
I was looking into the question raised in the Question about pmap
thread, and noticed that on my Mac and on a Linux virtual machine, a
recent git version of clojure (about 1 week old) seems to use more
parallelism in 'pmap' than its source code in core.clj would imply is
the intent. The code
Johann:
Could it be that your CPU has a single floating-point unit shared by 4
cores on a single die, and thus only 2 floating-point units total for
all 8 of your cores? If so, then that fact, plus the fact that each
core has its own separate ALU for integer operations, would seem to
explain
for chunked
collections. That's pretty quick and easy.
or
(2) modify the pmap implementation so that even if map optimized for
chunked collections, pmap doesn't use more parallelism than intended.
That would require a more significant code change in pmap.
Thanks,
Andy
On Aug 4, 1:31 pm, Andy
On Aug 5, 6:09 am, Rich Hickey richhic...@gmail.com wrote:
On Wed, Aug 5, 2009 at 8:29 AM, Johann Krausjohann.kr...@gmail.com wrote:
Could it be that your CPU has a single floating-point unit shared by 4
cores on a single die, and thus only 2 floating-point units total for
all 8 of your
On Aug 6, 4:53 am, Rich Hickey richhic...@gmail.com wrote:
On Aug 5, 10:10 pm, Luc Prefontaine lprefonta...@softaddicts.ca
wrote:
I like this very much... that's the kind of clever optimizations that
preserves Clojure principles and
can yield significant performance increases. This
On Aug 6, 3:28 pm, André Thieme splendidl...@googlemail.com wrote:
On 27 Jul., 23:26, AndyF andy_finger...@alum.wustl.edu wrote:
Hello Andy, could you please update the following table?
| sbcl | perl | ghc | java | clj
On Aug 6, 11:51 am, John Harrop jharrop...@gmail.com wrote:
Cache misses are a possibility; try the integer version with long, so the
size of the data is the same as with double.
The other possibility I'd consider likely is that the JDK you were using
implements caching in
On Aug 6, 6:49 pm, John Harrop jharrop...@gmail.com wrote:
On Thu, Aug 6, 2009 at 6:57 PM, Andy Fingerhut
andy_finger...@alum.wustl.edu wrote:
You are correct. I've updated that file:
http://github.com/jafingerhut/clojure-benchmarks/blob/bb9755bdeeccae8...
Could you post
On Aug 7, 6:17 pm, Sean Devlin francoisdev...@gmail.com wrote:
Ok, I need some help. I'm writing some tests for c.c.seq-utils, and I
ran into a problem defining a test for both shuffle and rand-elt.
Does anyone here have any experience writing tests for random
functions? Am I going to need
On Aug 7, 5:14 pm, John Harrop jharrop...@gmail.com wrote:
Your core loop seems to be:
(loop [zr (double 0.0)
zi (double 0.0)
zr2 (double 0.0)
zi2 (double 0.0)
iterations-remaining iterations-remaining]
(if (and (not (neg? iterations-remaining))
On Aug 8, 2:16 pm, John Harrop jharrop...@gmail.com wrote:
On Sat, Aug 8, 2009 at 5:23 AM, Mark Engelberg
mark.engelb...@gmail.comwrote:
On Fri, Aug 7, 2009 at 5:14 PM, John Harropjharrop...@gmail.com wrote:
(if (and (not (= 0 i)) ( (+ zr2 zi2 limit-square)))
I believe that
On Aug 10, 11:35 am, fft1976 fft1...@gmail.com wrote:
On Aug 10, 4:46 am, Jarkko Oranen chous...@gmail.com wrote:
I'm not going to start optimising,
Somebody'd better!
You always hear this dogma that one should write elegant code first
and optimize later, and when you do that, a few
On Aug 10, 2:19 pm, Jonathan Smith jonathansmith...@gmail.com wrote:
1.) use something mutable
2.) unroll all the loops (mapping is a loop)
3.) try not to coerce between seq/vec/hash-map too much.
in real world, stuff like the shootout is pretty useless, as generally
you'd reach for a
On Aug 10, 5:57 pm, Mark Engelberg mark.engelb...@gmail.com wrote:
Andy,
My understanding is that any double that gets stored in a vector or
map is boxed, and therefore, the vast majority of your double
conversions aren't really doing anything, because when you pull them
out of the vector
On Aug 10, 11:33 pm, Mark Engelberg mark.engelb...@gmail.com wrote:
On Mon, Aug 10, 2009 at 11:15 PM, Andy
Fingerhutandy_finger...@alum.wustl.edu wrote:
I suspect I'm doing something wrong in my mutable Java array
implementation, but I don't see what it could be.
There still seems to be
On Aug 10, 11:50 pm, Christophe Grand christo...@cgrand.net wrote:
Hi Andy,
On Tue, Aug 11, 2009 at 8:15 AM, Andy Fingerhut
andy_finger...@alum.wustl.edu wrote:
I've tried an approach like you suggest, using mutable Java arrays of
doubles, macros using aget / aset-double for reading
On Aug 10, 11:15 am, Christophe Grand christo...@cgrand.net wrote:
Hi Andy,
On Thu, Aug 6, 2009 at 7:40 PM, Andy Fingerhut
andy_finger...@alum.wustl.edu wrote:
Thank you, Christophe! I've been wanting to try those out.
I made changes to 3 lines of my Clojure program for the k
In case it matters to anyone, my intent in creating these Clojure
programs to compare their speed to others isn't to try to rip into
Clojure, or start arguments. It is for me to get my feet wet with
Clojure, and perhaps produce some examples that others can learn from
on what performs well in
On Aug 11, 4:27 pm, Stuart Halloway stuart.hallo...@gmail.com wrote:
If I am reading the README correctly, clj-8 is 10.8 times slower than
Java, but clj-9 does better: 3.2 times slower.
Stu
You are reading that correctly. My clj-9 wasn't created until after
fft1976's message starting this
On Aug 11, 2:36 pm, Aaron Cohen remled...@gmail.com wrote:
At that point is it possible you're just paying the price of
PersistentVector for the bodies vector? Does it improve much if you
change bodies to an array?
About 7% faster changing bodies to a Java array of java.lang.Object's,
each
My apologies for the noise if this is well known in the Clojure
community, but I'll ask anyway.
One of the tweaks to my Clojure benchmarks that people have suggested
for improving performance, and that does help, is changing some
function definitions to macros. This is in effect inlining those
I've got a Mac and I've set it up to run jvm 1.6.0 instead of 1.5.0,
but I think I've done it with 1.5.0 before, too. You should be fine
there. Also I have ant version 1.7.1, but again, probably not a show
stopper difference.
I put my clojure-contrib in a directory beside my clojure directory,
Oh, one more thing. If you have latest git clojure-contrib, I'd
recommend trying it with latest git clojure, too. Latest clojure-
contrib might not work with clojure 1.0.0.
Andy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
This is the same Clojure for Lispers talk with audio, and video of
slides, available on clojure.blip.tv, among others, from the September
2008 Boston Lisp meeting.
It has been uploaded to the files section of the group with this name:
clojure-for-lispers-transcript.txt
I've added a very few
If there is a better place to report things like this, let me know.
I've done some looking at how much memory various kinds of Clojure
data structures use, and come across some behavior that I think might
be a memory leak, in the sense that perhaps a reference to a
On Aug 15, 5:44 am, Christophe Grand christo...@cgrand.net wrote:
I wouldn't call this a memory leak: vectors have a bigger memory overhead
than before (additional PersistentVector$Node and AtomicReference).
On Sat, Aug 15, 2009 at 2:13 AM, Andy Fingerhut
andy_finger...@alum.wustl.edu
On Aug 15, 9:45 am, Nicolas Oury nicolas.o...@gmail.com wrote:
Thank you very much for your answers.
The syntax was difficult to guess.
Is there a general rule for forming the internal name of types?
It seems after a few tests that is is slightly slower (15-20%) than
making a final static
On Aug 17, 3:51 am, Christophe Grand christo...@cgrand.net wrote:
On Sat, Aug 15, 2009 at 4:23 PM, Andy Fingerhut
andy_finger...@alum.wustl.edu wrote:
Not to say this ought to be done, but would it be possible to have no
'edit' field *at all* for persistent data structures (not even
On Aug 19, 2:38 am, Christophe Grand christo...@cgrand.net wrote:
Imagine a persistent data structure S1 with a root node A and two child
nodes B and C.
On this data structure you call transient, make some updates and call
persistent! which yields an updated persistent data structure S2
Is there any reason to keep aset-* functions around in Clojure? I
guess backwards compatibility?
It definitely seems worth flagging them when *warn-on-reflection* is
true, in a similar way to other warnings it enables. Perhaps that
might be overloading the meaning of *warn-on-reflection*, but
On Jan 27, 8:21 pm, Scott sbuck...@gmail.com wrote:
wondering if I can please get some advice on how to improve the
performance of this piece of code
(defn select-n-tournament
[popu fit-fn n]
(let [k 7]
(take n (repeatedly #(first (sort-by fit-fn (take k (shuffle
popu))
)
An interest was expressed by a few in having a separate ClojureScript mailing
list.
If it is a Google group, that requires moderating messages sent to the group,
via manual approval. I suspect early on there will be many people posting to
the group for the first time that have long worked
., then it is not welcome
on the ClojureScript group. Please send it to the Clojure group instead.
If it is not specific to any one flavor of Clojure, but you prefer to send it
to the ClojureScript group, go right ahead, but realize that your audience may
be smaller than if you send it to the Clojure group.
Andy
CLJ-1098 fix committed to Clojure master today as part of 1.5.0-RC3:
http://build.clojure.org/job/clojure/changes
Andy
On Jan 14, 2013, at 4:24 AM, Wolodja Wentland wrote:
On Sat, Jan 12, 2013 at 08:15 -0800, Andy Fingerhut wrote:
The CLJ-1098 ticket was categorized as a minor
I do not know exactly what is going on, but suspect it is something to do with
conversion between float and double (or Java Float and Double).
Try replacing the argument 19.1 with each of these possibilities, and you
should see what I mean:
(double 19.1)
(Double. 19.1)
(float 19.1)
(Float
On Jan 20, 2013, at 7:11 PM, Andy Fingerhut wrote:
On Jan 20, 2013, at 7:49 AM, Anthony Grimes wrote:
In closing, I propose the following. If we're going to continuously deny
people things they are accustomed to, instead of treating them like angry
children having tantrums, why don't we get
This isn't what you are asking, but I wanted to make a comment that there is a
proposed patch to Clojure attached to ticket CLJ-904 that adds warnings to read
and read-string about how their behavior depends upon the value of *read-eval*:
http://dev.clojure.org/jira/browse/CLJ-904
Also,
Out of curiosity, I made a patch to Clojure that causes the default value of
*read-eval* to be false instead of true, to see if any of the tests pass, and
to let other people try it out in case it breaks things that would be
surprising and/or disruptive. It is attached to this new ticket:
Bug fixed in the forthcoming Clojure 1.5:
http://dev.clojure.org/jira/browse/CLJ-667
% java -cp clojure.jar clojure.main
Clojure 1.5.0-master-SNAPSHOT
user= (try nil (finally (doseq [x (range 10)] (println x
0
1
2
3
4
5
6
7
8
9
nil
Andy
On Jan 30, 2013, at 8:42 AM, nick rothwell
Josiah mentioned requesting a free trial of the ZIng JVM. Did you ever get
access to that, and were able to try your code running on that?
Again, I have no direct experience with their product to guarantee you better
results -- just that I've heard good things about their ability to handle
Roger, tryclj.com is limited in what it can do. The Clojure code you type in
there is running on the web server across the network from you, not on your own
local machine. That file isn't accessible there.
Also for that reason many symbols are not allowed to be used in tryclj.com
Can you post a larger chunk of code for us to examine, perhaps on github or as
a gist if it is over 30 lines of code or so? Many of us have had good success
with eliminating reflection using type hints, so it should be possible to make
it work.
Andy
On Feb 3, 2013, at 12:50 PM, Kanwei Li
I was able to open an X windows emacs session using:
(require '[clojure.java.shell :as sh])
(sh/sh emacs)
on my system. The REPL did not give another prompt until I quit that emacs
invocation. I was able to get another REPL prompt immediately using this:
(future (sh/sh emacs))
can't be
resolved.
Reflection warning, NO_SOURCE_PATH:29 - reference to field newLine can't be
resolved.
Reflection warning, NO_SOURCE_PATH:20 - reference to field newLine can't be
resolved.
Thanks!
On Sunday, February 3, 2013 4:38:38 PM UTC-5, Andy Fingerhut wrote:
Can you post
You can create a ticket for java.jdbc here if you wish that describes the
problem and what you think will fix it. Then any of the 500+ Clojure
contributors can take a shot at fixing it:
http://dev.clojure.org/jira/browse/JDBC
Andy
On Feb 5, 2013, at 7:07 PM, a...@bitlimn.com wrote:
Hey
clojure.set/intersection is documented to work on input sets. In Clojure,
all sets are finite. (range) is a lazy sequence, which isn't a set. You could
attempt to make a set out of it with (set (range)), but that won't work because
it will try to consume the entire unending sequence.
I
That is nowhere near the Clojure group's 7000+ members, but it is a good start
for only existing since Jan 23.
Don't worry, I won't mention its existence here every 2 weeks. I will in
another 6 months or so, as a note to any new Clojure group members who are
especially interested in
Following up on the thread *read-eval* vulnerability, I started writing some
documentation for how to read Clojure data safely. That isn't ready yet, but
before I get the time to finish that I wanted to quickly get out a warning that
is obvious to some, but probably not all:
NEVER use
1 - 100 of 890 matches
Mail list logo
