I am trying to track down and solve the issues Phil Hazelden reported on Hacker
News [1]. I suspect that the XML issue was this one:
It appears that the code has moved on since this report-- the emit-element fn
mentions a :pad option but I don't see it being used anywhere. Is there an
issue
I think the behavior you are seeing here is reasonable. When you mix
compilation and dynamic access to vars, you need to reason carefully about the
order in which things will happen.
More usefully: you can write a test in your var-get expression that will make
it do what you want in all
I am seeing more like 1.8 seconds for the raw version, vs. 2.8 seconds for
slurp (master branch). Can you post a complete example (including the clj
script you use, and what version of Clojure), so we can be apples-to-apples?
Stu
For the record, this program runs in 3.3 seconds so I guess
On my laptop (Mac) the biggest difference here has nothing to do with buffering
in slurp. It is whether you use System/in (fast) or *in* (slow). The latter is
a LineNumberingPushbackReader.
Can you check and confirm? When I slurp System/in it is more than twice as fast
as slurping *in*.
I
clojure.xml/parse is not documented to handle filenames-as-strings at all. It
treats strings as URIs, deferring to the host (JVM) notion of URI as
implemented in the underlying API.
I can certainly see why this would be confusing! Is there a way to make it
better without violating the
[] :validator validate-message-list))
(defn add-message [msg]
(dosync (alter messages conj msg)))
(add-message (struct message mm first message))
On Jun 23, 12:58 pm, Stuart Halloway stuart.hallo...@gmail.com
wrote:
Hi Michele,
Pass a sequence of maps, not just a map:
(every? #(:x
Duplicate key prevention is a feature added in commit
c733148ba0fb3ff7bbab133f5375422972e62d08.
Stu
I tried Clojure via Githhub today.
Anyone notice this bug that hadn't existed in Version 1.1
user= #{:item1 {:a A :b B} :item2 {:a A :b B}}
java.lang.IllegalArgumentException: Duplicate
PM, Stuart Halloway wrote:
Assembla Ticket #311 [1] calls for the promotion of clojure.contrib.io into
clojure (as clojure.java.io). I have attached a patch, and am requesting
comments and code review from the community.
Reasons you want to take time from your day to read this code:
(1
Hi Peter,
You are on the contributors list, so I just need to know your account name on
Assembla to activate your ability to add tickets, patches, etc. Let me know
your account name (which needs to be some permutation of your real name, not a
nick).
Thanks,
Stu
I put a self-contained test
Duplicate keys in maps/sets are disallowed in literals and factory functions,
where data is generally literal inline and therefore likely represents coder
error:
; all disallowed
#{:a :a}
{:a 1 :a 2}
(hash-map :a 1 :a 2)
(hash-set :a :a)
They are allowed in other contexts, where the data
to these considerations the names of the functions already in play, and you
get the implementation you see.
On Fri, 25 Jun 2010 10:31:57 -0400
Stuart Halloway stuart.hallo...@gmail.com wrote:
Duplicate keys in maps/sets are disallowed in literals and factory
functions, where data is generally literal
Clojure 1.5 RC 4 is now available via Maven Central:
http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.clojure%22%20AND%20a%3A%22clojure%22%20AND%20v%3A1.5.0*
Please test it!
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this
The docs are clear that the test occurs before the bindings:
(doc if-let)
-
clojure.core/if-let
([bindings then] [bindings then else oldform])
Macro
bindings = binding-form test
If test is true, evaluates then with binding-form bound to the value of
test, if not,
I am pleased to announce the release of Simulant, an open-source framework
for simulation-based testing built using Datomic and Clojure:
https://github.com/Datomic/simulant
Feedback welcome!
Stu
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To
+1 on this line of thought. We are definitely interested in decomplecting
dev mode utility from production lean-and-meanness.
One question along this path is What options exist in Java/maven land for
doing multiple releases of the same artifact with e.g. different
performance and debugging
Clojure 1.5 RC 14 (fourteen) will be available soon from Maven Central:
http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.clojure%22%20AND%20a%3A%22clojure%22%20AND%20v%3A1.5.0*
Please test it!
Thanks,
Stu
--
--
You received this message because you are subscribed to the Google
Groups
It is likely that, once this Pandora's box is opened, there will be more
profiles that just debug yes/no.
It is almost certain that whatever we do must be maven friendly. (Maven is
a de facto standard for 1000x more people than leiningen, and some of them
want to use libs written in Clojure.)
:18.445-00:00 #inst
2000-05-08T18:30:51.890-00:00 #inst 1970-03-22T04:27:39.217-00:00 #inst
1980-11-20T20:59:16.421-00:00 #inst 2001-06-29T08:24:25.837-00:00],
:read #OutOfMemoryError java.lang.OutOfMemoryError: PermGen space}
-Aaron
On Feb 9, 2013, at 2:13 PM, Stuart Halloway stuart.hallo
: Success
VM Running Arch Linux: Success
So I can't say it is easily reproducible. I'll see if I can find what is
tripping things up on the iMac today.
-Aaron
On Feb 10, 2013, at 8:36 AM, Stuart Halloway stuart.hallo...@gmail.com
wrote:
Aaron:
Were you simply running the test suite via
Please test...
Stu
--
--
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
Next week, I will be giving an all-new version of my Clojure in the Field'
experience report [1] at DevNexus in Atlanta [2].
I will be drawing in Chas's State of Clojure Survey [3], and on the
community success stories page [4], but those only scratch the surface of
the wealth of Clojure
If you care about Clojure 1.5 compatibility for your codebase, please test
it against RC 16 as soon as possible.
You can get the source and build it yourself from [1], or wait for Maven
Central [2] to pick up the CI build, which usually takes a few hours.
Thanks!
Stu
[1]
Only change from RC 16 is http://dev.clojure.org/jira/browse/CLJ-1168.
Please test for regression.
Stu
--
--
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
Iwaniuk
Hugo Duncan
John Szakmeister
Juha Arpiainen
Justin Kramer
Kevin Downey
Laurent Petit
Meikel Brandmeyer
Michael Fogus
MichaĆ Marczyk
Michel Alexandre Salim
Philip Aston
Philip Potter
Rich Hickey
Scott Lowe
Steve Miner
Stuart Halloway
Stuart Sierra
Tassilo Horn
Toby Crawley
Tom Faulhaber
Thanks
Clojure 1.5.1 fixes a memory leak in Clojure 1.5, discussed here:
https://groups.google.com/d/msg/clojure-dev/uAFM0Ti4AcQ/GmnKmphF1BgJ
Getting Clojure:
Web: http://clojure.org/downloads
Lein/Maven: :dependencies [[org.clojure/clojure 1.5.1]]
Note that it will take a few
Fixed, thanks.
Stu
On Sun, Mar 10, 2013 at 7:28 PM, ke.mar...@gmail.com wrote:
I think there's a typo in the download link on
http://clojure.org/downloads:
It says http://repo1.maven.org/maven2/org/clojure/clojure/1.5.*0*
Wiki/repo: https://github.com/Datomic/simulant/wiki
Clojars: https://clojars.org/com.datomic/simulant
Presentations:
https://github.com/stuarthalloway/presentations/wiki/Simulation-Testing
Enjoy!
Stu
--
--
You received this message because you are subscribed to the Google
Groups
As opposed to tools.nrepl?
Thanks,
Stu
--
--
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
laurent.pe...@gmail.comwrote:
Hello,
What about
lein run -m clojure.main
?
2013/5/27 Stuart Halloway stuart.hallo...@gmail.com:
As opposed to tools.nrepl?
Thanks,
Stu
--
--
You received this message because you are subscribed to the Google
Groups Clojure group
Hi all,
I will be doing Clojure and Datomic workshops, as well as a few talks. at
NDC Oslo in a few weeks, see http://ndcoslo.oktaset.com/Agenda for details.
Hope to see some of you there!
Stu
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To
Hi Steven,
A few thoughts:
1. You may want to look at
https://github.com/clojure/test.generative/blob/master/data-model.org.
2. I don't think you want a ref for *assertion-results* -- I am not aware
of any use cases that would need transactions. In any case the choice of
reference type probably
-name)))
You might also want to look at clojure.reflect. The API results are data, and
can easily be mapped/filtered/etc.
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email
, it can be used once in the middle of a symbol to
separate the namespace from the name, e.g. my-namespace/foo. '/' by itself
names the division function.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group
On Thu, Jun 23, 2011 at 10:40 AM, Stuart Halloway
stuart.hallo...@gmail.com wrote:
The docs (http://clojure.org/reader) are specific:
'/' has special meaning, it can be used once in the middle of a symbol to
separate the namespace from the name, e.g. my-namespace/foo. '/' by itself
names
be larger than my OO intuition
would have them be.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members
almost 300 signatories to the contributor agreement, and any of
them can update dev.clojure.org without any review process. This should be
plenty of horizontal scaling to keep documentation (even high-churn
documentation) accurate.
Thanks to everyone who is helping out!
Stu
Stuart Halloway
hard problems. Rich will be presenting a great example of this at the NYC
Clojure group on July 20 [8].
Cheers,
Stu
Stuart Halloway
Clojure/core
http://clojure.com
[1] http://dev.clojure.org/display/design/Error+Handling
[2] http://dev.clojure.org/pages/viewpage.action?pageId=950382
[3] http
that
this should not be IDE-based.
2b. Link out to the various other resources that are particularly useful for
beginners.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
[1] http://www.meetup.com/Clojure-NYC/events/16166953/
--
You received this message because you are subscribed to the Google
. (Clojure's own use of metadata isn't required at
runtime, but who knows what other consumers of metadata may need or expect.)
This problem needs more design work before coding begins. (Maybe I should add
the preceding statement to my sig...)
Stu
Stuart Halloway
Clojure/core
http://clojure.com
[1] http
interesting Clojure projects I
have been involved with. But nobody involved with any of them wants to fire me.
:-)
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email
over arrays better not let the array escape
* line-seq better not let the BufferedReader escape
and so on.
Implementers of seqs are responsible for encapsulating implementation details
and not letting them escape. It's a fact of life.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You
an examples macro that calls out to e.g.
clojuredocs.org.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members
Several people have asked about access to Rich's upcoming talk this Wednesday
night [1]. In order to make information available for those who are not present
in NYC, we are planning to do the following:
During the talk:
* We will be live streaming the talk at [2]. This is our first time live
at 9:28 PM, Stuart Halloway stuart.hallo...@gmail.com
wrote:
Several people have asked about access to Rich's upcoming talk this Wednesday
night [1]. In order to make information available for those who are not
present in NYC, we are planning to do the following:
During the talk:
* We
Where is the bug tracker for ClojureScript?
Just created: http://dev.clojure.org/jira/browse/CLJS
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure
.
Let's wait and collect feedback from the community before pouring any cement on
deployment approaches.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure
!
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post
, monolithic contrib git repository.
More important, http://dev.clojure.org/display/doc/Clojure+Contrib is a
community-managed page, so Clojure/core isn't a bottleneck on improving it.
Help requested to make http://dev.clojure.org/display/doc/Clojure+Contrib
better.
Cheers,
Stu
Stuart Halloway
I am working through a few of the pages on clojure.org with two goals:
(1) remove or fix anything that is outdated or incorrect
I really like how minimal that is now.
A quick suggestion: shouldn't the Copyright date be updated too?
Yuo. Fixed, thanks.
Stu
Stuart Halloway
Clojure
that someone grabbing a non-stable build
would recognize the trailing version goo as build artifact. I guess we'll find
out. :-)
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send
). Clojure data structures are even
used for application configuration (lein, cake).
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note
would be better off to start from scratch.
Cheers,
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members
is underway on this. Stay tuned.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please
://dev.clojure.org/display/doc/Documentation+for+1.3+Numerics. These should
be made better and placed in a more prominent place before 1.3 goes final.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group
to be responsible adults.
This should be fixed now. Please verify:
http://dev.clojure.org/display/doc/Documentation+for+1.3+Numerics
Thanks,
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group
. So nobody should bite anyone's head off for asking a question
that has been answered before (particularly if e.g. it is hiding in a deep,
convoluted thread and isn't search friendly).
Keep the feedback coming! Preferably in atomic chunks with good subject lines.
:-)
Cheers,
Stu
Stuart Halloway
to dictate approach. The suggestion was
more about providing a way for people to ease into contributing.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure
on both sides
thanks
Oded
Hi Oded,
sorted-set is on the todo list. Also, the which libraries are todo list is
available in the repos at devnotes/corelib.org. Just look for anything marked
todo.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post
of the class-files generated from core.clj
etc, and still have everything working properly?
Tips/hints/suggestions?
Great question. Post 1.3 we hope to look at a super-slim jar. The design notes
are minimal at this point, but FWIW:
http://dev.clojure.org/display/design/Build+Profiles
Stu
Stuart
, you can implement the IDeref interface.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated
://dev.clojure.org/display/doc/Documentation+for+1.3+Numerics
However (type (- 2 1N)) results in java.lang.Long and does not seem to
work accordingly. What's going on here?
Cheers,
Dominikus
This is already fixed on master.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You
issues is to have people trying a release.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated
user= (mod 987654321 3)
0
Whoa! The computation finished in reasonable time, but with the WRONG
answer! How did that happen?
Did I find a bug?
No, there is simply a typo in your input arg.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you
inside an atom, which provides atomic transitions between values, but no
coordination.
Abandoning values entirely should be highly motivated by a specific need. If
you're there, then Java's concurrent maps are good and appropriate.
Stuart Halloway
Clojure/core
http://clojure.com
--
You
We will see this subject line in this mailing list every few months until the
end of time, or until def- is added to core.
So be it.
The burden, no matter how distributed, of answering that question forevermore
greatly outweighs the burden of moving a def- macro from a contrib file to a
The API already contains `find` and `contains?`, which are woefully
misleading names. That's not a big deal: I'm *terrible* at naming. I tell
people that all the time. I've learned to accept it. It doesn't detract from
my wonderfulness. It doesn't detract from the underlying wonderfulness
I don't understand your comment about polluting the language core. Do you
really think people are going to use def- for some other purpose? If you
don't, then it is not pollution.
Fair enough. Maybe pollution wasn't the best word. Introducing a combinatorial
set of names is a [some other
for constants that will never
change.
I find this style so useful and readable that I'm curious why it isn't
more popular in the community at large.
Top-level lets make it more difficult for tools to statically analyze code.
Of course said tools are largely hypothetical at present. :-)
Stu
Stuart
I also think it is worth remembering the difficulty people have with getting
started with Clojure (wrt to IDEs). There are *so* many third party
libraries out there at the moment that a beginner could easily be
overwhelmed. The more self contained and feature complete the core is the
building properly. That is now fixed, so we can confirm this issue on Hudson:
http://build.clojure.org/view/Clojure/job/clojure-test-matrix/
-Stuart Sierra
clojure.com
Now fixed on master. Thanks for the report!
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message
with the
semantics you propose.
On the other hand, what you want is quite simple to achieve: If you want
consistent view of the the values of refs, deref them all at the start of the
transaction.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you
to the
Fedora package.
Best Regards:
Jochen Schmitt
The SHA for that commit is fcc3d799cc33c920720fa512b18901e2f2a81dda .
But you might want to leapfrog that and just grab the clojure-1.3.0 tag. :-)
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you
the website says:
deftype supports mutable fields, defrecord does not
so deftype seems to be what would be a java bean with simple
properties in java
Nope. :-)
Domain information should use defrecord, and should never be mutable. This is
the closest thing to a Java bean, but is
Nice! This is great. Will the :only directive always be required, or
will we eventually be able to pull in entire namespaces?
- Jason
Probably the former. Pulling in entire namespaces is generally considered bad
practice.
Stu
--
You received this message because you are subscribed to
what's the difference between persistent and immutable?
See http://en.wikipedia.org/wiki/Persistent_data_structure, which now has a
nice shout out to Clojure.
Stu
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
a transparent wrapper
around 1.2 jars so that they can be called by 1.3 code without local
(eval-in-1.3 ...) macros.
This sounds big and hairy compared to simple detect-and-warn or detect-and-fail
approaches.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message
would really help those of us who want to be able to
rely on Clojure.
The objective is the kind of stability seen across 1.0, 1.1, and 1.2.
I am aware of nothing on the horizon like the numerics change, but if something
important enough comes along, a decision will be made.
Stuart Halloway
Clojure
Staying with 1.2 meant not only staying with the Clojure core, which worked
fine, but also losing any progress on any of the contribs, which was frankly
more important to me than core language changes. Perhaps part of the really
big issue here is not Clojure per se, but the contribs. In one
user= (= 23.0 23)
false
user= (= 23 23)
true
This is the correct behavior. If the doc string is confusing, please propose
alternate language.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group
Stu's comment actually worries me in this respect: the fact that each contrib
has its own version may make it easier to evaluate them separately, but it
would appear to me as a defeatist goal for Clojure moving forward.
Things that are simple can be composited. Things that are compounds
Contrarily, it seems that effort is being put into cleaning up the core and
jettisoning anything merely suspected of being superfluous.
That certainly isn't an objective. Can you list some examples of things that
in your opinion were casually jettisoned?
I didn't use the word casually.
On 10/02/2011 05:20 PM, Stuart Halloway wrote:
I was referring to the aggregate contrib, not a curated subset (which I
agree is a good idea). Maybe we should call the aggregated thing the
Libraries Formerly Known as Contrib (LFKAC).
Here's how I envision the distribution structure:
Clojure
Ok, so I'm stuck. If any of you more seasoned clojurians have a hint
that could get me out, I will be forever gratefull to him/her:
I'm trying execute a query against google app engine datastore, using
appengine-magic, with the filter dynamically generated from a map.
Here's the closest
(java.io.IOException.)) (catch java.io.IOException _ caught!))
I suspect something else is going wrong in the GAE example. Can you narrow the
code down to a block you can quote in full here?
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you
I finally got around to trying out the 1.3 release yesterday with a batch of
code that was constructed using 1.2, and promptly ran into a problem. In 1.2,
it's possible to define a protocol with zero methods, so, for example,
(defprotocol xxx) works just fine. In 1.3, this generates the
I use Base64 encoding a lot and the slow implementation is hurting a
lot. It's slower than Sun misc encoder/decoder
and that one is very very slow. I was using Sun's implementation a bit
and it took 80 seconds to encode a 56 MB file.
Then I found this: http://migbase64.sourceforge.net/
It
contrib?
One thing I would like to see is a call that takes bytes,offset,length. When I
care about fast I also care about not being forced to do an arraycopy.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure
Sure, I'll start working on it. Do you want it to be worked on in a contrib
project or just submit it once it's functional?
Whatever works best for you.
Also, I assume you'd want this to work with 1.2, right?
I won't personally need that. Plus, this is the kind of lib where the code
a little more than
twice as slow as clj-json (which clocked in a little under one second
for my file).
Lars Nilsson
Thanks. I am going to take a look at this now.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups
Trying to be a little bit constructive here, in case I come across as
complaining, I took the source for c.d.json and put it into a
leiningen project, enabled warn on reflection, and found that several
cases of (... (let [c (char i] ... (= c \x) ...) results in Clojure
deciding it needs to
On Sunday, 9 October 2011 19:49:17 UTC-7, Stuart Sierra wrote:
Clojure unless somebody clever can make one that's actually *faster* than the
best Java lib.
Here ya go: https://github.com/ataggart/clojure.data.codec
I owe you a beer for the offset and length args. Thanks!
Stu
Stuart
record] (str (:i record)))
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
I want to submit the Contributor Agreement.
One question is whether the following mail address on
http://clojure.org/contributing is still valid:
Rich Hickey
514 South Duke Street
Durham, NC 27701
The other question is whether the above address is in USA. I live in
Beijing. I need to
interop method invocation, or box an int if
you want to hold on to a value guaranteed to be int.
Can you post a code example that shows a problem you are having?
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups
/test.benchmark would be terrific. These act as test
cases for both functionality and performance.
Improving the docs at http://dev.clojure.org/ is also a great help (although
the site seems down atm).
Cheers,
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because
Yes, I understand the behavior perfectly well. The primitive int gets
converted to a Long immediately, as this code demonstrates:
user= (class (Integer/parseInt 5))
java.lang.Long
The int isn't being boxed into a Long -- the type is being changed.
I'm aware that I can fix things by
It appears that the answer to the original question is no, there is no way
to configure the reader to default numbers with a decimal point to be
BigDecimal instead of Double.
Scott Hickey
Reading a double implies that somebody upstream of you was using doubles, which
violates the
It appears that the answer to the original question is no, there is no way
to configure the reader to default numbers with a decimal point to be
BigDecimal instead of Double.
Scott Hickey
Reading a double implies that somebody upstream of you was using doubles,
which violates the
Luc, what you're saying sounds to me like this is the way it is so
deal with it. Can you give me some concrete code snippets showing why
it's better to box ints as Longs? Do you really think the following is
at all intuitive?
user= (class (Integer/parseInt 1))
java.lang.Long
user= (class
401 - 500 of 776 matches
Mail list logo