Re: namespace what?
Hello, Jay, Your email is not precise enough. What did you place in which files, how were the files named, how were they stored relatively to some root folder, and how did you start a REPL ? 2011/12/13 jayvandal s...@ida.net: I think I understand namespace and then I don't! I try to run this example (ns examples.core (use [clarity.component :as c])) (make :button The Button) I have programs stored in c:\projects\klarity.clj I have clojure stored in c:\clojure-1.2.1\clojure-1.21. I am running c:\cljr\clj-installer-jar I tried running (ns clojure-1.2.1.clojure-1.2.1.src.clojure.core (use [clarity.component :as c])) (make :button The Button) What is namespace suposed to point to or access??? -- 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: multiple return values
Thanks.
On Dec 14, 8:30 pm, Alan Malloy a...@malloys.org wrote:
Correct, just like closures and reifies.
On Dec 14, 7:33 am, Tom Faulhaber tomfaulha...@gmail.com wrote:
Razvan,
I believe that proxy actually only creates a new class per call site,
not per instance. However, I can't completely swear to this.
Anyone with more detailed knowledge than I have want to comment?
Assuming I'm right,, you should be fine to have lots of instances.
HTH,
Tom
On Dec 13, 10:47 am, Razvan Rotaru razvan.rot...@gmail.com wrote:
Thanks Tom. Using proxy like this could work. But i'm worried about
one thing.What happens if I have many instances? With proxy there's a
new class with each instance. Could I run out of permgen space?
On Dec 13, 9:38 am, Tom Faulhaber tomfaulha...@gmail.com wrote:
Razvan,
I think that you can implement your idea of extending the class with
proxy in the following way (originally suggested to me by Rich Hickey
Chris Houser for use with the pretty printer):
(let [extra-fields (ref {:field1 extra-value1, :field2 extra-value2}]
(proxy [Writer IDeref]
(deref [] extra-fields)
(write [x] ...)
other funcs))
You don't need to make the extra-values item a ref if you will set the
values immutably at create time.
You can see the full example of this
athttps://github.com/clojure/clojure/blob/1f11ca3ef9cd0585abfbe4a9e7609...
The rest of that module is an abomination that was written when I was
still under the influence of CLOS O-O.
Hope that helps,
Tom
On Dec 12, 5:10 pm, Stephen Compall stephen.comp...@gmail.com wrote:
On Mon, 2011-12-12 at 10:54 -0800, Razvan Rotaru wrote:
- function returns a value which is a java instance (not possible to
change here, or at least not from what I see - it needs to be a java
instance)
- i need to be able to call some function which gets some values
that
are not part of the java class
You should approach such a need with great trepidation:
[org.jboss.netty/netty 3.2.7.Final]
(import
'org.jboss.netty.util.internal.ConcurrentIdentityWeakKeyHashMap)
(def ^:private asides (ConcurrentIdentityWeakKeyHashMap.))
(defn function-with-two-return-values [...]
(let [retval ...]
(.put asides retval extra-data)
retval))
(let [x (function-with-two-return-values ...)]
(prn x)
(prn (.get asides x)))
--
Stephen Compall
^aCollection allSatisfy: [:each|aCondition]: less is better
--
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
Expanding expression with macro
Hi! I have something like this: (defmacro testme[ ops ] `(do ~@(for[ op ops ] `(println ~op (macroexpand '(testme 1 2 3)) (testme 1 2 3) How can I change the macro so do wouldn't be required? When I do doseq instead of for the resulting value is nill. (defmacro testme[ ops ] (doseq[ op ops ] `(println ~op))) (macroexpand '(testme 1 2 3)) (testme 1 2 3) What is wrong with that? The desired code should be just (println 1) (println 2) (println 3) Now I have (do (println 1) (println 2) (println 3) ) -- 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: Expanding expression with macro
Hi, macros can only return one value. So multiple forms have to be wrapped into a do. The do never hurts. Why do you want to get rid of it? 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: want to make a 'debug' function, how to get current source and line number?
This should get you started: (defmacro debug [x] (println x) (println (pr-str form)) (println *file*) (println (meta form))) On Thu, Dec 15, 2011 at 12:48 AM, jaime xiejianm...@gmail.com wrote: Hello there, I want to write a function named debug which will print out date- time msg + current source-line + etc. info, but I don't know how to get the current source and line number of the running point (just like what REPL does when encounter any exceptions) ... Got any ideas? 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: namespace what?
You can just say: (ns examples.core (:use clarity.component)) This will intern all the symbols in the clarity.component namespace into examples.core, so you can use them as if they were defined in examples.core in the first place: (make :button the button) This has the disadvantage of potential clashes, if a make function existed in examples.core, it would be overwritten. You can also say: (ns examples.core (:require clarity.component)) This makes the clarity.component namespace symbols available to you, but you still have to fully qualify them: (clarity.component/ make :button the button) This is a bit long-winded, so you can alias the namespace to something shorter: (ns examples.core (:require [clarity.component :as c])) In which case your code becomes: (c/make :button the button) So you manage to be concise, but also you keep your namespaces tidily separated :-) Stathis On Dec 13, 9:50 pm, jayvandal s...@ida.net wrote: I think I understand namespace and then I don't! I try to run this example (ns examples.core (use [clarity.component :as c])) (make :button The Button) I have programs stored in c:\projects\klarity.clj I have clojure stored in c:\clojure-1.2.1\clojure-1.21. I am running c:\cljr\clj-installer-jar I tried running (ns clojure-1.2.1.clojure-1.2.1.src.clojure.core (use [clarity.component :as c])) (make :button The Button) What is namespace suposed to point to or access??? -- 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: namespace what?
Tassilo Horn tass...@member.fsf.org writes: I think I understand namespace and then I don't! I try to run this example (ns examples.core (use [clarity.component :as c])) The syntax of ns is (ns examples.core (:use [clarity.component :as c])) Notice the colon preceeding the use. Oh, and of course Stathis is correct. `use' has no :as clause, so you probably want to `require'. (ns examples.core (:require [clarity.component :as c])) 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: letrec
Is 'declare' possibly the missing component here? On Dec 14, 3:37 pm, Razvan Rotaru razvan.rot...@gmail.com wrote: Yes. Assuming I have following macros: (button :id b1 :listener #(...)) = (let [b1 (new JButton)] ...) (panel [:id p1] (button :id b1 ...) (button :id b2 ...)) = (let [p1 (new JPanel) b1 (button :id b1 ...) b2 (button :id b2 ...)] ...) How to make the listener in b1 refer to b2? Razvan On Dec 14, 11:09 pm, David Nolen dnolen.li...@gmail.com wrote: Do you have a minimal example of what you are trying to do? On Wed, Dec 14, 2011 at 3:53 PM, Razvan Rotaru razvan.rot...@gmail.comwrote: letfn defines functions. I'm just defining some values. The values contain anonymous functions which need to refer to other values.I know there are workarounds for this, but this means I must change the interface. Razvan On Dec 14, 9:56 pm, David Nolen dnolen.li...@gmail.com wrote: On Wed, Dec 14, 2011 at 2:53 PM, Razvan Rotaru razvan.rot...@gmail.com wrote: I don't quite understand why people are saying this. Anyway, It's not enough for me. What can't you solve your problem with what was suggested? 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 -- 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: namespace what?
you are mixing up the format for ns. If you want to use an alias for your library, use require, like this: (ns examples.core (:require [clarity.component :as c])) ;; you can call the function/macro make, by using the alias. (c/make :button The Button) but if you don't want to use an alias and just introduce the vars from the library to your namespace, the use use: (ns examples.core (:use clarity.component)) (make :button The Button) Notice that while using the form ns the internal calls to library like use,require,import,... are actually keywords and not actual calls to the forms use,require,import which you can use outside of the ns form. I don't know if I explained myself well. It's been a while since I dive into clojure, but I am coming back again. I would recommend clojuredocs [http://clojuredocs.org/clojure_core/clojure.core/ns] On Dec 13, 3:50 pm, jayvandal s...@ida.net wrote: I think I understand namespace and then I don't! I try to run this example (ns examples.core (use [clarity.component :as c])) (make :button The Button) I have programs stored in c:\projects\klarity.clj I have clojure stored in c:\clojure-1.2.1\clojure-1.21. I am running c:\cljr\clj-installer-jar I tried running (ns clojure-1.2.1.clojure-1.2.1.src.clojure.core (use [clarity.component :as c])) (make :button The Button) What is namespace suposed to point to or access??? -- 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: letrec
'declare' wouldn't be good because of the scope of vars. There's no sense using global (albeit namespaced) variables for what probably only need to be local identifiers. -- 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: letrec
Hi, to implement letrec in a language with eager evaluation strategy some kind of mutability is probably needed. Consider for example a self- referential definition such as (let [fibo (lazy-cat [1 1] (map + fibo (rest fibo)))] (take 10 fibo)) This will not work since fibo is not in scope when the binding is established. The standard solution would probably be something like this (let [fibo (promise)] (deliver fibo (lazy-cat [1 1] (map + @fibo (rest @fibo (take 10 @fibo)) Not as nice as the original version due to explicit dereferencing, but workable. As an alternative one could use a macro to expand to this and use a code walker (or symbol-macros) to automatically include the @ calls. The following is untested, but should be close: (defmacro letrec [binding body] (let [[var expr] binding g-var (gensym)] `(let [~g-var (promise)] (symbol-macrolet [~var @~g-var] (deliver ~g-var ~expr) ~@body and voila (letrec [fibo (lazy-cat [1 1] (map + fibo (rest fibo)))] (take 10 fibo)) produces (1 1 2 3 5 8 13 21 34 55). Best, Nils -- 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: want to make a 'debug' function, how to get current source and line number?
Great! that's exactly what I want. Thank you! This is the first time I meet form, is there any document about this 'form' or relevant things? On 12月15日, 下午9时19分, Jay Fields j...@jayfields.com wrote: This should get you started: (defmacro debug [x] (println x) (println (pr-str form)) (println *file*) (println (meta form))) On Thu, Dec 15, 2011 at 12:48 AM, jaime xiejianm...@gmail.com wrote: Hello there, I want to write a function named debug which will print out date- time msg + current source-line + etc. info, but I don't know how to get the current source and line number of the running point (just like what REPL does when encounter any exceptions) ... Got any ideas? 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: letrec
Hi, you'll probably have to rewrite your panel macro, so that it recognizes the button (and label, etc) macros ((= #'button (resolve env sym)) in 1.3) and extracts the ids from the subform. Then you construct a global let which contains all the individual id namings. Then you group all '...' parts (from your standalone button example) in the body of the let. 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: want to make a 'debug' function, how to get current source and line number?
You'll probably want to google around a bit. I wrote a blog entry at one point: http://blog.jayfields.com/2011/02/clojure-and.html - but it's not meant to cover everything in depth. 2011/12/15 jaime xiejianm...@gmail.com: Great! that's exactly what I want. Thank you! This is the first time I meet form, is there any document about this 'form' or relevant things? On 12月15日, 下午9时19分, Jay Fields j...@jayfields.com wrote: This should get you started: (defmacro debug [x] (println x) (println (pr-str form)) (println *file*) (println (meta form))) On Thu, Dec 15, 2011 at 12:48 AM, jaime xiejianm...@gmail.com wrote: Hello there, I want to write a function named debug which will print out date- time msg + current source-line + etc. info, but I don't know how to get the current source and line number of the running point (just like what REPL does when encounter any exceptions) ... Got any ideas? 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 -- 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: want to make a 'debug' function, how to get current source and line number?
in java i would throw an exception and parse its stack trace. don't know how to do that in clojure, but probably similar Am 15.12.2011 06:48, schrieb jaime: Hello there, I want to write a function named debug which will print out date- time msg + current source-line + etc. info, but I don't know how to get the current source and line number of the running point (just like what REPL does when encounter any exceptions) ... Got any ideas? 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
my first attempt at a macro returns form wrapped in clojure.core/fn
TL;DR I have an extra clojure.core/fn wrapped around the form I want
returned from my macro. This is my first macro and I'm not sure what's
wrong, even though the macro works.
I'm trying my first attempt at a macro by trying to save myself from
having to type sql/with-connection db for every time I want to
invoke a database command. I figure I can type dc (short for
database connection) instead.
I'm doing something wrong but I've tried a few iterations of ', `, ~,
and ~@ the closest I got was this one:
(def db {:classname org.postgresql.Driver
:subprotocol postgresql
:subname (str //localhost:5432/shouter)
:user username
:password 1234})
(defmacro dc
[sql-cmd]
(list 'sql/with-connection 'db
sql-cmd))
This macro works in that it actually invokes the form I want, but when
I run macroexpand on it I have an extra clojure.core/fn wrapped around
my command, and when I compare that output to the when macro (which
does not have the clojure.core/fn wrapper that I can see), I think
I've got it wrong.
user (macroexpand '(when (pos? a) (println positive) (/ b a)))
(if (pos? a) (do (println positive) (/ b a)))
user (macroexpand '(dc (sql/create-table :testing [:data :text])))
(clojure.java.jdbc.internal/with-connection* db (clojure.core/fn []
(sql/create-table :testing [:data :text])))
I've also tried it with args so I don't have to put my
sql/create-table ... form in parens, but it seems to work even worse
(I've still got the extra clojure.core/fn and now parens are around
the args).
(defmacro dc1
[sql-cmd args]
(list 'sql/with-connection 'db
sql-cmd args))
user (macroexpand '(dc1 sql/create-table :testing [:data :text]))
(clojure.java.jdbc.internal/with-connection* db (clojure.core/fn []
sql/create-table (:testing [:data :text])))
I also tried this variation, which works but instead of returning the
status of the database command (0) as dc did, it returns the last arg
passed in, [:data :text].
(defmacro dc2
[sql-cmd args]
`(sql/with-connection db
~sql-cmd ~@args))
user (macroexpand '(dc2 sql/create-table :testing [:data :text]))
(clojure.java.jdbc.internal/with-connection* user/db (clojure.core/fn
[] sql/create-table :testing [:data :text]))
Any ideas on where I'm specifically going wrong, or where to read
further on macros (preferably simple examples)?
Thanks,
Peter
--
The king’s heart is like a stream of water directed by the Lord; He
guides it wherever He pleases.
--
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 videos no longer downloadable
On Wed, Dec 14, 2011 at 8:21 PM, Baishampayan Ghose b.gh...@gmail.com wrote: Every video has an RSS feed which can be mechanically constructed given the URL. So for http://blip.tv/clojure/rich-hickey-unveils-clojurescript-5399498, the RSS feed is at http://blip.tv/rss/flash/5399498 IIRC, the RSS feed has the URL to the actual video. That's quite handy; thanks. Even so I'm pretty annoyed that they deleted my account and locked me out. Not that it necessitates finding a friendlier video host, but I wanted to just raise awareness of the issue. -Phil -- 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: my first attempt at a macro returns form wrapped in clojure.core/fn
On Thu, Dec 15, 2011 at 1:14 PM, Peter Buckley buckmeist...@gmail.com wrote: TL;DR I have an extra clojure.core/fn wrapped around the form I want returned from my macro. This is my first macro and I'm not sure what's wrong, even though the macro works. ... (defmacro dc [sql-cmd] (list 'sql/with-connection 'db sql-cmd)) This macro works in that it actually invokes the form I want, but when I run macroexpand on it I have an extra clojure.core/fn wrapped around my command, and when I compare that output to the when macro (which does not have the clojure.core/fn wrapper that I can see), I think I've got it wrong. user (macroexpand '(when (pos? a) (println positive) (/ b a))) (if (pos? a) (do (println positive) (/ b a))) user (macroexpand '(dc (sql/create-table :testing [:data :text]))) (clojure.java.jdbc.internal/with-connection* db (clojure.core/fn [] (sql/create-table :testing [:data :text]))) Try macroexpand-1. Plain macroexpand expands your macro, but the result is] (sql/with-connection db (sql/create-table :testing [:data :text])) which starts with another macro call, (sql/with-connection ...), and if that happens macroexpand expands that macro as well. And apparently (sql/with-connection foo) expands to (clojure.java.jdbc.internal/with-connection* db (clojure.core/fn [] foo)) hence your confusion. -- 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: Lazy-seq of a binary file
On Wed, Dec 14, 2011 at 11:47 PM, Simone Mosciatti mweb@gmail.com wrote: Ok thank you so much, i got it. Thanks again ;-) You're welcome. -- 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: want to make a 'debug' function, how to get current source and line number?
This will print all the debug information at compile time, which is usually not what you want. I have a little macro I use called ?, which looks like: (defmacro ? [x] `(let [x# ~x] (prn '~x '~'is x#) x#)) You could add file and line information to this fairly simply: (defmacro ? [x] (let [line (:line (meta form)) file *file*] `(let [x# ~x] (println (pr-str '~x) is (pr-str x#) (str ; ( ~file : ~line ))) x#))) And use it like so: user (let [x 10] (+ 5 (? x))) x is 10 ; (NO_SOURCE_FILE:1) 15 On Dec 15, 5:19 am, Jay Fields j...@jayfields.com wrote: This should get you started: (defmacro debug [x] (println x) (println (pr-str form)) (println *file*) (println (meta form))) On Thu, Dec 15, 2011 at 12:48 AM, jaime xiejianm...@gmail.com wrote: Hello there, I want to write a function named debug which will print out date- time msg + current source-line + etc. info, but I don't know how to get the current source and line number of the running point (just like what REPL does when encounter any exceptions) ... Got any ideas? 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: letrec
Hi,
if you always follow the let structure you outlined the following might work.
Untested, though. Note, that things work recursively with this approach.
(def ours? #{#'button #'label ...})
(defmacro panel
[{:keys [id]} components]
(let [[bindings body]
(reduce (fn [[bindings body] component]
(if (and (seq? component)
(ours? (resolve env (first component
(let [[_let local-bindings local-body]
(macroexpand-1 component)]
[(into bindings local-bindings) (into body local-body)])
; Keep stuff we don't know.
[bindings (conj body component)]))
[[id `(JPanel.)] []]
components)]
`(let ~bindings
~@body
...
~id)))
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: my first attempt at a macro returns form wrapped in clojure.core/fn
FWIW, much safer is (defmacro dc [sql-cmd] `(sql/with-connection db ~sql-cmd)) If you use the version with (list) and plain-quoting of the first two items, then the namespace resolution is very fragile: it will only work if the caller has referred to the sql library with the prefix sql/, and if they have the db in scope. The syntax-quote expands those to their fully-qualified names, so that they always refer to the thing you intend, even if (god forbid) the user has an unrelated local variable named db in their lexical scope. On Dec 15, 10:37 am, Cedric Greevey cgree...@gmail.com wrote: On Thu, Dec 15, 2011 at 1:14 PM, Peter Buckley buckmeist...@gmail.com wrote: TL;DR I have an extra clojure.core/fn wrapped around the form I want returned from my macro. This is my first macro and I'm not sure what's wrong, even though the macro works. ... (defmacro dc [sql-cmd] (list 'sql/with-connection 'db sql-cmd)) This macro works in that it actually invokes the form I want, but when I run macroexpand on it I have an extra clojure.core/fn wrapped around my command, and when I compare that output to the when macro (which does not have the clojure.core/fn wrapper that I can see), I think I've got it wrong. user (macroexpand '(when (pos? a) (println positive) (/ b a))) (if (pos? a) (do (println positive) (/ b a))) user (macroexpand '(dc (sql/create-table :testing [:data :text]))) (clojure.java.jdbc.internal/with-connection* db (clojure.core/fn [] (sql/create-table :testing [:data :text]))) Try macroexpand-1. Plain macroexpand expands your macro, but the result is] (sql/with-connection db (sql/create-table :testing [:data :text])) which starts with another macro call, (sql/with-connection ...), and if that happens macroexpand expands that macro as well. And apparently (sql/with-connection foo) expands to (clojure.java.jdbc.internal/with-connection* db (clojure.core/fn [] foo)) hence your confusion. -- 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
How to: convert output stream into an input stream
I have created an output stream, which appears to work fine, however
I get an error when trying to convert the output stream into an input
stream for use in ring:
('use [clojure.java.io :only [input-stream]])
= (with-out-str (ofn var))
it works!
Now when I use ring:
{:body (input-stream (ofn var))}
java.lang.IllegalArgumentException: No implementation of method: :make-
input-stream of protocol: #'clojure.java.io/IOFactory found for class:
nil
Is there something special I need to do to convert output stream into
an input stream ?
Thanks,
Trevor
--
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: want to make a 'debug' function, how to get current source and line number?
On Thu, Dec 15, 2011 at 1:54 PM, Alan Malloy a...@malloys.org wrote: This will print all the debug information at compile time, which is usually not what you want. I have a little macro I use called ?, which looks like: (defmacro ? [x] `(let [x# ~x] (prn '~x '~'is x#) x#)) You could add file and line information to this fairly simply: (defmacro ? [x] (let [line (:line (meta form)) file *file*] `(let [x# ~x] (println (pr-str '~x) is (pr-str x#) (str ; ( ~file : ~line ))) x#))) And use it like so: user (let [x 10] (+ 5 (? x))) x is 10 ; (NO_SOURCE_FILE:1) 15 You might want to change (pr-str x#) to something like (pr-str (if (seq? x#) (let [s (Object.)] (if (= (nth x# 11 s) s) x# (concat (take 10 x#) ['...]))) x#)) which will print sequences longer than ten elements as (1 2 3 4 5 6 7 8 9 10 ...) and prevent infinite seqs from blowing things up. Or more generally you might want to go through pprint which lets you set *print-len* and *print-level* to generally control the printing of very large and/or deeply-nested structures. But that adds a new dependency that needs to be required anywhere you use the macro ... -- 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: my first attempt at a macro returns form wrapped in clojure.core/fn
On Thu, Dec 15, 2011 at 2:16 PM, Alan Malloy a...@malloys.org wrote: FWIW, much safer is (defmacro dc [sql-cmd] `(sql/with-connection db ~sql-cmd)) If you use the version with (list) and plain-quoting of the first two items, then the namespace resolution is very fragile: it will only work if the caller has referred to the sql library with the prefix sql/, and if they have the db in scope. The syntax-quote expands those to their fully-qualified names, so that they always refer to the thing you intend, even if (god forbid) the user has an unrelated local variable named db in their lexical scope. Yes, I know. I assumed the OP was going through an exercise that introduces macros first, and then syntax-quote, rather than both at once (or syntax-quote first). -- 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: Expanding expression with macro
Nothing is wrong with do I just missed the point how the macro works Thanks! On 15 Gru, 13:37, Meikel Brandmeyer m...@kotka.de wrote: Hi, macros can only return one value. So multiple forms have to be wrapped into a do. The do never hurts. Why do you want to get rid of it? 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, is it ready yet?
Hi! Is clojurescript ready for wide water? How far i can only see obscure compilation env and low level ops on html elemnts. Are there any plans to start building second gwt? Swing 2.0? Google started darts as general purpose language with web browser's VM aka javascript. They want even to replace java as language in gwt framework. But you guess I prefer to stick to Clojure that is why i'm asking. My story is. I have written some apps with gwt, some server side with jee. I'm happy with ajax, however i don't like imperative way of building ui. That is why i have defined xml schema - declarative lang for ui - aka s-expressions - to define views, validators and factories. I'm parsing that xml with clojure xml parse method (mentioning it is important because targeting data structure is flexible - it is abstract syntax tree which i can covert forward and back betwwen xml, hashmaps of hashmaps and sexpressions) and I'm able to execute it as clojure code, or simply interpret on client side with gwt. I have two implementations of that xml schema. One as mentioned before is interpreted in gwt to build gui, second is interpreted in jvm to build ui in swing instead, for faster ui and concepts prototyping. The missing part is clojurescript, which could generate ui on client side in web browser so i would drop the interpreter in gwt and gwt itself So the question is - Is anybody already building gwt for clojurescript? Bye! -- 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: Clojurescript, is it ready yet?
On Thu, Dec 15, 2011 at 5:11 PM, Michael Jaaka michael.ja...@googlemail.com wrote: Hi! Is clojurescript ready for wide water? It's getting there. How far i can only see obscure compilation env and low level ops on html elemnts. I find the compilation environment is quite nice, if there's something you find confusing you should discuss it. I don't think that ClojureScript should offer much in the way of manipulating the DOM. That's for libraries. So the question is - Is anybody already building gwt for clojurescript? Bye! Not that I'm aware of, but that does sounds like something people would be interested in. 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: Clojurescript, is it ready yet?
Is clojurescript ready for wide water? It's getting there. +1 How far i can only see obscure compilation env and low level ops on html elemnts. I find the compilation environment is quite nice, if there's something you find confusing you should discuss it. I don't think that ClojureScript should offer much in the way of manipulating the DOM. That's for libraries. So the question is - Is anybody already building gwt for clojurescript? Bye! Not that I'm aware of, but that does sounds like something people would be interested in. Though there is nothing exactly comparable to UIBinder, with the combination of Pinot [1] and Noir [2], the Closure library [3], and client/server templates like Closure [4] or Mustache [5][6], you can get much of the benefit of GWT. [1] https://github.com/ibdknox/pinot [2] https://github.com/ibdknox/noir [3] http://closure-library.googlecode.com/svn/docs/index.html [4] http://code.google.com/closure/templates/ [5] https://github.com/fhd/clostache [6] https://github.com/janl/mustache.js -- 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
Bug with 1.3 primitive function return value hinting.
(defn dist Shortest distance between x,y and x2,y2 in toroidal space of dimensions w,h. Input coordinates should be in range (0,0)-(w,h). For instance, will give 1.414... if x,y = (0,0) and x2,y2 = (w-1,h-1), as these are diagonally adjacent. ([x y x2 y2 w h] (let [x2s [(- x2 w) x2 (+ x2 w)] y2s [(- y2 h) y2 (+ y2 h)] dist-sqrs (for [x2 x2s y2 y2s] (let [dx (- x2 x) dy (- y2 y)] (+ (* dx dx) (* dy dy] (Math/sqrt (double (apply min dist-sqrs)) #'user/dist (defn dist2 Shortest distance between x,y and x2,y2 in toroidal space of dimensions w,h. Input coordinates should be in range (0,0)-(w,h). For instance, will give 1.414... if x,y = (0,0) and x2,y2 = (w-1,h-1), as these are diagonally adjacent. (^double [x y x2 y2 w h] ; Sole difference is the ^double added here. (let [x2s [(- x2 w) x2 (+ x2 w)] y2s [(- y2 h) y2 (+ y2 h)] dist-sqrs (for [x2 x2s y2 y2s] (let [dx (- x2 x) dy (- y2 y)] (+ (* dx dx) (* dy dy] (Math/sqrt (double (apply min dist-sqrs)) #CompilerException java.lang.IllegalArgumentException: fns taking primitives support only 4 or fewer args, But the function isn't *taking* primitives. It's only *returning* a primitive, after taking Objects. So it obviously shouldn't produce this error. -- 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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 5:53 PM, Cedric Greevey cgree...@gmail.com wrote: (defn dist Shortest distance between x,y and x2,y2 in toroidal space of dimensions w,h. Input coordinates should be in range (0,0)-(w,h). For instance, will give 1.414... if x,y = (0,0) and x2,y2 = (w-1,h-1), as these are diagonally adjacent. ([x y x2 y2 w h] (let [x2s [(- x2 w) x2 (+ x2 w)] y2s [(- y2 h) y2 (+ y2 h)] dist-sqrs (for [x2 x2s y2 y2s] (let [dx (- x2 x) dy (- y2 y)] (+ (* dx dx) (* dy dy] (Math/sqrt (double (apply min dist-sqrs)) #'user/dist (defn dist2 Shortest distance between x,y and x2,y2 in toroidal space of dimensions w,h. Input coordinates should be in range (0,0)-(w,h). For instance, will give 1.414... if x,y = (0,0) and x2,y2 = (w-1,h-1), as these are diagonally adjacent. (^double [x y x2 y2 w h] ; Sole difference is the ^double added here. (let [x2s [(- x2 w) x2 (+ x2 w)] y2s [(- y2 h) y2 (+ y2 h)] dist-sqrs (for [x2 x2s y2 y2s] (let [dx (- x2 x) dy (- y2 y)] (+ (* dx dx) (* dy dy] (Math/sqrt (double (apply min dist-sqrs)) #CompilerException java.lang.IllegalArgumentException: fns taking primitives support only 4 or fewer args, But the function isn't *taking* primitives. It's only *returning* a primitive, after taking Objects. So it obviously shouldn't produce this error. Not a bug, but the error should be clearer. 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: Bug with 1.3 primitive function return value hinting.
And a related bug/quirk: I had had (defn- remm Remainder of a modulo b; unlike (rem a b) result is in [0,b) even if a is negative. ([a b] (let [r (rem a b)] (if ( r 0) (+ r b) r and evaluated (defn- remm Remainder of a modulo b; unlike (rem a b) result is in [0,b) even if a is negative. (^long [^long a ^long b] (let [r (rem a b)] (if ( r 0) (+ r b) r in the same namespace. After that, I ran a test from the namespace and got a very weird failure: #ClassCastException java.lang.ClassCastException: thingy.core$remm cannot be cast to clojure.lang.IFn$LLO Reloading the full namespace fixed it. It looks like there's a failure to be as dynamic as people expect, here; if a function is modified in a way that changes the hinting on it, its callers apparently need to be recompiled or they'll crash rather than transparently start using the new version. I'm not sure if this is a bug or an expected limitation, though; unlike the above, where an error message appeared that clearly was not applicable in that situation. -- 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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 5:59 PM, David Nolen dnolen.li...@gmail.com wrote: On Thu, Dec 15, 2011 at 5:53 PM, Cedric Greevey cgree...@gmail.com wrote: #CompilerException java.lang.IllegalArgumentException: fns taking primitives support only 4 or fewer args, But the function isn't *taking* primitives. It's only *returning* a primitive, after taking Objects. So it obviously shouldn't produce this error. Not a bug, Clearly a bug. A limitation on primitive arguments simply cannot be applicable to a function with no primitive arguments. -- 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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 6:01 PM, Cedric Greevey cgree...@gmail.com wrote: On Thu, Dec 15, 2011 at 5:59 PM, David Nolen dnolen.li...@gmail.com wrote: On Thu, Dec 15, 2011 at 5:53 PM, Cedric Greevey cgree...@gmail.com wrote: #CompilerException java.lang.IllegalArgumentException: fns taking primitives support only 4 or fewer args, But the function isn't *taking* primitives. It's only *returning* a primitive, after taking Objects. So it obviously shouldn't produce this error. Not a bug, Clearly a bug. A limitation on primitive arguments simply cannot be applicable to a function with no primitive arguments. primitive args/return are thoroughly intertwined. You cannot separate them in the current implementation. So it's not a bug, it's a limitation (and I one I don't see how to surmount). The error could be changed to reflect 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 Stored Procedure
Hello, I'm interested in this kind of thing too. Do you have any progress? -- 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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 6:05 PM, David Nolen dnolen.li...@gmail.com wrote: On Thu, Dec 15, 2011 at 6:01 PM, Cedric Greevey cgree...@gmail.com wrote: On Thu, Dec 15, 2011 at 5:59 PM, David Nolen dnolen.li...@gmail.com wrote: On Thu, Dec 15, 2011 at 5:53 PM, Cedric Greevey cgree...@gmail.com wrote: #CompilerException java.lang.IllegalArgumentException: fns taking primitives support only 4 or fewer args, But the function isn't *taking* primitives. It's only *returning* a primitive, after taking Objects. So it obviously shouldn't produce this error. Not a bug, Clearly a bug. A limitation on primitive arguments simply cannot be applicable to a function with no primitive arguments. primitive args/return are thoroughly intertwined. You cannot separate them in the current implementation. And yet, it accepts this function definition, which has one without the other: (defn foo ^long [x y] (+ x y)) So it's not a bug, it's a limitation (and I one I don't see how to surmount). I don't see any logical reason why a function taking only non-primitive arguments cannot have a primitive return value. Certainly a Java method can take only reference type arguments and have a primitive return value, so we're not seeing a JVM limitation here. And all of that is leaving aside the fact that the error message claimed that the function *did* have at least one primitive argument, even though it did not. In any event, the compiler barfed on input with a message that clearly implies that the compiler should have accepted that same input. I can't see any way of interpreting that as not a bug. -- 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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 6:19 PM, Cedric Greevey cgree...@gmail.com wrote: I don't see any logical reason why a function taking only non-primitive arguments cannot have a primitive return value. You need a JVM method signature for every n number of object arguments + the supported primitive return type. So more interfaces would have to be defined for the object args only case. Personally I don't see the advantage given the use case here is high performance helper fns. 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: want to make a 'debug' function, how to get current source and line number?
On Dec 15, 1:09 pm, Cedric Greevey cgree...@gmail.com wrote: On Thu, Dec 15, 2011 at 1:54 PM, Alan Malloy a...@malloys.org wrote: This will print all the debug information at compile time, which is usually not what you want. I have a little macro I use called ?, which looks like: (defmacro ? [x] `(let [x# ~x] (prn '~x '~'is x#) x#)) You could add file and line information to this fairly simply: (defmacro ? [x] (let [line (:line (meta form)) file *file*] `(let [x# ~x] (println (pr-str '~x) is (pr-str x#) (str ; ( ~file : ~line ))) x#))) And use it like so: user (let [x 10] (+ 5 (? x))) x is 10 ; (NO_SOURCE_FILE:1) 15 You might want to change (pr-str x#) to something like (pr-str (if (seq? x#) (let [s (Object.)] (if (= (nth x# 11 s) s) x# (concat (take 10 x#) ['...]))) x#)) which will print sequences longer than ten elements as (1 2 3 4 5 6 7 8 9 10 ...) and prevent infinite seqs from blowing things up. Or more generally you might want to go through pprint which lets you set *print-len* and *print-level* to generally control the printing of very large and/or deeply-nested structures. But that adds a new dependency that needs to be required anywhere you use the macro ... Good point. I'm surprised this has never bitten me yet. On the other hand, the fact that it's never bitten me in the like 12 months of heavy use since I wrote it does lessen my concern that this would be an issue. However, there's no reason to go through pprint - the bindable print-foo vars are respected by pr-str. -- 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: Bug with 1.3 primitive function return value hinting.
Hi Cedric, Your statement A limitation on primitive arguments simply cannot be applicable to a function with no primitive arguments does not stand given all the previous discussions about numeric optimizations and comparing optimizations found in other compiler. Look at any C compiler optimizations switches, you will find many compromises and limitations, in fact you might be bald after using them :) Agree, the message should be clearer and need some improvement There's also a limit on the # of arguments even without the numeric optimization stuff. It's not a bug, it's a limitation. Software vendors are calling these things features but clearly this group cannot sustain the big marketing dept. needed to create the neçessary distorsion field to alter perceptions :))) Luc P On Thu, Dec 15, 2011 at 6:05 PM, David Nolen dnolen.li...@gmail.com wrote: On Thu, Dec 15, 2011 at 6:01 PM, Cedric Greevey cgree...@gmail.com wrote: On Thu, Dec 15, 2011 at 5:59 PM, David Nolen dnolen.li...@gmail.com wrote: On Thu, Dec 15, 2011 at 5:53 PM, Cedric Greevey cgree...@gmail.com wrote: #CompilerException java.lang.IllegalArgumentException: fns taking primitives support only 4 or fewer args, But the function isn't *taking* primitives. It's only *returning* a primitive, after taking Objects. So it obviously shouldn't produce this error. Not a bug, Clearly a bug. A limitation on primitive arguments simply cannot be applicable to a function with no primitive arguments. primitive args/return are thoroughly intertwined. You cannot separate them in the current implementation. And yet, it accepts this function definition, which has one without the other: (defn foo ^long [x y] (+ x y)) So it's not a bug, it's a limitation (and I one I don't see how to surmount). I don't see any logical reason why a function taking only non-primitive arguments cannot have a primitive return value. Certainly a Java method can take only reference type arguments and have a primitive return value, so we're not seeing a JVM limitation here. And all of that is leaving aside the fact that the error message claimed that the function *did* have at least one primitive argument, even though it did not. In any event, the compiler barfed on input with a message that clearly implies that the compiler should have accepted that same input. I can't see any way of interpreting that as not a bug. -- 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 -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail! -- 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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 6:33 PM, David Nolen dnolen.li...@gmail.com wrote: On Thu, Dec 15, 2011 at 6:19 PM, Cedric Greevey cgree...@gmail.com wrote: I don't see any logical reason why a function taking only non-primitive arguments cannot have a primitive return value. You need a JVM method signature for every n number of object arguments + the supported primitive return type. So more interfaces would have to be defined for the object args only case. Personally I don't see the advantage given the use case here is high performance helper fns. For helper fns, it's unlikely to be necessary to use the function widely in generic contexts, i.e. in a first-class manner, right? In that case, can't the compiler eschew using an interface and just call the function directly? For that matter, can't it just generate both a 1.2 version of the function and a 1.3 version, with the IFn interface methods calling the 1.2 version, and direct use at a call site calling the 1.3 version directly without going through an interface? That makes functions with primitive args and/or returns nondynamic at such call sites, but that already seems to be at least partially the case, necessitating recompiling the calling functions at least when the type signature changes. The indirect call case tends to mean HOF use, which tends to mean it's being run over a collection's members, which tends to mean unboxing gets done anyway, so the 1.2 version being used in such contexts wouldn't be a disadvantage. (And a closure like #(foo 1 2 %) would compile into a call to the 1.3 version, if existent, of foo; only the % argument then needs unboxing, while the 1 and 2 can be compiled and passed in as primitives). The one case I see as being less efficient might be (let [f (if some-condition f1 f2)] (f some-primitive-arg)) where both f1 and f2 take a primitive arg. Right now that might be efficient, whereas with the above suggestion it would call the 1.2 version and some-primitive-arg would get boxed and unboxed. But I think that case is comparatively rare, relative to invocation of a statically-determined function that uses and/or returns primitives. -- 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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 6:51 PM, Softaddicts lprefonta...@softaddicts.ca wrote: Hi Cedric, Your statement A limitation on primitive arguments simply cannot be applicable to a function with no primitive arguments does not stand It is true by axiom. Either the limitation is not actually a limitation on primitive arguments but on something broader, or else it is not applicable. Either the code should have compiled, or the error is different from what the message stated. There's no getting around that. There's also a limit on the # of arguments even without the numeric optimization stuff. It's not a bug, it's a limitation. As I recall, there's no such limit with the use of a rest arg -- even an infinite seq can be used, as in (defn foo [ xs] (take 10 xs)) (apply foo (iterate inc 1)) though it actually passes a seq in using a single argument in the underlying Java method (and indeed in the function definition xs is a single seq argument). If it doesn't already, it can accomodate arbitrarily-long lists of formal parameters by quietly boxing the 20th onwards into a seq and destructuring it on the other side, i.e. (defn foo [a1 a2 ... a20 a21 a22 ...] (do-stuff a22)) (foo 1 2 ... 20 21 22 ...) can be made to behave as (defn foo [a1 a2 ... a20andbeyond] (let [[a20 a21 a22 ...] a20andbeyond] (do-stuff a22))) (foo 1 2 ... (list 20 21 22 ...)). If this isn't already supported, the fn macro itself can be modified to detect that case and expand in exactly such a manner when that occurs. As for the wackiness with primitive returns (even without primitive arguments) my previous post details something that could probably fix most or all such issues and gotchas, at the expense of making a single, relatively uncommon use-case, namely (let [f (if foo primitive-fn1 primitive-fn2)] (f primitive-arg)) less efficient and requiring recompilation of static-callers of primitive-returning functions when the latters' signatures (return type and number and types of arguments) are changed (changing the types already seems to require this). -- 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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 7:14 PM, Cedric Greevey cgree...@gmail.com wrote: For helper fns, it's unlikely to be necessary to use the function widely in generic contexts, i.e. in a first-class manner, right? fns with prim args/return support already do this. When not used higher order if the compiler can infer the right interface to use at a call site it will use it. Otherwise it calls the generic version. To be clear there is no unboxing. If something becomes boxed, it must be manually unboxed by you. As far needing to recompile callers of changed prim fns I think this is a case of c'est la vie until someone volunteers to fix it (if that's possible). 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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 7:29 PM, David Nolen dnolen.li...@gmail.com wrote: On Thu, Dec 15, 2011 at 7:14 PM, Cedric Greevey cgree...@gmail.com wrote: For helper fns, it's unlikely to be necessary to use the function widely in generic contexts, i.e. in a first-class manner, right? fns with prim args/return support already do this. When not used higher order if the compiler can infer the right interface to use at a call site it will use it. Otherwise it calls the generic version. In that case, I don't see the need for the interface in the non-higher-order case. It could just create a Java method of some class that implements the primitive-ized version of the fn, and compile a direct invocation to that method of that class at the call site without using any interface. And that gets rid of any limitation that is not a JVM-based limitation of a Java method. I'm pretty sure it would allow a lot more than 4 arguments, in particular. To be clear there is no unboxing. If something becomes boxed, it must be manually unboxed by you. If it's passed to a function or, via interop, Java method that expects a primitive, it seems to be unboxed: (Math/sqrt 2.0) 1.4142135623730951 And just to be sure the argument to Math/sqrt is a Double and not a double: (Math/sqrt (Double. 2.0)) 1.4142135623730951 No no matching method error and no Math.sqrt(Double) overload listed in the javadocs. (Though I notice that (Double. 2) hurls with a no matching ctor message -- I think that worked under 1.2? So it's not doing conversions, even widening conversions, of numeric types to resolve interop calls; hmm.) As far needing to recompile callers of changed prim fns I think this is a case of c'est la vie until someone volunteers to fix it (if that's possible). Oh, I think that probably can't be avoided, but in that case there's little point in not ditching the interface and calling the fn class directly at nondynamic call sites. Again, cases where the function is variable but the arguments don't come pre-boxed by being pulled out of a coll are passing rare. We should be optimizing for the common case. -- 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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 7:43 PM, Cedric Greevey cgree...@gmail.com wrote: In that case, I don't see the need for the interface in the non-higher-order case. It could just create a Java method of some class that implements the primitive-ized version of the fn, and This is what already happens, every fn is a class - prim fns *implement* the prim interfaces. If it's passed to a function or, via interop, Java method that expects a primitive, it seems to be unboxed: (Math/sqrt 2.0) 1.4142135623730951 It was never boxed in the first place. -- 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: Midje 1.3.0
Joining the congrats, one of the must have tools for any Clojure project Ronen On Dec 14, 8:01 am, Denis Labaye denis.lab...@gmail.com wrote: Midje is getting better and better. Congrats! On Mon, Dec 12, 2011 at 5:41 PM, Brian Marick mar...@exampler.com wrote: Midje 1.3's most important feature is compatibility with Clojure 1.3. https://github.com/marick/Midje Midje is a test framework for Clojure that supports top-down as well as bottom-up testing, encourages readable tests, provides a smooth migration path from clojure.test, supports a balance between abstraction and concreteness, and tries to be gracious in its treatment of its user. Other major changes in 1.3 are: * Colorized output https://github.com/marick/Midje/wiki/Colorizing * Monitoring and rerunning changed files (autotest/lazytest) (under Leiningen:https://github.com/marick/Midje/wiki/Lein-midje) * Partial prerequisites (makes it easier to add new behavior to existing code) https://github.com/marick/Midje/wiki/Partial-prerequisites * Data prerequisites (avoiding overcommitment to data representation) https://github.com/marick/Midje/wiki/Data-prerequisites More here:https://github.com/marick/Midje/blob/master/HISTORY.md Thanks especially to Alex Baranosky, who did a lot of work on this release. Enjoy. - Brian Marick, Artisanal Labrador Now working athttp://path11.com Contract programming in Ruby and Clojure Occasional consulting on Agile -- 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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 7:48 PM, David Nolen dnolen.li...@gmail.com wrote: On Thu, Dec 15, 2011 at 7:43 PM, Cedric Greevey cgree...@gmail.com wrote: In that case, I don't see the need for the interface in the non-higher-order case. It could just create a Java method of some class that implements the primitive-ized version of the fn, and This is what already happens, every fn is a class - prim fns *implement* the prim interfaces. I know that every fn is a class; I am questioning the very need for prim interfaces. If it's passed to a function or, via interop, Java method that expects a primitive, it seems to be unboxed: (Math/sqrt 2.0) 1.4142135623730951 It was never boxed in the first place. It was in the part you snipped, which explicitly constructed a Double object as the argument. -- 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: Bug with 1.3 primitive function return value hinting.
From a JVM perspective, f( arglist) is a one arg function. Try defining a fn with more than 20 args and you will get the can't specify more than 20 arguments error. This is the maximum supported by the Clojure runtime for non-optimized fns. One can argue about the argument size limit of optimized fn calls. Maybe 4 is too low. These limitations has David pointed out are indirectly inherited from the JVM architecture. What maximum is reasonable ? A vast discussion subject... There are multiple ways to work around this limit. Destructuring, passing a map, ... All these options are much more easier and accessible than implementing/modifying the numeric optimizations. Luc P On Thu, Dec 15, 2011 at 6:51 PM, Softaddicts lprefonta...@softaddicts.ca wrote: Hi Cedric, Your statement A limitation on primitive arguments simply cannot be applicable to a function with no primitive arguments does not stand It is true by axiom. Either the limitation is not actually a limitation on primitive arguments but on something broader, or else it is not applicable. Either the code should have compiled, or the error is different from what the message stated. There's no getting around that. There's also a limit on the # of arguments even without the numeric optimization stuff. It's not a bug, it's a limitation. As I recall, there's no such limit with the use of a rest arg -- even an infinite seq can be used, as in (defn foo [ xs] (take 10 xs))ly (apply foo (iterate inc 1)) though it actually passes a seq in using a single argument in the underlying Java method (and indeed in the function definition xs is a single seq argument). If it doesn't already, it can accomodate arbitrarily-long lists of formal parameters by quietly boxing the 20th onwards into a seq and destructuring it on the other side, i.e. (defn foo [a1 a2 ... a20 a21 a22 ...] (do-stuff a22)) (foo 1 2 ... 20 21 22 ...) can be made to behave as (defn foo [a1 a2 ... a20andbeyond] (let [[a20 a21 a22 ...] a20andbeyond] (do-stuff a22))) (foo 1 2 ... (list 20 21 22 ...)). If this isn't already supported, the fn macro itself can be modified to detect that case and expand in exactly such a manner when that occurs. As for the wackiness with primitive returns (even without primitive arguments) my previous post details something that could probably fix most or all such issues and gotchas, at the expense of making a single, relatively uncommon use-case, namely (let [f (if foo primitive-fn1 primitive-fn2)] (f primitive-arg)) less efficient and requiring recompilation of static-callers of primitive-returning functions when the latters' signatures (return type and number and types of arguments) are changed (changing the types already seems to require this). -- 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 -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail! -- 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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 8:05 PM, Softaddicts
lprefonta...@softaddicts.ca wrote:
From a JVM perspective, f( arglist) is a one arg function.
Try defining a fn with more than 20 args and you will get the
can't specify more than 20 arguments error.
This is the maximum supported by the Clojure runtime for non-optimized fns.
Well, that's just silly, since a simple change to the fn macro would
make that go away without any hassle, as I already outlined. (The
error would remain for direct users of fn*, of course.)
One can argue about the argument size limit of optimized fn calls. Maybe 4 is
too low.
These limitations has David pointed out are indirectly inherited from the JVM
architecture.
As I understand it, the problem is a combinatorial explosion of
interfaces with various signatures. Which is only a problem because,
for some reason, static calls to optimized fns are not made directly
to the fn's class. Why not just make an optimized fn class look like
public class MangledName implements IFn {
public Object invoke () { // unoptimized zero-arg version or arity
throw goes here }
public Object invoke (Object x) { // unoptimized one-arg version ... }
...
public static long optimized (int bar, double quux, Object
fiddlefaddle, long x, long y, long z) {
// optimized version goes here
}
}
and an optimized call site produce the same bytecode as
MangledName.optimized(a, b, c, d, e, f);
with possible unboxing of some of the arguments, and possible boxing
of the return value, depending on the context. An unoptimized call
site would use the IFn interface and behave exactly as now or under
Clojure 1.2.
There are multiple ways to work around this limit. Destructuring, passing a
map, ...
All of those box any primitives as part of wrapping them in collections.
--
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: Bug with 1.3 primitive function return value hinting.
It's not silly, it's the fastest way to dispatch fn calls...
On Thu, Dec 15, 2011 at 8:05 PM, Softaddicts
lprefonta...@softaddicts.ca wrote:
From a JVM perspective, f( arglist) is a one arg function.
Try defining a fn with more than 20 args and you will get the
can't specify more than 20 arguments error.
This is the maximum supported by the Clojure runtime for non-optimized
fns.
Well, that's just silly, since a simple change to the fn macro would
make that go away without any hassle, as I already outlined. (The
error would remain for direct users of fn*, of course.)
One can argue about the argument size limit of optimized fn calls. Maybe 4
is too low.
These limitations has David pointed out are indirectly inherited from the
JVM architecture.
As I understand it, the problem is a combinatorial explosion of
interfaces with various signatures. Which is only a problem because,
for some reason, static calls to optimized fns are not made directly
to the fn's class. Why not just make an optimized fn class look like
public class MangledName implements IFn {
public Object invoke () { // unoptimized zero-arg version or arity
throw goes here }
public Object invoke (Object x) { // unoptimized one-arg version ... }
...
public static long optimized (int bar, double quux, Object
fiddlefaddle, long x, long y, long z) {
// optimized version goes here
}
}
and an optimized call site produce the same bytecode as
MangledName.optimized(a, b, c, d, e, f);
with possible unboxing of some of the arguments, and possible boxing
of the return value, depending on the context. An unoptimized call
site would use the IFn interface and behave exactly as now or under
Clojure 1.2.
There are multiple ways to work around this limit. Destructuring, passing a
map, ...
All of those box any primitives as part of wrapping them in collections.
--
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
--
Softaddictslprefonta...@softaddicts.ca sent by ibisMail!
--
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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 8:32 PM, Softaddicts lprefonta...@softaddicts.ca wrote: It's not silly, it's the fastest way to dispatch fn calls... Only calls with more than 20 arguments (or via apply) would need to be dispatched specially. -- 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: Bug with 1.3 primitive function return value hinting.
Your approach requires some lifting both in the runtime and the compiler. Why not sign a CA, implement it and submit a patch and supporting runtime data ? However there a plans to rewrite Clojure in Clojure on the JVM, some lessons have been learned while writing the ClojureScript compiler. This may impact your approach in the near future. Luc On Thu, Dec 15, 2011 at 8:32 PM, Softaddicts lprefonta...@softaddicts.ca wrote: It's not silly, it's the fastest way to dispatch fn calls... Only calls with more than 20 arguments (or via apply) would need be dispatched specially -- 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 -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail! -- 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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 8:47 PM, Softaddicts lprefonta...@softaddicts.ca wrote: Your approach requires some lifting both in the runtime and the compiler. I beg your pardon? Why not sign a CA, implement it and submit a patch and supporting runtime data ? Sounds like a lot of hoops to jump through. The direct-primitive-dispatch would be more worthy of such, perhaps. However there a plans to rewrite Clojure in Clojure on the JVM, some lessons have been learned while writing the ClojureScript compiler. This may impact your approach in the near future. Define the near future. Clojure in Clojure has been talked about for a long, long time, so you'll forgive me if I think that by the near future you might mean sometime between the sun swelling into a red giant and the release of Half-Life 2: Episode 3. :) -- 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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 8:16 PM, Cedric Greevey cgree...@gmail.com wrote:
public class MangledName implements IFn {
public Object invoke () { // unoptimized zero-arg version or arity
throw goes here }
public Object invoke (Object x) { // unoptimized one-arg version ... }
...
public static long optimized (int bar, double quux, Object
fiddlefaddle, long x, long y, long z) {
// optimized version goes here
}
}
This is not a good idea. You then have to know the class of the fn to do
the optimized dispatch. What's currently been done has left the door open
for high performance higher order usage.
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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 8:56 PM, David Nolen dnolen.li...@gmail.com wrote:
On Thu, Dec 15, 2011 at 8:16 PM, Cedric Greevey cgree...@gmail.com wrote:
public class MangledName implements IFn {
public Object invoke () { // unoptimized zero-arg version or arity
throw goes here }
public Object invoke (Object x) { // unoptimized one-arg version ... }
...
public static long optimized (int bar, double quux, Object
fiddlefaddle, long x, long y, long z) {
// optimized version goes here
}
}
This is not a good idea. You then have to know the class of the fn to do the
optimized dispatch. What's currently been done has left the door open for
high performance higher order usage.
There is no possibility of high performance higher order usage,
because primitives are boxed inside of collections. Unless you
proliferate int-vectors, double-vectors, long-seqs, and so forth and
map-longs, filter-doubles, remove-doubles, etc., etc., and that will
lead quickly to an unwieldy and messy API that will just leave
everyone longing for the way things used to be.
Meanwhile, what's currently been done makes for scarcely more
opportunities to reduce boxing than existed under 1.2.
Furthermore, even supposing someone adds, say, map-longs, there's
still a way to have the cake and eat it too. One could have all
*three* versions: MangledName implements IFn, if there're few enough
arguments one of the 1.3 interfaces, and has the static method. If one
of 1.3 interfaces is implemented, it can be used in the hypothetical
future map-longs. The four-argument limit then *only* applies to
*direct* higher-order use -- that is, (map-longs f s1 s2 s3 s4 s5)
would not work. If there were only four or fewer long-seqs, then f
would need to have four or fewer arguments and would then be capable
of having a 1.3 interface; or else f's position would be taken by a
closure that invoked the real f, something like #(f %1 42 %2 %4 0.5 %3
mumble), in which case the call to f is static rather than
higher-order (and can directly call the static optimized method of f's
class) and the closure can be compiled as a function with a 1.3
interface taking four longs.
--
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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 9:23 PM, Cedric Greevey cgree...@gmail.com wrote:
On Thu, Dec 15, 2011 at 8:56 PM, David Nolen dnolen.li...@gmail.com
wrote:
On Thu, Dec 15, 2011 at 8:16 PM, Cedric Greevey cgree...@gmail.com
wrote:
public class MangledName implements IFn {
public Object invoke () { // unoptimized zero-arg version or arity
throw goes here }
public Object invoke (Object x) { // unoptimized one-arg version ...
}
...
public static long optimized (int bar, double quux, Object
fiddlefaddle, long x, long y, long z) {
// optimized version goes here
}
}
This is not a good idea. You then have to know the class of the fn to do
the
optimized dispatch. What's currently been done has left the door open for
high performance higher order usage.
There is no possibility of high performance higher order usage,
because primitives are boxed inside of collections. Unless you
proliferate int-vectors, double-vectors, long-seqs, and so forth and
map-longs, filter-doubles, remove-doubles, etc., etc., and that will
lead quickly to an unwieldy and messy API that will just leave
everyone longing for the way things used to be.
This isn't true, look at gvec. All that is required is more sophisticated
analysis and perhaps a little bit of annotation. I'm optimistic that the
Clojure community can leverage the literature on stream fusion.
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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 9:31 PM, David Nolen dnolen.li...@gmail.com wrote: On Thu, Dec 15, 2011 at 9:23 PM, Cedric Greevey cgree...@gmail.com wrote: There is no possibility of high performance higher order usage, because primitives are boxed inside of collections. Unless you proliferate int-vectors, double-vectors, long-seqs, and so forth and map-longs, filter-doubles, remove-doubles, etc., etc., and that will lead quickly to an unwieldy and messy API that will just leave everyone longing for the way things used to be. This isn't true, Sure looks like it -- unless you have the runtime checking constantly what's in collections to detect all-one-primitive-type cases, which would gobble cycles and thereby defeat the purpose, or else thread static knowledge of what gets put where all through the code, which would mean either a proliferation of types as noted above, an equivalent proliferation of hints like (let [x ^long-seq s] ...), or a lot of static analysis by the compiler (with corresponding loss of dynamicness -- pretty much anything changing would require everything that depends on it to be recompiled, much, *much* worse than is already the case with direct callers of primitive-optimized fns. Regardless, you again snipped something pretty important: Furthermore, even supposing someone adds, say, map-longs, there's still a way to have the cake and eat it too. One could have all *three* versions: MangledName implements IFn, if there're few enough arguments one of the 1.3 interfaces, and has the static method. If one of 1.3 interfaces is implemented, it can be used in the hypothetical future map-longs. The four-argument limit then *only* applies to *direct* higher-order use -- that is, (map-longs f s1 s2 s3 s4 s5) would not work. If there were only four or fewer long-seqs, then f would need to have four or fewer arguments and would then be capable of having a 1.3 interface; or else f's position would be taken by a closure that invoked the real f, something like #(f %1 42 %2 %4 0.5 %3 mumble), in which case the call to f is static rather than higher-order (and can directly call the static optimized method of f's class) and the closure can be compiled as a function with a 1.3 interface taking four longs. -- 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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 9:47 PM, Cedric Greevey cgree...@gmail.com wrote: ... Nobody wants map-longs. We have lovely abstractions like map / filter / reduce, we have primitive fns, we have collections which can hold primitives, we have type hints. What I'd like to see is that by adding one single annotation to this (reduce + foo) like so: (reduce + ^long-vector foo) triggers the compiler to eliminate all unnecessary allocations and work only on unboxed data. Another approach might be some of Rich Hickey's ideas of about primitive fns that understand chunks. Do your ideas get us any closer to writing idiomatic Clojure yet getting close to the performance of primitive operations on collections of unboxed data? 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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 10:13 PM, David Nolen dnolen.li...@gmail.com wrote: Nobody wants map-longs. We have lovely abstractions like map / filter / reduce, we have primitive fns, we have collections which can hold primitives, we have type hints. What I'd like to see is that by adding one single annotation to this (reduce + foo) like so: (reduce + ^long-vector foo) triggers the compiler to eliminate all unnecessary allocations and work only on unboxed data. Another approach might be some of Rich Hickey's ideas of about primitive fns that understand chunks. Do your ideas get us any closer to writing idiomatic Clojure yet getting close to the performance of primitive operations on collections of unboxed data? They certainly don't get us any further; they aren't trying to address that at all, but instead to address other issues, such as that if I have a function that takes five values I can't optimize it. For instance, if I want to optimize (distance x1 y1 z1 x2 y2 z2), I can't. If I declare anything primitive, the compiler complains as there are more than four arguments. If I change the input format to (distance [x1 y1 z1] [x2 y2 z2]) the numbers are boxed as collection elements, though at least I can now make the return be hinted as ^double without the compiler complaining. Short of creating a Point3D deftype with primitive components, there doesn't seem to be a way with Clojure 1.3 to optimize this; and having to create lots of helper types like Point3D smacks of Java-like coding instead of Clojure-like coding to me. So, I can wait until either larger numbers of primitive arguments are supported, or primitive vectors are supported. But I can see how to support larger numbers of primitive arguments *tomorrow* -- it probably would be that fast to code, for someone already knowledgeable about Clojure's internals and with commit access to the repository. I *can't* see how to easily support collections-of-primitives without a *lot* more work, including new syntax, in a *lot* of parts of the language core, with a *lot* more likely damage to backward compatibility. So there is my argument in a nutshell. There's an improvement we can make *now*, *without* foreclosing on an improvement that *may* be possible *in a few years or so*, and that would make mine, and probably others', projects easier to optimize *now*, and which therefore *should* be made, and quickly. -- 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: Bug with 1.3 primitive function return value hinting.
On Thu, Dec 15, 2011 at 11:03 PM, Cedric Greevey cgree...@gmail.com wrote: For instance, if I want to optimize (distance x1 y1 z1 x2 y2 z2), I can't. If I declare anything primitive, the compiler complains as there are more than four arguments. If I change the input format to (distance [x1 y1 z1] [x2 y2 z2]) the numbers are boxed as collection elements, though at least I can now make the return be hinted as ^double without the compiler complaining. Short of creating a Point3D deftype with primitive components, there doesn't seem to be a way with Clojure 1.3 to optimize this; and having to create lots of helper types like Point3D smacks of Java-like coding instead of Clojure-like coding to me. I would not exactly call this: (deftype Point3d [^double x ^double y ^double z] IVecMath (distance [this other] ...)) Java coding :) I don't buy your example but I can certainly imagine desirable cases. I *can't* see how to easily support collections-of-primitives without a *lot* more work, including new syntax, in a *lot* of parts of the language core, with a *lot* more likely damage to backward compatibility. Your solution also sounds like a *lot* of work for *someone*. So there is my argument in a nutshell. There's an improvement we can make *now*, *without* foreclosing on an improvement that *may* be possible *in a few years or so*, and that would make mine, and probably others', projects easier to optimize *now*, and which therefore *should* be made, and quickly. What should and will happen is of course completely based on the level of contribution from interested parties, no? For me the discussion is exhausted. But you've spent time discussing it passionately, I recommend you send in your CA and write up these thoughts in a Clojure design document. 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: Bug with 1.3 primitive function return value hinting.
On Dec 15, 10:03 pm, Cedric Greevey cgree...@gmail.com wrote: So, I can wait until either larger numbers of primitive arguments are supported, or primitive vectors are supported. We already have persistent vectors that store their contents as primitives with gvec. If you take a look at IFn.java, you'll see that there is a combinatorial explosion of interfaces. Another related bug in 1.3: calling a primitive function whose return typed is hinted as a subtype of Object (such as ArrayList) causes an AbstractMethodError. -- 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
why would this statement java -server ???
I was looking at the installation in Learning clojure and the batch file had this statement: java -server -cp .;%CLOJURE_JAR% clojure.main why is the server in the line and what is it referencing??? Thanks for any help -- 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: why would this statement java -server ???
It means to use the server version of JVM On Dec 15, 2011, at 11:48 PM, jayvandal s...@ida.net wrote: I was looking at the installation in Learning clojure and the batch file had this statement: java -server -cp .;%CLOJURE_JAR% clojure.main why is the server in the line and what is it referencing??? Thanks for any help -- 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
why would this statement java -server ???
I was looking at the installation in Learning clojure and the batch file had this statement: java -server -cp .;%CLOJURE_JAR% clojure.main why is the server in the line and what is it referencing??? Thanks for any help -- 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: why would this statement java -server ???
On Fri, Dec 16, 2011 at 05:48, jayvandal s...@ida.net wrote: I was looking at the installation in Learning clojure and the batch file had this statement: java -server -cp .;%CLOJURE_JAR% clojure.main why is the server in the line and what is it referencing??? Thanks for any help The Java virtual machine (JVM) can run either in client or server mode. The server virtual machine's just in time (JIT) compiler generates better performing machine code. The down side is that startup is slower (generating better code is more work), but performance after startup is better (better code runs faster). The byte code Clojure translates to benefits considerably from the optimizations offered by the server virtual machine. Here's a picture: Clojure source -(Clojure compiler)- JVM byte code -(JIT Compiler)- Machine code java -server makes -(JIT Compiler)- do more work to generate better machine code. // 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
