how can I dispatch on "[[F" ..
Hello Everybody, I would like to know how to have one of the multimethods dispatch on [[F (2d-array of float) .. I don't know how to say that in the code .. I can say Integer Double etc.. How do I say 2-d-array of floats? what is the literal representation of [[F... I am not sure if I am clear with my question .. I remember somebody had before used something like this .. but I am unable to find it right now... Thanks, Sunil. -- 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: how can I dispatch on "[[F" ..
On Fri, Jan 14, 2011 at 3:53 AM, Sunil S Nandihalli wrote: > Hello Everybody, > I would like to know how to have one of the multimethods dispatch on [[F > (2d-array of float) .. I don't know how to say that in the code .. I can > say Integer Double etc.. How do I say 2-d-array of floats? what is the > literal representation of [[F... I am not sure if I am clear with my > question .. I remember somebody had before used something like this .. but I > am unable to find it right now... I don't think there is a literal representation, but you also don't need it to be literal: user=> (defmulti foo #(vector (type %1) (type %2))) #'user/foo user=> (defmethod foo [(type (make-array (type (float-array 0)) 0)) String] [x y] (println "[[F and String")) # user=> (foo (make-array (type (float-array 0)) 0) "foo") [[F and String nil There may still be a somewhat more elegant way of getting the type; I just promise that this way works. :) -- 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: Java namespaces, Cobol, and Hierarchical file systems
On Thursday, January 13, 2011 5:54:17 PM UTC+1, TimDaly wrote: [snip] > In sum, I'm suggesting that it isn't very lispy to use > hierarchical namespace naming conventions. > I think all you said is very true... *if* the user of a namespace is allowed to change its name (i.e. Common Lisp's RENAME-PACKAGE). In Java, you obviously can't; I don't know Clojure well enough, but I suspect you can't, either. So, in case two third-party namespaces collide, there's no solution. Thus a collision-avoiding naming scheme becomes more important. (Note: I'm not advocating the blind use of Java conventions; in my "Dynaspring" project, which is coded in a mix of Lisp and Java, the Java package is just "dynaspring" and the Lisp one is :spring, because I find it very improbable that someone else will release another library using the same package names and that someone else will use both libraries in his or her project). Just my .02€ Alessio -- 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: how can I dispatch on "[[F" ..
How about (def float-2D (class (make-array Float/TYPE 1 1)))? sincerely, --Robert McIntyre On Fri, Jan 14, 2011 at 4:07 AM, Ken Wesson wrote: > On Fri, Jan 14, 2011 at 3:53 AM, Sunil S Nandihalli > wrote: >> Hello Everybody, >> I would like to know how to have one of the multimethods dispatch on [[F >> (2d-array of float) .. I don't know how to say that in the code .. I can >> say Integer Double etc.. How do I say 2-d-array of floats? what is the >> literal representation of [[F... I am not sure if I am clear with my >> question .. I remember somebody had before used something like this .. but I >> am unable to find it right now... > > I don't think there is a literal representation, but you also don't > need it to be literal: > > user=> (defmulti foo #(vector (type %1) (type %2))) > #'user/foo > user=> (defmethod foo [(type (make-array (type (float-array 0)) 0)) > String] [x y] (println "[[F and String")) > # > user=> (foo (make-array (type (float-array 0)) 0) "foo") > [[F and String > nil > > There may still be a somewhat more elegant way of getting the type; I > just promise that this way works. :) > > -- > 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
Clojure and Android update status
Hello, Say I want to write an app in Clojure for Android. The kind of app which does not require endless restarts. Would you recommand me to go for it ? And if so, what's the current "best way" of doing this ? I've seen many "ports", "special builds" of clojure for Android, but they seem to be dated (late 2009). Is this because right now with clojure 1.2 I can just go with the official 1.2 build ? Or because people lost interest in 2010 for the "Clojure + Android" combo, and are waiting for a solution to come from Clojure/core ? Thanks in advance if you can help me update the status of Android+clojure combo for people having to make a decision for immediate needs. Regards, -- Laurent -- 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: how can I dispatch on "[[F" ..
Or: (defmethod foo (clojure.lang.RT/classForName "[[F") ...) -- 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 Job Opening in Amsterdam area
Hi Clojurians, My employer Sourcesense is looking for Clojure Developer to hire/contract in Amsterdam area. Please see opening details http://www.sourcesense.nl/careers/#clj Best regards, Hubert Iwaniuk. -- 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
draining file of s-expressions
Let's say I've got a finite, unknown number of valid clojure forms in a file, say like this: (foo)(bar)[blah blah blah](and one more) (note there is a vector sandwiched in there too) Let's say I open this file and want to use it with read: (read f) => (foo) I do it again, and: (read f) => (bar) Not what I want...I need all this data, not each one individually. What's the idiomatic clojure way to basically drain this file of clojure data structures (say, put them in a lazy seq)? I'm guessing that I need to call (read f) in some sort of do* method, wrapped in a (try ... (catch)) block for when I encounter end-of-file, but I really don't understand side effects and file handling in clojure too well. Any advice? Thanks guys... Mike -- 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: draining file of s-expressions
Hi, you can use lazy-seq: (def eof-marker (Object.)) (defn read-all [stream] (lazy-seq (let [x (read stream false eof-marker)] (when-not (identical? x eof-marker) (cons x (read-all stream)) Or go for high-level: (def eof-marker (Object.)) (defn read-all [stream] (take-while #(not (identical? % eof-marker)) (repeatedly #(read stream false eof-marker 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: draining file of s-expressions
Wow, that's awesome, thanks for the quick reply. I found when I opened the stream with (with-open ...) the lazy seq would throw an exception because the stream is already closed by the time the repl is trying to print it, so I forced it with a doall: (with-open [f (open-my-file "foo.exprs")] (doall (read-all f))) Thanks again Meikel... Mike On Jan 14, 7:08 am, Meikel Brandmeyer wrote: > Hi, > > you can use lazy-seq: > > (def eof-marker (Object.)) > > (defn read-all > [stream] > (lazy-seq > (let [x (read stream false eof-marker)] > (when-not (identical? x eof-marker) > (cons x (read-all stream)) > > Or go for high-level: > > (def eof-marker (Object.)) > > (defn read-all > [stream] > (take-while #(not (identical? % eof-marker)) (repeatedly #(read > stream false eof-marker > > 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
ClojureScript Help
I was browsing the ClojureScript source on GitHub and saw the request for help. I'm interested in what the grocery-list of tasks for ClojureScript are, so that I might poke around with a little more direction and focus. Thanks! --Aaron -- 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 and Android update status
There was recently a stack overflow thread on this: http://stackoverflow.com/questions/4651757/clojure-on-android/4675855#4675855 One of the people who replied (Arthur Ulfeldt) says that JIT has helped greatly with performance. So maybe it's time to revisit it. It looks like remvee's example code has been upkept based on the commit history https://github.com/remvee/clojurehelloandroid On Fri, Jan 14, 2011 at 4:21 AM, Laurent PETIT wrote: > Hello, > > Say I want to write an app in Clojure for Android. > > The kind of app which does not require endless restarts. > > Would you recommand me to go for it ? > > And if so, what's the current "best way" of doing this ? > > I've seen many "ports", "special builds" of clojure for Android, but they > seem to be dated (late 2009). > > Is this because right now with clojure 1.2 I can just go with the official > 1.2 build ? Or because people lost interest in 2010 for the "Clojure + > Android" combo, and are waiting for a solution to come from Clojure/core ? > > > Thanks in advance if you can help me update the status of Android+clojure > combo for people having to make a decision for immediate needs. > > Regards, > > -- > Laurent > > -- > 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 and Android update status
Thanks Rob, I hadn't seen this very recent thread ! 2011/1/14 rob levy > There was recently a stack overflow thread on this: > http://stackoverflow.com/questions/4651757/clojure-on-android/4675855#4675855 > > One of the people who replied (Arthur Ulfeldt) says that JIT has helped > greatly with performance. So maybe it's time to revisit it. It looks like > remvee's example code has been upkept based on the commit history > https://github.com/remvee/clojurehelloandroid > > On Fri, Jan 14, 2011 at 4:21 AM, Laurent PETIT wrote: > >> Hello, >> >> Say I want to write an app in Clojure for Android. >> >> The kind of app which does not require endless restarts. >> >> Would you recommand me to go for it ? >> >> And if so, what's the current "best way" of doing this ? >> >> I've seen many "ports", "special builds" of clojure for Android, but they >> seem to be dated (late 2009). >> >> Is this because right now with clojure 1.2 I can just go with the official >> 1.2 build ? Or because people lost interest in 2010 for the "Clojure + >> Android" combo, and are waiting for a solution to come from Clojure/core ? >> >> >> Thanks in advance if you can help me update the status of Android+clojure >> combo for people having to make a decision for immediate needs. >> >> Regards, >> >> -- >> Laurent >> >> -- >> 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 -- 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: [ANN] fs - file system utilities for Clojure
> First, I suggest that you look at the standard clojure.java.io package for > some useful functions that are already in Clojure 1.2. > Done in 0.3.0 (as well as some other added functions), thanks again. -- 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
fns taking primitives support only 4 or fewer args
Today I evaluated John Lawrence Aspden's Clojure port of a fractal tree program which contains optimisations targeting 1.3: http://www.learningclojure.com/2010/09/clojure-13-first-impression.html Unfortunately, this no longer compiles with 1.3.0-alpha4 as draw-tree has too many arguments: "CompilerException java.lang.IllegalArgumentException: fns taking primitives support only 4 or fewer args" The signature of the offending function is as follows: (defn ^:static draw-tree [ #^Graphics g2d ^double angle ^double x ^double y ^double length ^double branch-angle ^long depth] ...) I was wondering what purpose the '4 or fewer args' restriction serves and therefore how you might retain the performance of this implementation with 1.3.0-alpha4 and beyond (assuming the restriction is here to stay). Would you have to break out into a number of smaller fns calculating the new x, y length and angle vals? Sam --- http://sam.aaron.nmae -- 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: fns taking primitives support only 4 or fewer args
On Fri, Jan 14, 2011 at 12:07 PM, Sam Aaron wrote: > I was wondering what purpose the '4 or fewer args' restriction serves and > therefore how you might retain the performance of this implementation with > 1.3.0-alpha4 and beyond (assuming the restriction is here to stay). Would > you have to break out into a number of smaller fns calculating the new x, y > length and angle vals? > Interfaces have to defined for every combination of primitive arguments - so you get interface explosion, thus only 4. Not ideal, but that's how it is for now. Looking at that signature (6 arguments?), that should probably be refactored anyway - sounds like a good use case for deftype. 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: fns taking primitives support only 4 or fewer args
On Fri 14/01/11 17:07 , Sam Aaron samaa...@gmail.com sent: > Today I evaluated John Lawrence Aspden's Clojure port of a fractal tree > program which contains optimisations targeting 1.3: > http://www.learningclojure.com/2010/09/clojure-13-first-impress > ion.html > Unfortunately, this no longer compiles with 1.3.0-alpha4 as draw-tree has > too many arguments: > "CompilerException java.lang.IllegalArgumentException: fns taking > primitives support only 4 or fewer args" > The signature of the offending function is as follows: > > (defn ^:static draw-tree [ #^Graphics g2d ^double angle ^double x ^double y > ^double length ^double branch-angle ^long depth] ...) Note that from what I understand, ^:static doesn't do anything any more. (Despite it appearing in core.clj in a few places). In early snapshots of 1.3, primitive arguments were implemented by ^:static, which caused the function implementation class to get augmented with a static method with primitive arguments. There were a number of limitations of this approach - for instance it only supported top-level functions, not closures; and I think it lacked some of the dynamic features of normal features. The new implementation of primitive functions doesn't require the ^:static tag, but it does limit the function to a maximum of 4 args. As David Nolen suggests, deftypes/defrecords support primitive fields, so wrapping the arguments in this way is probably the easiest option. -- 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: fns taking primitives support only 4 or fewer args
On 14 January 2011 19:07, Sam Aaron wrote: [...] > --- > http://sam.aaron.nmae I don't know the answer to your question, but I thought I'd point out the typo in your signature. -- Michael Wood -- 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: fns taking primitives support only 4 or fewer args
> Interfaces have to defined for every combination of primitive arguments - so > you get interface explosion, thus only 4. Not ideal, but that's how it is > for now. Why the explosion, since the parameter hints indicate a specific signature? > > Looking at that signature (6 arguments?), that should probably be refactored > anyway - sounds like a good use case for deftype. I'll hazard a guess: it should be refactored down to 4 for proper design! (I suspect it took just 4 args to beat Scala in popular microbenchmarks.) -- 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: fns taking primitives support only 4 or fewer args
On Fri, Jan 14, 2011 at 3:03 PM, Armando Blancas wrote: > > Interfaces have to defined for every combination of primitive arguments - > so > > you get interface explosion, thus only 4. Not ideal, but that's how it is > > for now. > > Why the explosion, since the parameter hints indicate a specific > signature? > Yes. > > > > Looking at that signature (6 arguments?), that should probably be > refactored > > anyway - sounds like a good use case for deftype. > > I'll hazard a guess: it should be refactored down to 4 for proper > design! > > (I suspect it took just 4 args to beat Scala in popular > microbenchmarks.) 2, one for the graphics instance, one for the data structure to hold the other 5 arguments. 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
What's the best way to hide transaction error output from contrib.sql
By design contrib.sql, when executing a batch of commands, uses transaction and if an exception is raised, it is printed to the error output stream. This is very practical but when you are using such code in a test that is meant to throw an exception it adds a lot of noise to the tests output. I was thinking about solving this by redirecting the error output stream, but then it might hide some errors I'd like to know about. Does anyone have a better solution to this (minor) issue? -- 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: fns taking primitives support only 4 or fewer args
On Fri, Jan 14, 2011 at 12:43 PM, David Nolen wrote: > On Fri, Jan 14, 2011 at 12:07 PM, Sam Aaron wrote: >> >> I was wondering what purpose the '4 or fewer args' restriction serves and >> therefore how you might retain the performance of this implementation with >> 1.3.0-alpha4 and beyond (assuming the restriction is here to stay). Would >> you have to break out into a number of smaller fns calculating the new x, y >> length and angle vals? > > Interfaces have to defined for every combination of primitive arguments - so > you get interface explosion, thus only 4. The interfaces are needed only if the function is passed around as an object or dynamically rebound; if it's just called at a few fixed sites, those calls can be directly to a known class. Even then, couldn't the compiler generate the needed interfaces for a specific Clojure project on the fly along with the appropriate calls? Are they even needed at all? Can a passed-around function be invoked with unboxed primitive arguments? Later in the thread the OP is advised to wrap the primitive args in a deftype and pass an instance of that. Manual boxing, in essence. Won't that negate any performance improvement from using primitive args? -- 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: Enhanced Primitive Support Syntax
Debatable it is, endlessly. ;) So Clojure committers made a choice. Hopefully, they have made a choice that has: * a small positive effect (better performance with less effort) on a majority of users * a small negative effect (worse performance, extra effort) on a minority -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: Clojure and Android update status
Clojure 1.2.0 works "out of the box" on Android, but startup time is still a problem. Some members of Clojure/core have experimented with ways to make this better, mostly by selectively removing stuff that isn't needed at runtime. Follow http://dev.clojure.org/display/design/Android+Support for news. The last update was by Aaron Bedra, a Clojure/core member, in December 2010. I wouldn't say it's a high priority right now, but neither have people lost interest. I personally would not recommend writing an Android app in Clojure if you intend to release it right away. But if you're interested experimenting with Clojure on Android and making it better, then go for it. -Stuart Sierra 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
Re: fns taking primitives support only 4 or fewer args
On Jan 14, 2:14 pm, Ken Wesson wrote: > On Fri, Jan 14, 2011 at 12:43 PM, David Nolen wrote: > > On Fri, Jan 14, 2011 at 12:07 PM, Sam Aaron wrote: > > >> I was wondering what purpose the '4 or fewer args' restriction serves and > >> therefore how you might retain the performance of this implementation with > >> 1.3.0-alpha4 and beyond (assuming the restriction is here to stay). Would > >> you have to break out into a number of smaller fns calculating the new x, y > >> length and angle vals? > > > Interfaces have to defined for every combination of primitive arguments - so > > you get interface explosion, thus only 4. > > The interfaces are needed only if the function is passed around as an > object or dynamically rebound; if it's just called at a few fixed > sites, those calls can be directly to a known class. > > Even then, couldn't the compiler generate the needed interfaces for a > specific Clojure project on the fly along with the appropriate calls? > > Are they even needed at all? Can a passed-around function be invoked > with unboxed primitive arguments? > > Later in the thread the OP is advised to wrap the primitive args in a > deftype and pass an instance of that. Manual boxing, in essence. Won't > that negate any performance improvement from using primitive args? I don't think that's the case. The deftype can be type-hinted to have all of its fields be primitives, and then it only costs one object allocation and deref instead of the five you'd have to do to box each argument separately. -- 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: fns taking primitives support only 4 or fewer args
On Fri, Jan 14, 2011 at 7:05 PM, Alan wrote: > I don't think that's the case. The deftype can be type-hinted to have > all of its fields be primitives, and then it only costs one object > allocation and deref instead of the five you'd have to do to box each > argument separately. That's still more than the ideal number of zero. -- 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: Enhanced Primitive Support Syntax
They used to give you compile switches for that kind of stuff, not hope and wholesome wishes. Seems like every performance improvements makes the language more complex, uglier or both. On Jan 14, 2:40 pm, Stuart Sierra wrote: > Debatable it is, endlessly. ;) So Clojure committers made a choice. > Hopefully, they have made a choice that has: > > * a small positive effect (better performance with less effort) on a > majority of users > > * a small negative effect (worse performance, extra effort) on a minority > > -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
