ANN: 26 October Overtone Orchestra in London
Hello Fellow Clojurians and Clojure Curious! Following from Sam Aaron's very well received talk on Making Music with Clojure using Overtone the London Clojure Dojo is holding a special Clojure Dojo on Wednesday 26 October where we'll be having fun making music with Overtone. Sign up for the event is here: https://ldncljdojo.eventwax.com/october-2011-overtone-orchestra Bring your laptop if you have one. Instructions on setting up Overtone are available on the London Clojurians google group here: http://groups.google.com/group/london-clojurians/browse_thread/thread/4478110c5d24c6f6 I hope to see you there! cheers, Bruce -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is there a reader setting support BigDecimal by default?
On Tue, Oct 18, 2011 at 3:47 PM, Tassilo Horn tass...@member.fsf.org wrote: Scott Hickey jscotthic...@gmail.com 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, you can do decimal calculations exactly using it. -- [what were the skies like when you were young?] -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
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 converting the type back to an
Integer manually, but that's not the point. Changing the types is
unusual behavior that leads to hard to track down bugs like I ran into
with the ClassCastException. My proposal still stands.
-Nathan
On Oct 19, 5:29 pm, Kevin Downey redc...@gmail.com wrote:
On Wed, Oct 19, 2011 at 5:14 PM, nathanmarz nathan.m...@gmail.com wrote:
Here's a code example illustrating the problem I'm having:
https://gist.github.com/1300034I've simplified it to the bare minimum
necessary to illustrate the problem.
Agree 100% that ints and longs are broken in Java. The hashcode/
equality stuff is messed up. Clojure can try really hard to hide this,
but it can't hide it completely since Java libraries can always return
you Integer objects. The additional complexity added from changing the
Existing Integer objects are unchanged. If the method call in your
example did return an Integer object then you would never notice
anything.
types on you isn't worth it IMO.
Here's my proposal for what I think would be better behavior:
1. Clojure boxes ints into Integers rather than convert them into
longs
clojure does not convert ints into longs, you are putting a primitive
into a collection, which requires boxing, clojure 1.3 boxes ints as
Longs. If you put (Integer. …) around your call you will be fine.
2. If you wrap the form in (long ...), Clojure skips the boxing and
does what it does now. Since this is done explicitly, there's no
confusion about types.
-Nathan
On Oct 19, 7:38 am, Stuart Halloway stuart.hallo...@gmail.com wrote:
Thanks. I read through that and it didn't quite answer my question. To
me it seems more logical that:
1. Clojure defaults to longs when you create a new number (with a
literal 0, 1, etc)
2. You can create ints by doing (int 0)
3. Clojure never changes the types of things you're using
I find Clojure's behavior of changing the types of primitive ints to
longs highly unusual, and it is causing a lot of pain in upgrading
Storm to 1.3.
Integers and longs are going to be painful no matter what because they are
broken in Java, e.g.
Object[] objects = new Object[] {-1, -1L};
System.out.println(objects[0].hashCode());
System.out.println(objects[1].hashCode());
Clojure avoids this pit by standardizing on longs, which leaves you with
the need to specifically request ints when you need them for interop. You
can use (int n) hints to select the correct 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/corehttp://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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?
--
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 group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Is there a reader setting support BigDecimal by default?
On Thu, Oct 20, 2011 at 11:17, Joel Gluth joel.gl...@gmail.com wrote: On Tue, Oct 18, 2011 at 3:47 PM, Tassilo Horn tass...@member.fsf.org wrote: Scott Hickey jscotthic...@gmail.com 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, you can do decimal calculations exactly using it. The term floating point is used to distingiush from fixed-point schemes, such as deciding that We're going to store money as a 64 bit integer representing the number of 100ths of a cent. Effectively, fixing the decimal point thus: $1000.. BigDecimal is an arbitrary precision integer and a scale factor (think of the scale factor as multiplying or dividing by a power of ten.) So, in that sense the (decimal) point floats. Unlike floating point in the IEEE754 sense, BigDecimal is decimal, not binary, (so e.g. 0.1 has a terminating representation) and arbitrary precision, so you can avoid rounding effects unless you're dividing where you might have to round to truncate a non-terminating representation. // Ben -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: About metadat and #^ macro.
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) to mean I'm OK with this being done via reflection. (.foo bar) = error (.foo ^SomeType bar) = fast (..foo bar) = probably slow Of course, something this fundamental is unlikely to change, so I guess I should just get used to setting *warn-on-reflection* :) - Chris -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is there a reader setting support BigDecimal by default?
Joel Gluth joel.gl...@gmail.com 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, you can do decimal calculations exactly using it. You are right. What I've meant that you don't want to use double or float because it's not precise, and you don't want to use BigDecimal because it's slower and, even more important, it'll throw an exception if a given number cannot be represented as decimal number. user= (/ 1M 3) ArithmeticException Non-terminating decimal expansion; no exact representable decimal result. java.math.BigDecimal.divide (BigDecimal.java:1616) So the general suggestion is to stick to integers and rational numbers as long as possible. Bye, Tassilo -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: About metadat and #^ macro.
On Thu, Oct 20, 2011 at 3:53 PM, Chris Perkins chrisperkin...@gmail.com 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) = fast (..foo bar) = probably slow Instead of introducing a whole new (possibly confusing) syntax for reflective calls, IMHO it's better to have a var *error-on-reflection* which, when set to true will throw an error on reflection. A patch for this should be easy to implement as well. Regards, BG -- Baishampayan Ghose b.ghose at gmail.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. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Type hints and records
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 surprising that (.toString thing) can be 100 times slower than (str thing), at least until you know what's going on there. - Chris -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
clojure starter package for aichallenge ?
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 nice to see clojure-programs participate in the challenge. have a successful day -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Array type hints in 1.3
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), however, it didn't work: (definterface Name (^[Ljava.lang.String; method [])) Method method in class aserver/entity/device/Name has illegal signature ()L[Ljava/lang/String;; [Thrown class java.lang.ClassFormatError] Primitive array hints do compile, the compiled code refers to a class named by the literal string though; hinting with ^longs, .. works: (definterface Name (^[J method [^longs arg])) // looking into the .class file with JD http://java.decompiler.free.fr/ public abstract [J getPushes(long[] arg); Did I do something wrong? kind regards -- __ Herwig Hochleitner -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
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 converting the type back to an Integer manually, but that's not the point. Changing the types is unusual behavior that leads to hard to track down bugs like I ran into with the ClassCastException. My proposal still stands. -Nathan Somebody has to work hard: either users of collections, or interop callers. The current behavior makes things just work for collections, at the cost of having to be explicit for some interop scenarios. There are two reasons to favor collection users over interop users: (1) Interop problems are local, and can be resolved by checking the type signature at the point of the problem. Collection key problems are global and break the composability of collections. It is a *huge* benefit of Clojure that collections are sane. (2) There are a lot more lines of code working with collections than doing interop. 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: About metadat and #^ macro.
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 run time, reflection may become significant, hence the need to check. It was not meant as a general remark. It's a trade off situation and you must do some analysis to apply these optimizations. Most of the time here we do not care about the type of objects passed except in some frequently reused common code. We do not want to loose the flexibility of dynamic typing, our message bus runs on a small cluster Atom 330 machines 24/7... not Hulk like servers and we should be the rightly concerned by these optimizations. We did not find so many cases that justified retooling the code up to now. Luc P. On Wed, 19 Oct 2011 22:49:46 -0700 (PDT) Alan Malloy a...@malloys.org wrote: I agree with the general sentiment: add typehints later, and only if you need performance in this particular part of the code. I object to the characterization as a small loss of performance, though. A reflective method call takes about five hundred times as long as a hinted method call in the following benchmark, so if you do have a performance-sensitive section of your program that needs to do a lot of interop, the improvement is dramatic, not small. user (time (dotimes [_ 1e6] (let [s (identity test)] (.length s Elapsed time: 15490.471302 msecs user (time (dotimes [_ 1e6] (let [s (identity test)] (.length ^String s Elapsed time: 34.561754 msecs On Oct 19, 10:35 pm, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Just use ^ for type hints. http://clojure.org/java_interop#Java%20Interop-Type%20Hints Type hints are used to eliminate reflection calls, the compiler can use the exact type of the parameter to eliminate the runtime cost of finding if methods/fields exist before calling/accessing them. user= (set! *warn-on-reflection* true) true ;;; == tells the compiler to complain about reflection calls user= (defn a [b] (.startsWith b a)) Reflection warning, NO_SOURCE_PATH:23 - call to startsWith can't be resolved. === Oups ! #'user/a user= (a 1) java.lang.IllegalArgumentException: No matching method found: startsWith for class java.lang.Integer (NO_SOURCE_FILE:0) This definition has no type hint, the compiler flags a warning to say that it cannot resolve the method startsWith. If you try to call the first form with an object not implementing startsWith, the runtime traps that it did not find the method on that object's class. The flexibility comes with a cost, finding the method on the fly. user= (defn a [^String b] (.startsWith b a)) #'user/a user= (a 1) java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String (NO_SOURCE_FILE:0) Here the compilation does not trigger the reflection warning, the argument type has been hinted as a string. The compiler can find the method immediately and generate the code without any runtime search. At runtime, if you ever call the second form with a non string object, this time you get that the argument type is not the one expected (from the type hint). The compiler has added a type check instead of relying on the dynamic search for methods/fields in the class which is faster. Note that it's not data typing per se. You are allowed to call the form with a different object class. The compiler will not scream, the runtime will if you persists to call the method. Form #1 allows you to pass objects of any class that implements startsWith with a small loss of performance. In form #2 you can gain performance at the expense of generality. Type hints are to be to improve performance AFTER your code is more or less stable. If you use type hints early in your development, you will carry them all the way and that can be a significant pain. Luc P. On Wed, 19 Oct 2011 22:03:31 -0700 (PDT) mmwaikar mmwai...@gmail.com wrote: Hi, I read in Clojure in Action book by Amit Rathore, that #^ associates metadata for the next form. He also mentions that it is deprecated. So what is the current way of doing it? Also, in code like this - (defn filenames-in-jar Returns a sequence of Strings naming the non-directory entries in the JAR file. [#^JarFile jar-file] is it specifying that the type of the jar-file argument should be JarFile? Where can I find some more documentation and or examples about it? Thanks, Manoj. -- Luc P. The rabid Muppet -- Luc P. The rabid Muppet -- 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
Re: Clojure 1.3 treatment of integers and longs
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 environments, loosing its identity along the way and creating a Babel tower. Luc P. On Thu, 20 Oct 2011 09:00:23 -0400 Stuart Halloway stuart.hallo...@gmail.com 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 The int isn't being boxed into a Long -- the type is being changed. I'm aware that I can fix things by converting the type back to an Integer manually, but that's not the point. Changing the types is unusual behavior that leads to hard to track down bugs like I ran into with the ClassCastException. My proposal still stands. -Nathan Somebody has to work hard: either users of collections, or interop callers. The current behavior makes things just work for collections, at the cost of having to be explicit for some interop scenarios. There are two reasons to favor collection users over interop users: (1) Interop problems are local, and can be resolved by checking the type signature at the point of the problem. Collection key problems are global and break the composability of collections. It is a *huge* benefit of Clojure that collections are sane. (2) There are a lot more lines of code working with collections than doing interop. Stu -- Luc P. The rabid Muppet -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Type hints and records
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 mefo...@gmail.com wrote: Another potential option is to implement a record toString method: (defrecord Rec [^Integer i] Object (toString [_] (str i))) (str (Rec. 42)) ;= 42 -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Rich Hickey: Simple Made Easy from Strange Loop 2011
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_made_easy_by_rich_hickey.html -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
On Thu, Oct 20, 2011 at 1:54 AM, nathanmarz nathan.m...@gmail.com 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 the int must be boxed.
The int isn't being boxed into a Long -- the type is being changed.
I'm aware that I can fix things by converting the type back to an
Integer manually, but that's not the point. Changing the types is
unusual behavior that leads to hard to track down bugs like I ran into
with the ClassCastException. My proposal still stands.
-Nathan
On Oct 19, 5:29 pm, Kevin Downey redc...@gmail.com wrote:
On Wed, Oct 19, 2011 at 5:14 PM, nathanmarz nathan.m...@gmail.com wrote:
Here's a code example illustrating the problem I'm having:
https://gist.github.com/1300034I've simplified it to the bare minimum
necessary to illustrate the problem.
Agree 100% that ints and longs are broken in Java. The hashcode/
equality stuff is messed up. Clojure can try really hard to hide this,
but it can't hide it completely since Java libraries can always return
you Integer objects. The additional complexity added from changing the
Existing Integer objects are unchanged. If the method call in your
example did return an Integer object then you would never notice
anything.
types on you isn't worth it IMO.
Here's my proposal for what I think would be better behavior:
1. Clojure boxes ints into Integers rather than convert them into
longs
clojure does not convert ints into longs, you are putting a primitive
into a collection, which requires boxing, clojure 1.3 boxes ints as
Longs. If you put (Integer. …) around your call you will be fine.
2. If you wrap the form in (long ...), Clojure skips the boxing and
does what it does now. Since this is done explicitly, there's no
confusion about types.
-Nathan
On Oct 19, 7:38 am, Stuart Halloway stuart.hallo...@gmail.com wrote:
Thanks. I read through that and it didn't quite answer my question. To
me it seems more logical that:
1. Clojure defaults to longs when you create a new number (with a
literal 0, 1, etc)
2. You can create ints by doing (int 0)
3. Clojure never changes the types of things you're using
I find Clojure's behavior of changing the types of primitive ints to
longs highly unusual, and it is causing a lot of pain in upgrading
Storm to 1.3.
Integers and longs are going to be painful no matter what because they
are broken in Java, e.g.
Object[] objects = new Object[] {-1, -1L};
System.out.println(objects[0].hashCode());
System.out.println(objects[1].hashCode());
Clojure avoids this pit by standardizing on longs, which leaves you with
the need to specifically request ints when you need them for interop. You
can use (int n) hints to select the correct 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/corehttp://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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?
--
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 group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?
--
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 group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Will clojurescript get in-ns and load?
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 different file/location. (The practical use being to allow both jvm and clojurescript implementations of the same api) Dave -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Will clojurescript get in-ns and load?
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 managed as a compile time operation to merge the namespaces. Perhaps there are better ways of achieving this that I am not aware of. Cheers D -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
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 elided ) (defmacro primitive-type [x] `(.getType (PrimitiveTester.) ~x)) (comment user= (primitive-type 5) ;unboxed :long user= (primitive-type (Integer/parseInt 5)) ;unboxed :int user= (class (Integer/parseInt 5)) ;boxed java.lang.Long ) Justin -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
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) (getType [this ^long x] :long) ;; etc (getType [this ^Object x] :object)) (defmacro primitive-type [x] `(.getType (PrimitiveTester.) ~x)) (comment user= (primitive-type (Integer. 5)) :object user= (primitive-type (Integer/parseInt 5)) :int ) On Thursday, October 20, 2011 1:13:03 PM UTC-4, Justin Kramer wrote: 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 elided ) (defmacro primitive-type [x] `(.getType (PrimitiveTester.) ~x)) (comment user= (primitive-type 5) ;unboxed :long user= (primitive-type (Integer/parseInt 5)) ;unboxed :int user= (class (Integer/parseInt 5)) ;boxed java.lang.Long ) Justin -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Clojure 1.3 wonky behavior
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 helping me condense the snippet, and thanks to both @cemerick and @chouser for the lively discussion on IRC. Yet the discussion was inconclusive. Is the above expected behavior? Micah -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Rich Hickey: Simple Made Easy from Strange Loop 2011
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 function does. What it also has to mean is why the function does it. In order to write a program that lives, that is, one that can be maintained and changed you need to capture why the code exists and why it is written that way. The best solution I have found is called Literate Programming. The LP idea is that you write the program for the programmer rather than the machine. You should be able to sit and read a book that explains the program, including the why. The real code is in the document but the text explaining the program is the focus. I would encourage you to look at Lisp in Small Pieces. It is a literate program, a book, that contains a complete lisp system with the interpreter and compiler but it is written to be read. Tim Daly The hardest part of literate programming is the documentation On Thu, 2011-10-20 at 09:01 -0700, Alex Miller wrote: 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_made_easy_by_rich_hickey.html -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Question:Multi-Core processor affinity for load balancing Clojure Web apps
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 max IO capabilities at a lower cost. (Note that I currently using nginx, to route requests to a Clojure/Ring+Jetty web app on a specified port. I am expecting that in order to run 4 app instances I will need to load balance within nginx to each port and also set the processor affinity for each app instance to ensure they are balanced across cores). So here are my questions: 1. Does this idea make sense? why/whynot? 2. Do you do currently do this for your web apps and can you provide any insight/experiences that could be helpful? 3. Is there a way to specify processor affinity within the application, such that I wouldn't need to manually set them afterwards? 4. Are there better ideas to accomplish the same kind of thing? Thanks for any help/ideas. Tim -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Rich Hickey: Simple Made Easy from Strange Loop 2011
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 looked at our software, then wrote a talk on how not to do what we do here. Iif nothing else, at least my current job is teaching me the value of using Clojure at my next job. So for now, C# at workClojure at home, for everything else, there is beer. Timothy On Thu, Oct 20, 2011 at 1:01 PM, daly d...@axiom-developer.org wrote: 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 function does. What it also has to mean is why the function does it. In order to write a program that lives, that is, one that can be maintained and changed you need to capture why the code exists and why it is written that way. The best solution I have found is called Literate Programming. The LP idea is that you write the program for the programmer rather than the machine. You should be able to sit and read a book that explains the program, including the why. The real code is in the document but the text explaining the program is the focus. I would encourage you to look at Lisp in Small Pieces. It is a literate program, a book, that contains a complete lisp system with the interpreter and compiler but it is written to be read. Tim Daly The hardest part of literate programming is the documentation On Thu, 2011-10-20 at 09:01 -0700, Alex Miller wrote: 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_made_easy_by_rich_hickey.html -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 wonky behavior
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$Unbound cannot be cast to clojure.lang.IDeref Thanks to @cemerick for helping me condense the snippet, and thanks to both @cemerick and @chouser for the lively discussion on IRC. Yet the discussion was inconclusive. Is the above expected behavior? I'm not sure. Maybe it's undefined? Clojure compiles per top-level form. In this case this is the call to list. However in p does not exist before. It is created by the def inside this form. And maybe I'm just a weenie, but I wouldn't bet on some not very well documented peculiarities of def. From the “one top-level form” rule do is an exception. And indeed this seems to be for a reason: user= (do (declare ^:dynamic p) (defn q [] @p)) #'user/q user= (binding [p (atom 10)] (q)) 10 So maybe the rule of thumb is: never reference defs made in the same top-level form unless this form is a do. I'm sorry. I can't explain things further. I suspect that the effect you see is due to some accidental, implementation-dependent behavior of the compiler. Sincerely Meikel -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
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 Integer/valueOf, then Clojure will not change the Integer to a Long and will not prevent me from putting it in a collection. It's confusing that Integer/valueOf will stay an Integer in Clojure-land, and Integer/parseInt will become a Long in Clojure-land. The use case I'm interested in here is just this one point of Java interop: what Clojure does with primitive ints that it gets from a Java object (as far as I can tell, this is the only way to get a primitive int in Clojure 1.3). I think it's better that Clojure be consistent in its treatment of Integer objects and primitive ints by not changing the types on you. -Nathan On Oct 20, 10:19 am, Justin Kramer jkkra...@gmail.com wrote: 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) (getType [this ^long x] :long) ;; etc (getType [this ^Object x] :object)) (defmacro primitive-type [x] `(.getType (PrimitiveTester.) ~x)) (comment user= (primitive-type (Integer. 5)) :object user= (primitive-type (Integer/parseInt 5)) :int ) On Thursday, October 20, 2011 1:13:03 PM UTC-4, Justin Kramer wrote: 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 elided ) (defmacro primitive-type [x] `(.getType (PrimitiveTester.) ~x)) (comment user= (primitive-type 5) ;unboxed :long user= (primitive-type (Integer/parseInt 5)) ;unboxed :int user= (class (Integer/parseInt 5)) ;boxed java.lang.Long ) Justin -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
Oops, I meant Clojure should box primitive ints as Integers. :-) On Oct 20, 12:15 pm, nathanmarz nathan.m...@gmail.com 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 Longs. Stu, I wouldn't say Clojure's behavior makes it just work. For example, if I obtained by number using Integer/valueOf, then Clojure will not change the Integer to a Long and will not prevent me from putting it in a collection. It's confusing that Integer/valueOf will stay an Integer in Clojure-land, and Integer/parseInt will become a Long in Clojure-land. The use case I'm interested in here is just this one point of Java interop: what Clojure does with primitive ints that it gets from a Java object (as far as I can tell, this is the only way to get a primitive int in Clojure 1.3). I think it's better that Clojure be consistent in its treatment of Integer objects and primitive ints by not changing the types on you. -Nathan On Oct 20, 10:19 am, Justin Kramer jkkra...@gmail.com wrote: 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) (getType [this ^long x] :long) ;; etc (getType [this ^Object x] :object)) (defmacro primitive-type [x] `(.getType (PrimitiveTester.) ~x)) (comment user= (primitive-type (Integer. 5)) :object user= (primitive-type (Integer/parseInt 5)) :int ) On Thursday, October 20, 2011 1:13:03 PM UTC-4, Justin Kramer wrote: 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 elided ) (defmacro primitive-type [x] `(.getType (PrimitiveTester.) ~x)) (comment user= (primitive-type 5) ;unboxed :long user= (primitive-type (Integer/parseInt 5)) ;unboxed :int user= (class (Integer/parseInt 5)) ;boxed java.lang.Long ) Justin -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
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 change, the semantics gave you a free lunch around primitive ints in the interop scenario. Now you have be explicit just as you do with pretty much any kind of Java interop. David On Thu, Oct 20, 2011 at 3:16 PM, nathanmarz nathan.m...@gmail.com wrote: Oops, I meant Clojure should box primitive ints as Integers. :-) On Oct 20, 12:15 pm, nathanmarz nathan.m...@gmail.com 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 Longs. Stu, I wouldn't say Clojure's behavior makes it just work. For example, if I obtained by number using Integer/valueOf, then Clojure will not change the Integer to a Long and will not prevent me from putting it in a collection. It's confusing that Integer/valueOf will stay an Integer in Clojure-land, and Integer/parseInt will become a Long in Clojure-land. The use case I'm interested in here is just this one point of Java interop: what Clojure does with primitive ints that it gets from a Java object (as far as I can tell, this is the only way to get a primitive int in Clojure 1.3). I think it's better that Clojure be consistent in its treatment of Integer objects and primitive ints by not changing the types on you. -Nathan On Oct 20, 10:19 am, Justin Kramer jkkra...@gmail.com wrote: 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) (getType [this ^long x] :long) ;; etc (getType [this ^Object x] :object)) (defmacro primitive-type [x] `(.getType (PrimitiveTester.) ~x)) (comment user= (primitive-type (Integer. 5)) :object user= (primitive-type (Integer/parseInt 5)) :int ) On Thursday, October 20, 2011 1:13:03 PM UTC-4, Justin Kramer wrote: 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 elided ) (defmacro primitive-type [x] `(.getType (PrimitiveTester.) ~x)) (comment user= (primitive-type 5) ;unboxed :long user= (primitive-type (Integer/parseInt 5)) ;unboxed :int user= (class (Integer/parseInt 5)) ;boxed java.lang.Long ) Justin -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Question:Multi-Core processor affinity for load balancing Clojure Web apps
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 behaviour of the application under heavy concurrent access - I would be amazed if you any benefit from your approach. I wouldn't be surprised at all if it becomes much worse - sorry :). Note; I am not a performance specialist and even if I claimed to be one you should always take advice with a pinch of salt. It should be fairly easy to measure the difference between the two deployment models yourself. Sorry. On 20 October 2011 19:41, Tim Robinson tim.blacks...@gmail.com wrote: 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 max IO capabilities at a lower cost. (Note that I currently using nginx, to route requests to a Clojure/Ring+Jetty web app on a specified port. I am expecting that in order to run 4 app instances I will need to load balance within nginx to each port and also set the processor affinity for each app instance to ensure they are balanced across cores). So here are my questions: 1. Does this idea make sense? why/whynot? 2. Do you do currently do this for your web apps and can you provide any insight/experiences that could be helpful? 3. Is there a way to specify processor affinity within the application, such that I wouldn't need to manually set them afterwards? 4. Are there better ideas to accomplish the same kind of thing? Thanks for any help/ideas. Tim -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
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 the benefit of boxing primitive ints as Longs given how Integer objects are treated. Right now, if you obtain an Integer object via interop and want it to be compatible with Clojure's regular numerics, you still have to manually convert that Integer object into a Long. What I'm proposing is that you treat primitive ints obtained via interop the exact same way, which avoids the weird type issues that I ran into. -Nathan On Oct 20, 12:26 pm, David Nolen dnolen.li...@gmail.com wrote: 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 change, the semantics gave you a free lunch around primitive ints in the interop scenario. Now you have be explicit just as you do with pretty much any kind of Java interop. David On Thu, Oct 20, 2011 at 3:16 PM, nathanmarz nathan.m...@gmail.com wrote: Oops, I meant Clojure should box primitive ints as Integers. :-) On Oct 20, 12:15 pm, nathanmarz nathan.m...@gmail.com 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 Longs. Stu, I wouldn't say Clojure's behavior makes it just work. For example, if I obtained by number using Integer/valueOf, then Clojure will not change the Integer to a Long and will not prevent me from putting it in a collection. It's confusing that Integer/valueOf will stay an Integer in Clojure-land, and Integer/parseInt will become a Long in Clojure-land. The use case I'm interested in here is just this one point of Java interop: what Clojure does with primitive ints that it gets from a Java object (as far as I can tell, this is the only way to get a primitive int in Clojure 1.3). I think it's better that Clojure be consistent in its treatment of Integer objects and primitive ints by not changing the types on you. -Nathan On Oct 20, 10:19 am, Justin Kramer jkkra...@gmail.com wrote: 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) (getType [this ^long x] :long) ;; etc (getType [this ^Object x] :object)) (defmacro primitive-type [x] `(.getType (PrimitiveTester.) ~x)) (comment user= (primitive-type (Integer. 5)) :object user= (primitive-type (Integer/parseInt 5)) :int ) On Thursday, October 20, 2011 1:13:03 PM UTC-4, Justin Kramer wrote: 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 elided ) (defmacro primitive-type [x] `(.getType (PrimitiveTester.) ~x)) (comment user= (primitive-type 5) ;unboxed :long user= (primitive-type (Integer/parseInt 5)) ;unboxed :int user= (class (Integer/parseInt 5)) ;boxed java.lang.Long ) Justin -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
On Thu, Oct 20, 2011 at 3:45 PM, nathanmarz nathan.m...@gmail.com 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. You do know that Clojure now supports primitive args and return, right? How is what you proposing going to be reconciled with that? David -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
On Thu, Oct 20, 2011 at 12:45 PM, nathanmarz nathan.m...@gmail.com 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 is. 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 the benefit of boxing primitive ints as Longs given how Integer objects are treated. Right now, if you obtain an Integer object via interop and want it to be compatible with Clojure's regular numerics, you still have to manually convert that Integer object into a Long. What I'm proposing is that you treat primitive ints obtained via interop the exact same way, which avoids the weird type issues that I ran into. -Nathan On Oct 20, 12:26 pm, David Nolen dnolen.li...@gmail.com wrote: 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 change, the semantics gave you a free lunch around primitive ints in the interop scenario. Now you have be explicit just as you do with pretty much any kind of Java interop. David On Thu, Oct 20, 2011 at 3:16 PM, nathanmarz nathan.m...@gmail.com wrote: Oops, I meant Clojure should box primitive ints as Integers. :-) On Oct 20, 12:15 pm, nathanmarz nathan.m...@gmail.com 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 Longs. Stu, I wouldn't say Clojure's behavior makes it just work. For example, if I obtained by number using Integer/valueOf, then Clojure will not change the Integer to a Long and will not prevent me from putting it in a collection. It's confusing that Integer/valueOf will stay an Integer in Clojure-land, and Integer/parseInt will become a Long in Clojure-land. The use case I'm interested in here is just this one point of Java interop: what Clojure does with primitive ints that it gets from a Java object (as far as I can tell, this is the only way to get a primitive int in Clojure 1.3). I think it's better that Clojure be consistent in its treatment of Integer objects and primitive ints by not changing the types on you. -Nathan On Oct 20, 10:19 am, Justin Kramer jkkra...@gmail.com wrote: 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) (getType [this ^long x] :long) ;; etc (getType [this ^Object x] :object)) (defmacro primitive-type [x] `(.getType (PrimitiveTester.) ~x)) (comment user= (primitive-type (Integer. 5)) :object user= (primitive-type (Integer/parseInt 5)) :int ) On Thursday, October 20, 2011 1:13:03 PM UTC-4, Justin Kramer wrote: 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 elided ) (defmacro primitive-type [x] `(.getType (PrimitiveTester.) ~x)) (comment user= (primitive-type 5) ;unboxed :long user= (primitive-type (Integer/parseInt 5)) ;unboxed :int user= (class (Integer/parseInt 5)) ;boxed java.lang.Long ) Justin -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- And what is good, Phaedrus,
Re: Clojure 1.3 treatment of integers and longs
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 orthogonal to primitive args/return, but correct me if I'm wrong. Right now, it boxes ints as a Long, which I think is changing the type. My proposal is that it box ints as Integer objects. Would changing the behavior in this way cause a fundamental performance limitation in Clojure? -Nathan On Oct 20, 12:50 pm, David Nolen dnolen.li...@gmail.com wrote: On Thu, Oct 20, 2011 at 3:45 PM, nathanmarz nathan.m...@gmail.com 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. You do know that Clojure now supports primitive args and return, right? How is what you proposing going to be reconciled with that? David -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 wonky behavior
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 the preceding declare has not yet executed - it has only compiled. - Chris -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 wonky behavior
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 #Unbound Unbound: #'user/yyy Well, I learned something today. - Chris -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is there a reader setting support BigDecimal by default?
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. This includes a group insurance rate engine that generated hundreds of thousands of calculations in each web request. Second, storing values with implied decimal points is a nightmare. In the insurance application for example, some of the rate tables have precision to three decimal places, others to five. Picking some arbitrary value imposes code complexity throughout the whole in app in a very nasty way. Of course, what happens when you need to change that value two years from now? Unless there's a really good performance issue for a given application, I would never pick implied decimal representation over BigDecimals. Finally, for the business applications I've worked with, I haven't had to worry about representing all rationals, just base 10 numbers. In my experience, using BigDecimal by default for any number with a decimal point has worked out very well for balancing the needs of accuracy, speed and code complexity. 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 -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is there a reader setting support BigDecimal by default?
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 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is there a reader setting support BigDecimal by default?
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 guarantees you want from BigDecimals. Why is the upstream provider using doubles? 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is there a reader setting support BigDecimal by default?
On Thu, Oct 20, 2011 at 22:50, Stuart Halloway stuart.hallo...@gmail.com 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 somebody upstream of you was using doubles, which violates the guarantees you want from BigDecimals. Why is the upstream provider using doubles? I don't follow. The OP has text, which Clojure is reading as doubles. This only implies that upstream (which need not have been written in Clojure) is producing numbers matching #[-]?[1-9][0-9]*[.][0-9]*|0, because LispReader interprets that as Double. Whatever internal representation this text was produced form may or may not have been (binary) floating point initially. It doesn't seem reasonable to assume that the OP's 'business' applications I've built over the last 25 years could have known that Clojure would come along later and expect to find M on the end of every decimal number. // Ben // Ben -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is there a reader setting support BigDecimal by default?
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 guarantees you want from BigDecimals. Why is the upstream provider using doubles? I don't follow. The OP has text, which Clojure is reading as doubles. This only implies that upstream (which need not have been written in Clojure) is producing numbers matching #[-]?[1-9][0-9]*[.][0-9]*|0, because LispReader interprets that as Double. Whatever internal representation this text was produced form may or may not have been (binary) floating point initially. It doesn't seem reasonable to assume that the OP's 'business' applications I've built over the last 25 years could have known that Clojure would come along later and expect to find M on the end of every decimal number. // Ben Hmm, highly apropos discussion since Rich's talk on simplicity posted today. The reader does one thing: read Clojure data. Sometimes you need something else: read data written in another format. You might accomplish that by (1) making the reader able to do two things, adding a flag to deal with a specific format, or (2) by using a different reader for that job. (2) is hands-down the right answer. 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is there a reader setting support BigDecimal by default?
On Thu, Oct 20, 2011 at 23:16, Stuart Halloway stuart.hallo...@gmail.com 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 somebody upstream of you was using doubles, which violates the guarantees you want from BigDecimals. Why is the upstream provider using doubles? I don't follow. The OP has text, which Clojure is reading as doubles. This only implies that upstream (which need not have been written in Clojure) is producing numbers matching #[-]?[1-9][0-9]*[.][0-9]*|0, because LispReader interprets that as Double. Whatever internal representation this text was produced form may or may not have been (binary) floating point initially. It doesn't seem reasonable to assume that the OP's 'business' applications I've built over the last 25 years could have known that Clojure would come along later and expect to find M on the end of every decimal number. // Ben Hmm, highly apropos discussion since Rich's talk on simplicity posted today. The reader does one thing: read Clojure data. Sometimes you need something else: read data written in another format. You might accomplish that by (1) making the reader able to do two things, adding a flag to deal with a specific format, or (2) by using a different reader for that job. (2) is hands-down the right answer. No argument there. The Clojure reader's job is to read Clojure. If your have some data that happens to be syntactically compatible, fine, but if not the Clojure reader isn't the right tool. One obvious approach would be a to use a regular expression to identify the numbers in the text to be parsed and #(BigDecimal. ^String %) to do the actual conversion. // Ben -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 wonky behavior
On Thu, Oct 20, 2011 at 4:31 PM, Chris Perkins chrisperkin...@gmail.com 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 (defn xxx [] (declare yyy))
#'user/xxx
user yyy
#Unbound Unbound: #'user/yyy
Well, I learned something today.
But it only interns the Var, it doesn't fully set it up. Particularly
relevant to the OP's example is that the metadata from the name symbol
is not transferred to the Var (and the changes to the Var based on
:dynamic are not applied) until runtime for the 'def', even though the
Var exists at compile time.
Here's a macro that expands at compile time to the *compile* time
metadata of the var named in its argument:
(defmacro compile-time-meta [x] (meta (resolve x)))
Now observe how it behaves differently than a runtime call to 'meta':
(vector
(declare ^:dynamic *myvar*)
(meta #'*myvar*)
(compile-time-meta #'*myvar*)))
The above returns:
[#'user/*myvar*
{:ns #Namespace user, :name *myvar*, :dynamic true, :declared true, ...}
{:ns #Namespace user, :name #Unbound Unbound: #'user/*myvar*}]
First is the Var itself.
Next is the metadata of the Var at runtime, after the entire form has
been compiled and therefore the metadata from the name has been
applied to the Var, including the :dynamic flag.
Finally we see that when our macro was expanded the Var existed but
had minimal metadata. This was after the declare was compiled but
before any part of the 'vector' form was run. There is no :dynamic
flag, and anything that depends on that flag at compile time to work
correctly (such as a function that refers the for Var) will fail to
work correctly.
--Chouser
--
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 group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Finding a function's expected argument list length
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 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
On Thu, Oct 20, 2011 at 1:11 PM, nathanmarz nathan.m...@gmail.com 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 expects an int) - based on what I've understood of the numerics discussions. Similarly, you only have a primitive float if you coerce the value. So Clojure boxes a long as Long. If you want to box a long as Integer, you have to explicitly say so: (Integer. 42) - and Clojure will give you an Integer and not do anything to it. (Is my understanding correct? I'm finding the discussion interesting but not 100% sure whether I fully understand Clojure 1.3's primitive numerics) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
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 type as a significant cost in a computation. One of the purpose of normalizing to 64 bits was to get maximum performance for compute bound Clojure applications. Computing with wrappers is inefficient. Your proposal looks only at one facet of the whole problem. It's not a Java centric issue, it's a Clojure performance enhancement. You are coding in Clojure, not in Java. It happens that Clojure reuses some native types efficiently implemented by the JVM and used by Java (String, long, ) but not all of them. Let's say one day you end up coding in ClojureScript or Clojure on JS, what do you prefer ? Deal with idiosyncrasies of the underlying environment or have a consistent implementation that provides the best performance for that given pseudo-metal ? What about the day that long long (128 bits) comes around ? Clojure will drag behind because it's carrying 32 bit values ? Obviously it creates issues when you work at the fringe but interop is not the purpose of Clojure. It happens to be much more easier to access the outside world than in other environments but it cannot justify to compromise the performance or feature list of Clojure. Luc P. On Thu, 20 Oct 2011 13:11:40 -0700 (PDT) nathanmarz nathan.m...@gmail.com 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 does when it has to box a primitive int. I think this is orthogonal to primitive args/return, but correct me if I'm wrong. Right now, it boxes ints as a Long, which I think is changing the type. My proposal is that it box ints as Integer objects. Would changing the behavior in this way cause a fundamental performance limitation in Clojure? -Nathan On Oct 20, 12:50 pm, David Nolen dnolen.li...@gmail.com wrote: On Thu, Oct 20, 2011 at 3:45 PM, nathanmarz nathan.m...@gmail.com 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. You do know that Clojure now supports primitive args and return, right? How is what you proposing going to be reconciled with that? David -- Luc P. The rabid Muppet -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Will clojurescript get in-ns and load?
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 daves...@gmail.com wrote: 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 managed as a compile time operation to merge the namespaces. Perhaps there are better ways of achieving this that I am not aware of. Cheers D -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
partial, but instead of args + additional, get additional + args
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 partial, I wanna do something: (take-while (rpartial 2000) primes) 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 function on default that works as reversed arguments partial (appending partial arguments at end instead of beginning)? If it don't, is not a good idea to have one? --- Wilker Lúcio http://about.me/wilkerlucio/bio Kajabi Consultant +55 81 82556600 -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Rich Hickey: Simple Made Easy from Strange Loop 2011
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@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure jar files.
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 build tool which people use does the same thing? -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Finding a function's expected argument list length
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 of acceptable arities with them, but I haven't thought very hard about it - perhaps the performance implication this imposes on every function isn't worth it for the small minority of times when you need to ask the question. On Oct 20, 5:58 pm, Alex Baranosky alexander.barano...@gmail.com wrote: 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 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Finding a function's expected argument list length
In a REPL,
user (defn hello [name]
(println hi, name))
#'user/hello
user (meta (var hello))
{:ns #Namespace user, :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 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 group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Clojure jar files.
Manoj, On Fri, Oct 21, 2011 at 9:09 AM, mmwaikar mmwai...@gmail.com 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 and that's all I know - so I was curious to know if every other build tool which people use does the same thing? Clojure has a lot of Clojure code as well! The only difference is that it doesn't use Leiningen for building the project, but instead uses Maven directly. If you are going to upload your library to any Maven (or similar) repo that's accessible through Leiningen, then you may choose to not include a project.clj file; in any case, if you yourself are using Leiningen, you should include that file. FWIW, Leiningen can generate pom.xml files from project.clj as well. Regards, BG -- Baishampayan Ghose b.ghose at gmail.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. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Finding a function's expected argument list length
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 anything anything anything anything anything) = anything :never )) Knowing the arity of the function would have helped with the internals. On Thu, Oct 20, 2011 at 11:42 PM, Alan Malloy a...@malloys.org wrote: 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 of acceptable arities with them, but I haven't thought very hard about it - perhaps the performance implication this imposes on every function isn't worth it for the small minority of times when you need to ask the question. On Oct 20, 5:58 pm, Alex Baranosky alexander.barano...@gmail.com wrote: 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 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: partial, but instead of args + additional, get additional + args
On Thu, Oct 20, 2011 at 8:15 PM, Wilker wilkerlu...@gmail.com 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 function on default that works as reversed arguments partial (appending partial arguments at end instead of beginning)? I was expressing a need for exactly this function the other day on IRC. I jokingly called it 'impartial' :) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Finding a function's expected argument list length
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 mmwai...@gmail.com wrote:
In a REPL,
user (defn hello [name]
(println hi, name))
#'user/hello
user (meta (var hello))
{:ns #Namespace user, :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 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 group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
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 group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: partial, but instead of args + additional, get additional + args
Hi, Am 21.10.2011 um 06:01 schrieb Sean Corfield: On Thu, Oct 20, 2011 at 8:15 PM, Wilker wilkerlu...@gmail.com 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 would probably write the other case as #( 2000 %) instead of using partial. The only advantages of partial are a) that it acts like #(apply 2000 %) (to stay in the example) and b) that it generates one class less compared to #(). Sincerely Meikel -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
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 primitive int, then the only change I'm proposing is that
if Clojure needs to box that value later on, that it box it as an
Integer instead of a Long. This change in behavior would not affect
primitive number performance since it's at a point when Clojure is
already boxing.
If i is a primitive long (which is what I thought was happening
originally), I propose that Clojure box the value as an Integer unless
you wrap the form in a (long ...) form. In the latter case Clojure
would do what it's doing currently so you can still get the
performance if you need it. The difference is that you're being
explicit about the type changing so there's no possible confusion in
that regard.
Finally, if i is a Long object, I propose that it instead be boxed
as an Integer object.
Note that I am not saying:
1. That Clojure always box primitives into an object form
2. That Clojure implement 32 bit arithmetic
In all these cases, you can still get maximum performance without
Clojure changing ints to longs. Please correct me if there's something
I'm missing here.
Stu's argument from above is that Clojure boxes ints to Longs instead
of Integer to avoid weirdness with hashcode/equality in collections.
This is a reasonable point, but consider this code example:
user= (def m1 {(Integer/valueOf 1) 2})
#'user/m1
user= (def m2 {(Integer/parseInt 1) 2})
#'user/m2
user= (map class (keys m1))
(java.lang.Integer)
user= (map class (keys m2))
(java.lang.Long)
Clojure doesn't prevent you from putting Integer objects in
collections. So there are cases where you still need to do type
coercion yourself. Given that Clojure can't hide this problem
completely from you, I think it's better that it treat int and
Integer consistently by boxing ints as Integers. Then there's no
weirdness like I ran into with getting ClassCastExceptions because the
type changed.
-Nathan
On Oct 20, 6:19 pm, David Nolen dnolen.li...@gmail.com wrote:
On Thu, Oct 20, 2011 at 4:11 PM, nathanmarz nathan.m...@gmail.com 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 does when it has to box a primitive int.
I think this is orthogonal to primitive args/return, but correct me if
I'm wrong.
If 32bit ints are allowed to exist then the various numeric operators must
handle them. If the numeric operators handle them then primitive arg and
return should probably be supported. But that would exponentially increase
the number of interfaces required for primitive arg return support.
David
--
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 group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: partial, but instead of args + additional, get additional + args
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 m...@kotka.de wrote: Hi, Am 21.10.2011 um 06:01 schrieb Sean Corfield: On Thu, Oct 20, 2011 at 8:15 PM, Wilker wilkerlu...@gmail.com 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 would probably write the other case as #( 2000 %) instead of using partial. The only advantages of partial are a) that it acts like #(apply 2000 %) (to stay in the example) and b) that it generates one class less compared to #(). Sincerely Meikel -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
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 would happen. On Oct 20, 9:11 pm, nathanmarz nathan.m...@gmail.com wrote: 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? -- 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 group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
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'm proposing is that when Clojure needs to box a primitive int,
that Clojure box it as an Integer rather than a Long. Then this code
example:
(let [m {:a (Integer/parseInt 1)}]
(map class (vals m)))
will behave the same as this one:
(let [m {:a (Integer/valueOf 1)}]
(map class (vals m)))
-Nathan
On Oct 20, 9:35 pm, Alan Malloy a...@malloys.org wrote:
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 would happen.
On Oct 20, 9:11 pm, nathanmarz nathan.m...@gmail.com wrote:
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?
--
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 group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: About metadat and #^ macro.
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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 treatment of integers and longs
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=
Integer/parseInt returns a primitive type. Not a boxed Integer object.
If used as a key in a map or anything else in Clojure, it will get promoted to
a long value as per the math
promotion rules (long/double representation). Obviously needed if it is to be
used later in a computation
otherwise it would break math operations consistency by allowing mixed int/long
operands.
If passed as an interop parameter it will retain it's int type.
user= (class (Integer/valueOf 1))
java.lang.Integer
Integer/valueOf returns an Integer object, not a primitive type.
It's an object, not a primitive type, Clojure will not change it.
If used as a key in a Clojure map or any Clojure data structure, it will retain
its object status.
Just cast your keys accordingly if you want Integer objects as keys.
In your short example, 1 as a key will not do it, it gets promoted to primitive
long.
You may not recall but in Java, int used not to be compatible with Integer
objects.
It's only since java 5 that you can assign an Integer object to a primitive int.
That's the compiler tricking things to allow you to do that. In the JVM there's
still
not represented in the same way.
The above Integer member functions and their behavior have nothing to do with
Clojure.
They result from bad decisions made years ago when designing Java and the JVM
and you are blaming
Clojure for not handling them according to some patch implemented afterward in
the Java compiler.
You ran in the ClassCast exception by yourself. Clojure did not push you into
it.
When using Java interop you have to obey to Java rules and bend accordingly.
It's not Clojure that needs to bend, it's you to adapt to the interop
restrictions/conventions.
If Java expects an Integer object somewhere make sure you are providing it.
Luc P.
On Thu, 20 Oct 2011 21:11:41 -0700 (PDT)
nathanmarz nathan.m...@gmail.com wrote:
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 primitive int, then the only change I'm proposing is that
if Clojure needs to box that value later on, that it box it as an
Integer instead of a Long. This change in behavior would not affect
primitive number performance since it's at a point when Clojure is
already boxing.
If i is a primitive long (which is what I thought was happening
originally), I propose that Clojure box the value as an Integer unless
you wrap the form in a (long ...) form. In the latter case Clojure
would do what it's doing currently so you can still get the
performance if you need it. The difference is that you're being
explicit about the type changing so there's no possible confusion in
that regard.
Finally, if i is a Long object, I propose that it instead be boxed
as an Integer object.
Note that I am not saying:
1. That Clojure always box primitives into an object form
2. That Clojure implement 32 bit arithmetic
In all these cases, you can still get maximum performance without
Clojure changing ints to longs. Please correct me if there's something
I'm missing here.
Stu's argument from above is that Clojure boxes ints to Longs instead
of Integer to avoid weirdness with hashcode/equality in collections.
This is a reasonable point, but consider this code example:
user= (def m1 {(Integer/valueOf 1) 2})
#'user/m1
user= (def m2 {(Integer/parseInt 1) 2})
#'user/m2
user= (map class (keys m1))
(java.lang.Integer)
user= (map class (keys m2))
(java.lang.Long)
Clojure doesn't prevent you from putting Integer objects in
collections. So there are cases where you still need to do type
coercion yourself. Given that Clojure can't hide this problem
completely from you, I think it's better that it treat int and
Integer consistently by boxing ints as Integers. Then there's no
weirdness like I ran into with getting ClassCastExceptions because the
type changed.
-Nathan
On Oct 20, 6:19 pm, David Nolen dnolen.li...@gmail.com wrote:
On Thu, Oct 20, 2011 at 4:11 PM, nathanmarz nathan.m...@gmail.com
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 does when it has to
box a primitive int. I think this is orthogonal to primitive
args/return, but correct me if I'm wrong.
If 32bit ints are allowed to exist then the various numeric
operators must
