On Tue, Oct 18, 2011 at 3:47 PM, Tassilo Horn wrote:
> Scott Hickey writes:
> And usually, you should refrain from using floating points at all, no
> matter if BigDecimal or Double.
I thought BigDecimal with was not a floating point in the traditional
sense (ie., subject to all of the usual roun
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 conver
On Thu, Oct 20, 2011 at 11:17, Joel Gluth wrote:
> On Tue, Oct 18, 2011 at 3:47 PM, Tassilo Horn wrote:
>> Scott Hickey writes:
>> And usually, you should refrain from using floating points at all, no
>> matter if BigDecimal or Double.
>
> I thought BigDecimal with was not a floating point in th
Alan, I'm with you on this one. Reflection is so much slower that sometimes
I wish clojure had a different syntax for reflective method invocation. For
example:
1) Make reflection an automatic error (not even a warning), and
2) Use another syntax (let's say double-dot, for the sake of argument)
Joel Gluth writes:
>> And usually, you should refrain from using floating points at all, no
>> matter if BigDecimal or Double.
>
> I thought BigDecimal with was not a floating point in the traditional
> sense (ie., subject to all of the usual rounding horror, unless you
> ask it to be)? That is,
On Thu, Oct 20, 2011 at 3:53 PM, Chris Perkins wrote:
> 1) Make reflection an automatic error (not even a warning), and
> 2) Use another syntax (let's say double-dot, for the sake of argument) to
> mean "I'm OK with this being done via reflection."
> (.foo bar) => error
> (.foo ^SomeType bar) =>
Tangentially: In this particular case, reflection isn't strictly necessary
because toString is a method of Object. In theory, the compiler could
special-case Object's methods and never do reflection, right?
In practice, I don't know if it's worth the effort, although it's certainly
a little sur
hi clojure community,
at the moment there seems to be no applicable
clojure starter package for the http://aichallenge.org/
though some work has be done on it by chris granger, i
think: https://github.com/ibdknox/aichallenge
are there any plans to get a clojure starter package out ?
it would be
Hi,
definterface has the ability to type methods.
http://dev.clojure.org/jira/browse/CLJ-737 and its attached patch
http://dev.clojure.org/jira/secure/attachment/10119/definterface-array-fix-with-tests.patch
suggest, that you should be able specify array types too.
When I tried it (in 1.3), howev
> 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
Hey guys,
The "small loss of performance expression" was applied to the specific example
I used to illustrate the thing. 500 times longer may look huge but if it occurs
10 times in your application run, bottom line it may mean nothing.
Of course if you have a fn chewing up 30% of your application
We still have a sizable Java chunk here closely interacting with Clojure
and fully agree with #1 and #2.
Interop is environment specific and should not be driving the Clojure language
design.
Otherwise Clojure generics would have to "bend" to Java, CLR, JS and future
implementations in
other env
Thanks for the clarification.
Just to clear up any confusion, the .toString example was just the
simplest example I could think of that illustrated was I was seeing
with regards to reflection and type hints :)
On Oct 20, 4:22 am, Michael Fogus wrote:
> Another potential option is to implement a
The video is up:
http://www.infoq.com/presentations/Simple-Made-Easy
Places to watch for comments (or vote if you like):
- http://news.ycombinator.com/item?id=3135185
-
http://www.reddit.com/r/programming/comments/lirke/simple_made_easy_by_rich_hickey_video/
- http://www.dzone.com/links/simple_
On Thu, Oct 20, 2011 at 1:54 AM, nathanmarz wrote:
> 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
class is a clojure function that takes Objects, so th
Good point.
Let me change the question slightly,
Is there a compile time capability that will allow namespaces to be split
across several files and merged.
Thereby achieving the equivalent of in-ns and load?
Basically, I would like to have a namespace where some functions are defined
in a diff
Thinking further, the capability would not be of use (to me) if it were not
consistent/indistinguishable across clojure and clojurescript.
I have seen in-ns and load used to effectively split a namespace across
files
If 'in-ns' and 'load' were implemented for clojurescript, could 'load' be
man
Here's a quick proof using an interface-based primitive detector:
(definterface IPrimitiveTester
(getType [^int x])
(getType [^long x])
;; other types elided
)
(deftype PrimitiveTester []
IPrimitiveTester
(getType [this ^int x] :int)
(getType [this ^long x] :long)
;; other types e
Oops, I elided a little too much. Need a method with an Object signature to
distinguish Integer from int:
(definterface IPrimitiveTester
(getType [^int x])
(getType [^long x])
;; etc
(getType [^Object x]))
(deftype PrimitiveTester []
IPrimitiveTester
(getType [this ^int x] :int)
(g
I recently tried to get Speclj running on Clojure 1.3 and came across the
following problem:
(list
(declare ^:dynamic p)
(defn q [] @p))
(binding [p (atom 10)]
(q))
> java.lang.ClassCastException: clojure.lang.Var$Unbound cannot be cast to
> clojure.lang.IDeref
Thanks to @cemerick for h
In the Simple-Made-Easy talk Rich raises the question
of long term use. In particular, he mentions the issue
of maintenance and change.
In order to change software you need to understand the
program. Unfortunately most people equate "understanding
the program" as being equivalent to "what the func
This may not be a Clojure specific kind of question, but this is for
my Clojure web app(s) so hopefully it's not too far off.
Currently when I deploy my web apps I run 1 app instance on 1 app
server. Given these are multi-core servers I am thinking about running
4 app instances on a server to get
As a person currently suffering under the load of a highly entangled
system here at work, I really appreciated this talk. The software I'm
currently working on is so entangled, so strongly typed, that we have
some parts of our app even our Architect doesn't want to touch. It's
almost as if Rich loo
Hi,
Am 20.10.2011 um 19:53 schrieb Micah Martin:
> I recently tried to get Speclj running on Clojure 1.3 and came across the
> following problem:
>
> (list
> (declare ^:dynamic p)
> (defn q [] @p))
>
> (binding [p (atom 10)]
> (q))
>
>> java.lang.ClassCastException: clojure.lang.Var$Unboun
Thanks, that clarifies the behavior. Regardless though, at some point
the "int" is becoming a "Long" which is a change of type. I'm arguing
that Clojure should box primitive ints as Longs.
Stu, I wouldn't say Clojure's behavior makes it "just work". For
example, if I obtained by number using Integ
Oops, I meant "Clojure should box primitive ints as Integers." :-)
On Oct 20, 12:15 pm, nathanmarz wrote:
> Thanks, that clarifies the behavior. Regardless though, at some point
> the "int" is becoming a "Long" which is a change of type. I'm arguing
> that Clojure should box primitive ints as L
Such a change would be make Clojure's numeric design inconsistent. You keep
saying that Clojure is changing the types - that's probably not the right
way to look at it.
It's a semantic change, Clojure now only has 64bit primitives - the same way
that JavaScript only has doubles.
Prior to the 1.3
I don't think so. Jetty is also multi-threaded; each request will be served
by a new thread (within a bounded thread pool). Secondly, processor
affinity is almost always a bad idea; the OS is pretty good at doing this
for you.
At the very least I would have a test harness which measures the beha
But Clojure is already inconsistent. ints and Integers in interop are
treated differently. The only way to make Clojure consistent is to
either:
1. Box ints as Integers
2. Always convert Integers to Longs.
I'm not sure on the feasibility of #2.
I'm not trying to be obtuse, but I really don't see
On Thu, Oct 20, 2011 at 3:45 PM, nathanmarz wrote:
> But Clojure is already inconsistent. ints and Integers in interop are
> treated differently. The only way to make Clojure consistent is to
> either:
>
Clojure is consistent. Whether or not that makes *interop* easier or harder
is orthogonal.
On Thu, Oct 20, 2011 at 12:45 PM, nathanmarz wrote:
> But Clojure is already inconsistent. ints and Integers in interop are
> treated differently. The only way to make Clojure consistent is to
> either:
as David said "Clojure now only has 64bit primitives".
an Integer is not a primitive, an int
I'm not sure we're arguing about the same thing. I think that Clojure
only supporting 64 bit primitive arithmetic is fine, and I'm not
proposing that it support 32 bit primitive arithmetic. The sole point
of contention is what Clojure does when it has to box a primitive int.
I think this is orthogo
To put it another way: a top-level "do" is special-cased to compile and
then immediately execute each contained form, in order. Any other top-level
form, such as "list", will be fully compiled, including all contained forms,
and only then executed. In this case, the defn cannot compile because
Note: I forgot to preface that with "I think..." :) Upon experimenting
briefly, it turns out I was wrong about how Clojure works (that seems to
happen a lot with me). A declare/def defines a var even when it's not
executed!
user> (defn xxx [] (declare yyy))
#'user/xxx
user> yyy
#
Well, I lea
Thank for the replies and I appreciate the suggestions, however they some of
the rationale behind them doesn't match well my experience.
First, BigDecimal is plenty fast the large business systems I've worked on.
Actually, it has been plenty fast for every large business system I've
worked on.
Scott: "no, there is no way to configure the reader to default numbers with
a decimal point to be BigDecimal instead of Double"
Correct. But you can modify the Reader: it's just Java code.
-S
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post
> 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 g
On Thu, Oct 20, 2011 at 22:50, Stuart Halloway
wrote:
>> 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 som
>>> 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,
>> w
On Thu, Oct 20, 2011 at 23:16, Stuart Halloway
wrote:
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 im
I would suspect that you would not get a _significant_ performance advantage
from specifying processor affinity, but if you really want to measure it and
find out by experimentation, read on.
I was not able to find any portable way within a JVM to set processor
affinity, after some amount of Googl
On Thu, Oct 20, 2011 at 4:31 PM, Chris Perkins wrote:
> Note: I forgot to preface that with "I think..." :) Upon experimenting
> briefly, it turns out I was wrong about how Clojure works (that seems to
> happen a lot with me). A declare/def defines a var even when it's not
> executed!
> user> (d
For some work I'm doing it would be very nice to be able to know the number
of arguments any given function expects to be called with. Is there anyway
to get this information at run-time in Clojure?
Thanks.
--
You received this message because you are subscribed to the Google
Groups "Clojure" g
On Thu, Oct 20, 2011 at 1:11 PM, nathanmarz wrote:
> of contention is what Clojure does when it has to box a primitive int.
My understanding is that Clojure 1.3 has 64-bit primitives, i.e.,
longs and double. You only have a primitive int if you coerce the
value to int (for an interop call that ex
So you propose this:
user=> (time (dotimes [i 1000] (let [ a (Integer. 1) b (Integer. 2)] (+ a
b
"Elapsed time: 31.14886 msecs"
nil
Instead of this:
user=> (time (dotimes [i 1000] (let [ a 1 b 2] (+ a b
"Elapsed time: 15.680386 msecs"
nil
Using a wrapper instead of a primitive
On Thu, Oct 20, 2011 at 4:11 PM, nathanmarz wrote:
> I'm not sure we're arguing about the same thing. I think that Clojure
> only supporting 64 bit primitive arithmetic is fine, and I'm not
> proposing that it support 32 bit primitive arithmetic. The sole point
> of contention is what Clojure doe
There is a load-file function in clojurescript, I'm guessing that doesn't do
what you want?
Scott
On Thu, Oct 20, 2011 at 1:07 PM, Dave Sann wrote:
> Thinking further, the capability would not be of use (to me) if it were not
> consistent/indistinguishable across clojure and clojurescript.
>
>
Hi guys,
I fall out in many situations that I want the partial, but inversed, a
simple example:
Let's say I wanna all primes bellow 2.000:
(take-while (partial > 2000) primes)
In this case, that's ok, but I don't expressed myself write, I because I had
to use the oposite of < to create the part
I can understand your situation because I've seen a C# code where most of
the classes in some 5-6 different assemblies had all (or 90%) static methods
:)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@go
Clojure.jar does not have a project.clj file because it is all java code,
right? If it is all java code then it's a (java) jar file.
I found this convention of bundling a clojure jar file with a project.clj
file - lein does this and that's all I know - so I was curious to know if
every
other b
No. The summary is: from Java's point of view every function is
"willing" to accept any number of args, but many of the
implementations throw an exception. Vars have an :arglists metadata
key, but that is not generally present on functions. I agree it would
be nice if function objects carried a set
In a REPL,
user> (defn hello [name]
(println "hi," name))
#'user/hello
user> (meta (var hello))
{:ns #, :name hello, :file "NO_SOURCE_FILE", :line 1,
:arglists ([name])}
Please also check - http://clojuredocs.org/clojure_core/clojure.core/meta
--
You received this message because you
Manoj,
On Fri, Oct 21, 2011 at 9:09 AM, mmwaikar wrote:
> Clojure.jar does not have a project.clj file because it is all java code,
> right? If it is all java code then it's a (java) jar file.
>
> I found this convention of bundling a clojure jar file with a project.clj
> file - lein does this an
I figured, but had to ask. I'm looking into adding a feature to Midje to be
able to say:
(defn g [a b c d e f g] nil)
(fact
(f 1) => 1
(provided
(g ...) :never ))
instead of what you currently have to say for the equivalent:
(fact
(f 1) => 1
(provided
(g anything anything anythi
On Thu, Oct 20, 2011 at 8:15 PM, Wilker wrote:
> In the case of <> it's ok because they are reverse of each other, but in
> some circustances there is no reverse function, and you finish can't be
> using partial, instead you do like:
>
> (take-while #(< % 2000) primes)
>
> I mean, there is no such
Thanks. I'm going to have to see if that could help with what I'm trying to
do.
On Thu, Oct 20, 2011 at 11:45 PM, mmwaikar wrote:
> In a REPL,
>
> user> (defn hello [name]
> (println "hi," name))
> #'user/hello
>
> user> (meta (var hello))
> {:ns #, :name hello, :file "NO_SOURCE_FILE",
Hi,
Am 21.10.2011 um 06:01 schrieb Sean Corfield:
> On Thu, Oct 20, 2011 at 8:15 PM, Wilker wrote:
>>
>> (take-while #(< % 2000) primes)
>
> I was expressing a need for exactly this function the other day on
> IRC. I jokingly called it 'impartial' :)
What is bad about #(< % 2000)? In fact I w
Now I'm confused. So when I do this:
(def i (Integer/parseInt "1"))
Is "i" a primitive int, a primitive long, or a Long object?
I was under the impression that it was a primitive int based on
Justin's test code, but when I run "(primitive-type i)" in the REPL it
tells me :object.
If "i" is a pr
Hi Miekel,
The main reason is because I feel it is more expressive, and I really love
expressive code :)
---
Wilker Lúcio
http://about.me/wilkerlucio/bio
Kajabi Consultant
+55 81 82556600
On Thu, Oct 20, 2011 at 9:10 PM, Meikel Brandmeyer wrote:
> Hi,
>
> Am 21.10.2011 um 06:01 schrieb Sean C
It is a Long object. Vars hold objects, so it has to be boxed.
However, if instead of def'ing it you immediately called some java
method that will accept either a primitive int or a primitive long, my
understanding is that Clojure would arrange for the int version to be
called, because no boxing wo
Thanks Alan, that makes sense. This code example illustrates that
Clojure values can already be primitive ints:
user=> (let [i 1] (primitive-type i))
:long
user=> (let [i (Integer/parseInt "1")] (primitive-type i))
:int
So it appears that Clojure's behavior is case #2 from my last comment.
All I'
Thanks everyone for your inputs and the discussion.
Manoj.
--
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
fir
The "weirdness" here is that you seem to confuse the Java context and the
Clojure
context. They are not the same. Clojure has to satisfy to performance and
consistency
criterias. It's a language of it's own, not a Java offspring.
user=> (class (Integer/parseInt "1"))
java.lang.Long
user=>
Int
63 matches
Mail list logo
