I am pretty sure that there is nothing in the Clojure compiler that pays
attention to the key :internal in metadata.
People can put whatever metadata they want anywhere they wish, even if the
Clojure compiler ignores it. This looks like some metadata specific to
pallet, but not sure whether it us
Just to clarify, Alex, since your idea of "next release" might be different
than those who aren't following Clojure 1.7 alphas/betas/etc. carefully.
Do you mean "hoping to look at it for Clojure 1.8, since Clojure 1.7 is to
the point of primarily fixing critical bugs and regressions" ?
Andy
On F
James, are you saying that with such a core.typed annotation for function
available in that example, that it would give a warning if available or any
of the functions it calls accesses any keys other than :stock and :reserved
?
If so, that is quite impressive.
Andy
On Fri, May 8, 2015 at 10:36 A
I am not aware of any JIRA ticket for this, but there could be one lurking
there somewhere.
Here is a link to a previous discussion about it on this group:
https://groups.google.com/d/msg/clojure/r_ym-h53f1E/y1S31QXNhcAJ
Andy
On Fri, May 8, 2015 at 9:26 AM, Leon Grapenthin
wrote:
> Do you have
You can find a link to the JIRA bug tracker for most or all Clojure contrib
libraries on their corresponding github pages, and Google is pretty good at
finding those. Here is java.jdbc's: http://dev.clojure.org/jira/browse/JDBC
Andy
On Thu, May 7, 2015 at 6:44 PM, Alain Picard wrote:
> Dear fe
On Wed, May 6, 2015 at 1:27 PM, Fluid Dynamics wrote:
> On Wednesday, May 6, 2015 at 3:15:53 PM UTC-4, Andy Fingerhut wrote:
>>
>>
>> The "rough edges" show up on a lot of things in the Clojure ecosystem. I
>> know I suck at documentation which is why I moved
First some facts, without any evaluation:
There are only a handful of people in the world with authorization to edit
pages on clojure.org. I would guess maybe only 5.
Far more have authorization to edit the wiki pages on dev.clojure.org --
hundreds, I think. A subset of those who have signed a
The Eastwood [1] Clojure lint tool has a few warnings in it that warn about
unused metadata in your code.
The :unused-meta-on-macro warns about metadata on macro invocations, which
is usually ignored by Clojure [2].
The :wrong-tag warns about unused type tag metadata on Vars, and
non-fully-qualif
Permissions bumped up on your JIRA account named 'jwhitlark'.
Andy
On Sun, May 3, 2015 at 3:17 PM, Jason Whitlark wrote:
> I've got a CA on file since the early days, but *ahem* hadn't made any
> contributions. I don't have the jira-developers permission which seems to
> be needed to change fi
On Sun, May 3, 2015 at 2:37 AM, gvim wrote:
> On 03/05/2015 05:24, Sean Corfield wrote:
>
> Perfection is the enemy of the good (Gustave Flaubert).
>>
>
> "The whole is greater than the sum of its parts." (Aristotle)
>
> gvim
“What you're supposed to do when you don't like a thing is change it
I am not sure why you say "new primitive type hints". Primitive type hints
have been around for several Clojure released versions, 1.6.0 and earlier.
The error you are seeing is because of a property of the Clojure compiler
that as far as I know is not documented. I asked back in Nov 2014 whethe
Most of Clojure's collections already can hold arbitrary type values inside
of them, with no additional work required, whether those types are built
into Clojure or not. That is because most collections treat all contained
items as Java Object references.
The only exceptions I can think of are th
gt;
> On Monday, April 27, 2015 at 12:45:46 PM UTC-4, Andy Fingerhut wrote:
>>
>> Unless the Java Math library handles complex types already, I don't know
>> of any way to extend it in a way that would let you get the answer you want
>> from (Math/abs my-complex-nu
Unless the Java Math library handles complex types already, I don't know of
any way to extend it in a way that would let you get the answer you want
from (Math/abs my-complex-number) in Clojure.
If you want code that gives the correct answers, a library using vectors or
maps for complex numbers ca
On Wed, Apr 22, 2015 at 9:25 AM, Maik Schünemann
wrote:
> Andy Fingerhut writes:
>
> > As a silly example, if one gets to define their own equals for lists,
> > and you decide to define lists as equal if they contain the same
> > number of items, e.g. the list (1 2 3) i
u rearrange or filter or map
> they can be pure. But if you *implicitly* add new information - as (seq
> set) does - then they cannot be.
>
> Dave
>
> On Wednesday, 22 April 2015 15:28:30 UTC+10, Andy Fingerhut wrote:
>>
>> One thing I was surprised by in my investigat
If you are looking for a guarantee in the documentation that this will
never happen in the current version of Clojure, and it is promised never to
change in that way in future Clojure versions, then I don't see anything in
the documentation that would give that guarantee.
If you are looking for a
formative
>>> and to have good background sources.
>>>
>>> I certainly never thought about this sneaky behavior concerning `seq`
>>> and hash sets before now. I'll have to look out for that one!
>>>
>>> On Tuesday, April 21, 2015 at 8:13:4
I had come across the issue of Clojure hash sets that contain the same set
of elements returning their elements in different orders from each other,
depending upon which order they were added to the set (only if they have
equal values for (hash x)).
This and other questions on referential transpar
Looks like a bug in kibit. I'd recommend filing an issue on Github:
https://github.com/jonase/kibit/issues
Andy
On Tue, Apr 21, 2015 at 1:33 AM, Cesare wrote:
> Hi Daniel,
> thanks a lot for this great plugin!
>
> I've just run it on a project but I don't get this:
>
> Consider using:
> :p
And it assumes that they are _identical_ maps that you are calling keys and
vals on.
Equal (via =) not-sorted maps do *not* guarantee that they will have the
same seq order as each other, and in some cases do not, due to hash
collisions in hash maps having items in a linked list in whatever order
Your particular example is equivalent to #?(:clj) which is illegal, for the
reason given in the error message you saw.
Normal Clojure comments are far less surprising in their behavior than #_ is
I understand there can be convenience in using #_ when it works.
Andy
Sent from my iPhone
> On Ap
I have bought books while in beta version from Pragmatic Programmers
before, and they always sent me email whenever the book had an update to
its content (I ordered the book on their web site, so they had my contact
info).
Andy
On Mon, Apr 13, 2015 at 7:40 AM, Jonathon McKitrick
wrote:
> Will w
This may not find any relevant problems, but if you try running the latest
version of Eastwood on your project [1], it can detect the following kinds
of issues that might be causing problems:
* mismatches between namespace names, and the file names they are stored in
[2]
* :require or :use clauses
There are some subtle exceptions (e.g. don't mix Java mutable maps and
Clojure immutable maps), but if they are all immutable, and you don't mix
floats and doubles in there anywhere, and you don't use Double/NaN 'values'
anywhere, and probably a couple other minor caveats I am forgetting right
now,
I believe that change is due to this commit from early March 2015:
https://github.com/clojure/clojure/commit/692645c73c86d12c93a97c858dc6e8b0f4280a0b
Nicola Mometto had opened a ticket CLJ-1593 for this issue:
http://dev.clojure.org/jira/browse/CLJ-1593
The commit did not reference the ticket, but
On Sat, Apr 4, 2015 at 8:52 AM, Paul Roush wrote:
> I have 2 questions related to bigints.
>
> 1) I've read things suggesting Clojure auto-converts between int, long,
> and bigint to prevent overflow. That isn't the behavior I've experienced.
> Did something change from an older release of Cloju
If your goal is to learn Clojure, I would recommend not learning Emacs Lisp
at the same time, just to avoid confusion that may arise in your mind due
to the differences between the two.
You can use Emacs without learning Emacs Lisp with no problem. I've used
Emacs for 20 years, and only know a li
Dependency isolation without isolated class loaders or source rewriting
would be interesting, but how would you propose to achieve dependency
isolation without using either of those techniques?
Or perhaps a solution where the module system did the source level
rewriting for you 'under the hood' wo
Wow, I am amazed you are working to keep compatibility with Clojure 1.2 :-)
Andy
On Fri, Mar 20, 2015 at 2:55 PM, Mark Engelberg
wrote:
> Wow, I had forgotten how much had changed from Clojure 1.2 to 1.3 and
> beyond. There were three separate incompatibilities with 1.2.
>
> I have addressed t
Created a ticket: http://dev.clojure.org/jira/browse/CLJ-1678
It appears there is no bug here. Some Clojure tests were written with
particular constants that have equal .hashCode values, to test Clojure's
code generation for case expressions when hashCode values collide.
Somewhere between IBM JDK
.
Andy
On Wed, Mar 18, 2015 at 8:40 PM, Andy Fingerhut
wrote:
> Clojure is regularly built and tested with the following JVM versions, as
> you can find out here:
> http://build.clojure.org/view/Clojure/job/clojure-test-matrix/
>
> Sun JDK 1.6
> Oracle JDK 1.7
> Oracle JDK 1.8
&g
I don't know if it is a more elegant implementation, but I found something
like this for maps in the useful library a while back, called ordering-map:
https://github.com/amalloy/useful/blob/master/src/flatland/useful/map.clj#L243-L245
I have been putting a few different varieties of sorted maps
Clojure is regularly built and tested with the following JVM versions, as
you can find out here:
http://build.clojure.org/view/Clojure/job/clojure-test-matrix/
Sun JDK 1.6
Oracle JDK 1.7
Oracle JDK 1.8
IBM JDK 1.6
OpenJDK 1.6
I believe a JIRA ticket would be appropriate. The core team can decide
Christopher:
I think considering autodoc to be no longer maintained because the last
commit was Sep 1 2014 might be a bit hasty. No commits can mean "stable
and working", too, not only "abandoned".
Tom Faulhaber commits updates to the published Clojure API docs for Clojure
itself and its contrib
The email they use to correspond on this group are:
David - dnolen.li...@gmail.com
Nicola - brobro...@gmail.com
Daniel (GSoC organizer for Clojure), would there be any objection to
including email addresses of mentors on the Clojure GSOC 2015 projects
page? The question of what to do if someone
Clojure has been accepted as a mentoring organization for GSOC 2015,
announced by Google yesterday.
I'd recommend contacting the mentors, David Nolen and Nicola Mometto,
directly. The email they use to correspond on this group are:
David - dnolen.li...@gmail.com
Nicola - brobro...@gmail.com
And
Shubham:
Yes, Google has released its list of mentoring organizations for GSOC 2015,
and Clojure has made it on the list again:
http://www.google-melange.com/gsoc/org/list/public/google/gsoc2015
The list of proposed projects are here:
http://dev.clojure.org/display/community/Project+Ideas
The on
Not every function and macro is documented completely or accurately on
ClojureDocs.org, but I would recommend checking it out when you run across
something that looks amiss, and see if the examples mention what you are
seeing. In this case, it does:
http://clojuredocs.org/clojure.core/printf
And
If (text ...) is an invocation of a macro, not a function, then that type
tag is most likely silently ignored by the Clojure compiler, not hurting
anything, but not helping anything, either.
Eastwood [1] can warn you about such useless type tags in your Clojure
code, via the :unused-meta-on-macro
One way to get 1.7.0-master-SNAPSHOT into your local Maven repo in your
$HOME/.m2 directory is to do these commands to build it yourself and
install it there:
# First command creates a clojure directory, and subdirectories beneath
that.
git clone git://github.com/clojure/clojure.git
cd clojure
# m
Oh, and the page of examples for 'for' has more examples of :when and
:while that work similarly to doseq, and may be more informative:
http://clojuredocs.org/clojure.core/for
On Wed, Feb 25, 2015 at 9:14 AM, Andy Fingerhut
wrote:
> doseq does not have anything precisely like C/Jav
doseq does not have anything precisely like C/Java/Perl/etc.'s 'break' or
'continue'. The closest thing might be the :while keyword. You can see
some one example of its use near the end of the examples on this page:
http://clojuredocs.org/clojure.core/doseq
The best way I know to get such behavi
I may have the name of that library incorrect. I was going through
messages to the Clojure group from new senders. I saw this message, and
was intending to approve it, but accidentally hit the 'report as spam and
block the sender' button. Ugh. My apologies. If you were the sender, and
you are
different 'diff' in each of these cases,
such that the 'receiver' can end up in the same final state, for each of
these case?
Or perhaps the idea is that some of those are not supported?
Thanks,
Andy
On Fri, Feb 20, 2015 at 8:13 PM, Timothy Pratley
wrote:
> Hi Andy,
other state? That is, how would it know it needs to change the value
associated with :x to {} as opposed to removing the key :x and its value
entirely?
Andy
On Fri, Feb 20, 2015 at 5:34 PM, Timothy Pratley
wrote:
> On Fri, Feb 20, 2015 at 4:40 PM, Andy Fingerhut
> wrote:
>
>> Why
Timothy, I probably haven't thought about this carefully enough yet, but
why do you expect the return value to be ({:x {:y 1}} nil nil) in your test
case?
Why not ({:x {:y 1}} {:x {}} nil) ?
Andy
On Fri, Feb 20, 2015 at 4:13 PM, Timothy Pratley
wrote:
> Alex/Rich, if a patch is welcome for th
You could build your own patched version of Clojure, with the proposed
patch from the ticket, and use that. If you try that, it would be good to
add a comment to the ticket of whether it fixed the problem for you, too.
Note: I fully understand if you'd prefer not to do this. Simply giving
anothe
On Thursday, February 19, 2015 at 1:02:53 PM UTC-5, Andy Fingerhut wrote:
>>
>> I haven't checked carefully, but from at least a quick look it appears
>> that implementing the NavigableMap and NavigableSet interfaces could be
>> done by using the existing subseq and rsub
I haven't checked carefully, but from at least a quick look it appears that
implementing the NavigableMap and NavigableSet interfaces could be done by
using the existing subseq and rsubseq functions in clojure.core?
It doesn't give you access to subtree nodes directly, but perhaps it is
sufficient
There is a significant advantage to Francis's version when keys or values
in the map are collections that flatten flattens:
;; Most likely not the behavior you want:
user=> (flatten (seq {:colors ["red" "blue"] :cursor-set #{"pointer"
"hand"}}))
(:colors "red" "blue" :cursor-set #{"hand" "pointer
Laziness is pervasive in Haskell, for all computation (unless you force it
off with special constructs).
Laziness in Clojure is as pervasive as sequences, but it is not for all
computation like in Haskell, and sequences have the previously-mentioned
features of sometimes-more-eager-than-the-minimu
Or perhaps 1.7.0-alpha5 has a change vs. 1.6.0 that makes this code work by
accident.
Using lazy sequences to define later elements in terms of the prefix of the
sequence up to that point has come up multiple times, usually with the
example of generating primes (but different code each time).
I d
Sam:
I believe if you proceed to do the following in your REPL:
(in-ns 'monger.collection)
(doc update)
You will see that the name 'update' _from within the namespace
monger.collection_ refers to monger.collection/update, not
clojure.core/update.
That is what the message is intended to convey.
There are multiple links in the Clojure cheat sheet here:
http://jafingerhut.github.io/cheatsheet/clojuredocs/cheatsheet-tiptip-cdocs-summary.html
that go to clojure.org/somewhere#some-anchor
For example, in the "Special Forms" section, and the sub-section "Binding
Forms / Destructuring", there
Probably it was simplicity of coding, but that is just my guess.
There is a ticket open for Clojure suggesting reducing the number of calls
to the function. You, and anyone else who would like to see this changed
in the future, are welcome to vote on this ticket.
http://dev.clojure.org/jira/brow
the top of http://clojure.org/cheatsheet
Andy
On Thu, Feb 5, 2015 at 3:20 PM, Bruce Wang wrote:
> There are http://cljs.info/cheatsheet/
>
> from the commit logs on https://github.com/oakmac/cljs.info it's less
> than 4 days old
>
> On Fri, Feb 6, 2015 at 5:22 AM, gvim
> On 05/02/2015 17:04, Andy Fingerhut wrote:
>
>> Thanks to Alex Miller, who has updated the cheat sheet version published
>> at http://clojure.org/cheatsheet
>>
>> It was updated from v13 to v21. If you are curious what changes have
>> been made between those v
Thanks to Alex Miller, who has updated the cheat sheet version published at
http://clojure.org/cheatsheet
It was updated from v13 to v21. If you are curious what changes have been
made between those versions, you can read the change log here:
https://github.com/jafingerhut/clojure-cheatsheets/blo
Eduardo:
This is due to the weirdness in Java, and Java's own documentation
recommends against using the Boolean class constructor. See the discussion
at this link for more details:
http://clojuredocs.org/clojure.core/if
Andy
On Tue, Feb 3, 2015 at 3:16 AM, Eduardo Aquiles Affonso Radanovitsck
double 1.5))
true
user=> (>= (float 1.5) (double 1.5))
true
user=> (= (float 1.5) (double 1.5))
false
That certainly flies in the face of what most people learned in math class.
Andy
On Fri, Jan 23, 2015 at 9:29 AM, Michael Gardner
wrote:
> On Jan 23, 2015, at 8:23 AM, Andy Fingerhut
Michael:
You can try creating a JIRA ticket suggesting that Clojure's = should
return false when comparing floats and doubles to each other. I have no
idea if it would go anywhere, but alternative (2) trying to get hashes to
be equal between = float/doubles has been suggested and declined. Witho
Part of what you wish were true is already true: Using = to compare a
double to a BigDecimal always returns false in Clojure, as does comparing a
float to a BigDecimal.
It is only (= float-value double-value) that can return true in Clojure,
even though hash does not guarantee the usual hash consi
ways as true, if they're
> nominally the same value.
>
> Regards
>
> Plínio
>
> On Thu, Jan 22, 2015 at 12:18 PM, Andy Fingerhut > wrote:
>
>> "It is out of scope for Clojure to fix this for Java types Float/Double"
>> -- comments in CLJ-1036: htt
"It is out of scope for Clojure to fix this for Java types Float/Double"
-- comments in CLJ-1036: http://dev.clojure.org/jira/browse/CLJ-1036
Andy
On Thu, Jan 22, 2015 at 5:53 AM, Nicola Mometto wrote:
>
> Not sure if this is intended behaviour:
> user=> (= (float 1.6) (double 1.6))
> false
>
I agree that tools.reader is probably the best way to go.
The following note is off the top of my head without double-checking the
details, so please take it with a bit of "needs verification of details"
thought.
Even with tools.reader, I believe you either need to eval ns forms, or do
your own p
nsidered a regression or not, it's not up
> to me to decide. I suggest opening a ticket in JIRA to discuss this
> further.
>
> Nicola
>
> Andy Fingerhut writes:
>
> > I can reproduce this. I have also determined that the change in behavior
> > is due to th
I can reproduce this. I have also determined that the change in behavior
is due to the patch applied for ticket CLJ-1544 [1] [2]. There doesn't
appear to be an actual dependency cycle in the manifold lib, but I've only
looked at this for a few mins.
Andy
[1] http://dev.clojure.org/jira/browse/C
Nicola, Sean:
I am _not_ testing with Sean's code, so can't comment whether my results
will correspond with his.
I have found that between Clojure 1.7.0-alpha4 and 1.7.0-alpha5, and the
latest Eastwood version 0.2.1 released, I get an exception trying to lint
the namespace clojure.reflect in Cloj
I have not used it, but from the docs it appears there is at least some
overlap with this library:
https://github.com/qerub/camel-snake-kebab
It mentions in its docs that it avoids using regex's.
Andy
On Tue, Jan 6, 2015 at 11:25 AM, Noam Ben-Ari wrote:
> Hi,
>
> I've written a small libr
Possibly the most relevant Clojure ticket in JIRA related to your question
is: http://dev.clojure.org/jira/browse/CLJ-394
If you click the "All" tab at the top of the comments, you can see a more
full history of the changes made to the ticket's description over time.
When it was originally created
The "Clojure JIRA Workflow" page you linked to has several links on it to
'saved JIRA searches', which show only JIRA tickets matching specific
criteria. In the "Dev patch" section there are ones for all "Needs a
patch" tickets, for example, or all "Incomplete" tickets. For writing
patches, the "
, Laurent Petit, and other
contributors. See [2].
Below are some of the changes since version 0.2.0. A complete list is
at [3].
Go squash some bugs!
Jonas Enlund, Nicola Mometto, and Andy Fingerhut
[1] https://github.com/jonase/eastwood
[2] https://github.com/jonase/eastwood#editor-support
[3
I know it can be a pain, but a sample project on GitHub, or a zip/tar file
of the project, plus info like: OS version, JDK version, and sequence of
commands run after creating the repo that lead to the error, preferably
reproduced 100% or reasonably large fraction of the time, can make the
differen
Searching for "unknown constant tag" in the Clojure Google group finds a
few conversation threads mentioning it from several years ago. I don't
recall any tickets for it. From reading some of the discussion threads, it
sounds like there may never have been a cause identified. Also, perhaps
occur
I have just been working for the last day on adding code to the Eastwood
Clojure lint tool [1] for checking these and a few other things about wrong
ns forms. The documentation I just wrote for what it will do is here [2].
No released version of Eastwood makes these checks yet. I will probably
r
latest stable release. It will need to change
over time, but not very often (maybe once or twice a year, if the past few
years is an accurate predictor).
Andy
On Mon, Dec 8, 2014 at 7:00 PM, Andy Fingerhut
wrote:
> I can't state authoritatively why, but here is some evidence:
>
>
I can't state authoritatively why, but here is some evidence:
1.1.x and 1.3.x are identical to 1.1.0 and 1.3.0.
1.2.x and 1.5.x are equivalent to 1.2.1 and 1.5.1, respectively, which do
have a few bug fixes made after the 1.2.0 and 1.5.0 releases.
There were never any 1.4.x or 1.6.x releases for
are existing Clojure libraries that smooth some of this over
for the developer?"
Thanks,
Andy Fingerhut
On Mon, Dec 8, 2014 at 1:13 PM, Fluid Dynamics wrote:
> On Monday, December 8, 2014 4:01:28 PM UTC-5, Michał Marczyk wrote:
>>
>> On 8 December 2014 at 21:17, Fluid Dynamics wrot
In regards to your question "Why isn't this documented anywhere?", it is
documented somewhere -- in the documentation string for clojure.edn/read,
the very function you were attempting to use:
user=> (doc clojure.edn/read)
-
clojure.edn/read
([] [stream] [opts stream])
Re
As far as people making their own modified versions of Clojure to try these
things out, the clojure-android Google group is probably a good place to
find out, e.g. this thread:
https://groups.google.com/forum/#!topic/clojure-android/dJYfcRHekDw
I am not in the loop on Clojure core's precise plans
Lorentzz:
It might help to provide more information with your question. For example,
what file did you download, and from where, if any? What steps did you
try? What did you see?
Also, who you are referring to by "you" is not clear.
Please realize that a relatively small fraction of people wh
I don't have any speculation to give, but wanted to link to this recent
thread that has a few coments:
https://groups.google.com/forum/#!topic/clojure/cFT_sjb4Zx8
On Wed, Nov 19, 2014 at 5:36 PM, Jacob Goodson
wrote:
>
> http://opensource.com/business/14/11/microsoft-dot-net-empower-open-source-
Some mostly negative results: ClojureDocs.org is quick to search for
user-contributed examples, but in this case it is a toy example
demonstrating how it works, not when to use it:
http://clojuredocs.org/clojure.core/seque
crossclj.info has the ability to show you everywhere a function is used
f
a let binds values to symbols,
but those symbols are never used. Disabled by default.
Go squash some bugs!
Jonas Enlund, Nicola Mometto, and Andy Fingerhut
[1] https://github.com/jonase/eastwood#editor-support
[2] https://github.com/jonase/eastwood#whats-there
--
You received this message bec
Your description doesn't raise any particular issues in my mind, other than
a suggestion to try a JVM profiler to see if it helps you find anything,
e.g. free trial of YourKit.
Andy
On Mon, Nov 17, 2014 at 2:28 AM, Alexander L.
wrote:
> Hi all,
>
> I understand that the following question is a
Not idiomatic.
All Eastwood warnings except for one have some documentation explaining
what kinds of things they warn about, and sometimes why they warn about
them. The def-in-def warning documentation is available here:
https://github.com/jonase/eastwood#def-in-def
As it says there, def's i
Don:
You could try sending a message to the author of the Eclipse plugin (CC'ed)
about its documentation, and he may enhance it, e.g. a link to Leiningen's
home page, maybe with a sentence or two on what it does.
This web site may provide a better starting place, in particular the
"Getting Starte
At least in your particular case, replacing map with map2, defined below as
a small modification to a subset of map, seems to do the trick:
(defn map2 [f coll]
(lazy-seq
(when-let [s (seq coll)]
(let [r (rest s)]
(cons (f (first s)) (map2 f r))
(map2 count [(repeat 1e8 "stuff
In addition to the other suggestions, Clojure's with-local-vars may suit
your needs: http://clojuredocs.org/clojure.core/with-local-vars
On Sat, Nov 8, 2014 at 7:15 PM, Blake McBride wrote:
> Greetings,
>
> I have a sense that there is value in immutable variables and data but
> that value is un
Christian:
Try running 'lein deps :tree >& deps.txt' in each of those projects, and
diff them. I can't explain why the differences are there that exist, but
there are significant differences, including in version numbers of some of
the dependencies brought in.
Asking on the Leiningen email list
sked, sorry, there is still no way to annotate
expressions in your source code to disable linters for expressions that you
know are ok, while leaving the linter enabled in the rest of the code.
That is coming.
Go squash some bugs!
Jonas Enlund, Nicola Mometto, and Andy Fingerhut
--
You receiv
As Alex Miller mentioned earlier in the discussion (it can be confusing
with multiple subjects being discussed), the change that caused this
behavior was due to ticket http://dev.clojure.org/jira/browse/CLJ-1330
which has been reopened, and they plan to do something to improve the
situation in the
Christian, thanks for working on the enhancements.
It might be easiest to wait until the dust settles on the other big changes
in the works right now. You could also contact Herwig Hochleitner (
hhochleit...@gmail.com), who is developing those other data.xml changes,
and ask him if perhaps the po
stantially worse than String. With String I get
> about a 3.2X increase in memory footprint for this file, but with
> pjstadig.utf8 I get about 5X. Also, it's slower by orders of magnitude.
>
> On Tuesday, October 28, 2014 12:49:53 PM UTC-7, Andy Fingerhut wrote:
>>
>> S
I think root of the advice you are getting is "keep backups of important
files".
If you don't keep backups of important files, you are asking for trouble,
even if every piece of software on your computer has no bugs.
Andy
On Tue, Oct 28, 2014 at 2:14 PM, Fluid Dynamics wrote:
> On Tuesday, Oct
Sorry, no feedback on your attempt, but a note that you may want to check
out Paul Stadig's utf8 library to see if it serves your purpose. I believe
it should store text that fits within the ASCII subset into 1 byte of
memory per character, only using 2, 3, or 4 bytes for other Unicode
characters,
http://dev.clojure.org/jira/browse/CLJ-731 ?
On Tue, Oct 28, 2014 at 2:39 AM, Phillip Lord
wrote:
> Reid McKenzie writes:
> > This suggests that |apply| is immensely expensive in general,
> > and that such arity unrolling even for trivial functions would be a good
> > thing. Albeit hard to buil
I hope I am not pre-announcing things before they've been tested to work,
or misinterpreting work that is going on now, but it appears that Leiningen
folks are fixing Windows-specific issues as this conversation is taking
place (perhaps due to this conversation taking place).
https://github.com/te
Stephen:
Take a look at the "checkouts" Leiningen feature described here to see if
it does what you want:
https://github.com/technomancy/leiningen/blob/master/doc/TUTORIAL.md#checkout-dependencies
Andy
On Sun, Oct 26, 2014 at 8:39 AM, Stephen Wakely
wrote:
> I need to make some modifications
201 - 300 of 912 matches
Mail list logo
