Re: JVM 7 support (invokedynamic)
On Thu, Aug 25, 2011 at 2:49 AM, Tal Liron wrote: > Hey folks, > > I just want to reassure y'all that I am working on this. It took a while to > create a test environment: one of the challenges of using invokedynamic is > that the Java language does not support it; so the best way to test right > now is with ASM 4.0, which is still not officially released. Documentation > on the opcode is also somewhat scattered, and mostly out of date, since > JSR-292 has changed quite a bit until the final release. The JRuby folk are > definitely at the cutting edge of this right (well, after all, JRuby's John > Rose is the key mover and architect behind the JSR), and I'm trying to learn > from their implementation. Right now I'm working on a code tree outside the > main Clojure source, and once that seems to work, I will try to merge it > into a branch. > > So, it's not *quite* as easy as I hoped, but I still think it will be much > easier to use invokedynamic in Clojure than in JRuby. > > I'll keep the mailing list updated on my (slow) progress, and will > definitely make the code public once it becomes ... presentable. Just out of curiosity, what will this actually enable? Optimizations? What can we expect might perform faster -- calling closures? Functional function-calls such as map, reduce, etc.? Multimethods, protocols, and things like that? -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- 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
mini-version of clojure.jar?
My company (read: I) develop an web-based educational application (a language lab) implemented as a Java applet. I have spendt the summer porting it to Clojure. I am very happy with the results. Except: The download (and therefore the download-time) has increased dramatically, as I now include the clojure.jar as part of the download. (Actually, I repackage the content together with my application.) This, I fear is going to hit alot of the pupils hard, when 20 pupils at a time attempt to access the applet for the first time over the mediocre (at best) web-connections at their schools. Yes, I do manipulate the java applet cache-params. But There will always be a need for full downloads - both for first- time-users, and when I update the applet (frequently). My question: Is there anyway to reduce the size of the jar - drastically? Can I somehow remove most of the class-files generated from core.clj etc, and still have everything working properly? Tips/hints/suggestions? (Plug: See my open-source JS-embed code for Java applets: http://bitbucket.terjedahl.no/terjedahl/appletjs ) -- 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: mini-version of clojure.jar?
Hi, There is a slim version of the clojure jar. See here for example here: http://repo1.maven.org/maven2/org/clojure/clojure/1.3.0-beta1/ 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: mini-version of clojure.jar?
The slim jar probably won't work in an applet, because it does classloader stuff (unless you have a signed applet). -- Dave -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: JVM 7 support (invokedynamic)
invokedynamic reduces drastically the lookup times you require in dynamic languages. The JVM and JIT understand what you are trying to do and can optimize the invocation. Currently all dynamic languages targeting the JVM generate code that cannot be easily optimized by the JVM before invokedynamic was available. -- Paulo On Aug 25, 9:59 am, Ken Wesson wrote: > On Thu, Aug 25, 2011 at 2:49 AM, Tal Liron wrote: > > Hey folks, > > > I just want to reassure y'all that I am working on this. It took a while to > > create a test environment: one of the challenges of using invokedynamic is > > that the Java language does not support it; so the best way to test right > > now is with ASM 4.0, which is still not officially released. Documentation > > on the opcode is also somewhat scattered, and mostly out of date, since > > JSR-292 has changed quite a bit until the final release. The JRuby folk are > > definitely at the cutting edge of this right (well, after all, JRuby's John > > Rose is the key mover and architect behind the JSR), and I'm trying to learn > > from their implementation. Right now I'm working on a code tree outside the > > main Clojure source, and once that seems to work, I will try to merge it > > into a branch. > > > So, it's not *quite* as easy as I hoped, but I still think it will be much > > easier to use invokedynamic in Clojure than in JRuby. > > > I'll keep the mailing list updated on my (slow) progress, and will > > definitely make the code public once it becomes ... presentable. > > Just out of curiosity, what will this actually enable? Optimizations? > What can we expect might perform faster -- calling closures? > Functional function-calls such as map, reduce, etc.? Multimethods, > protocols, and things like that? > > -- > Protege: What is this seething mass of parentheses?! > Master: Your father's Lisp REPL. This is the language of a true > hacker. Not as clumsy or random as C++; a language for a more > civilized age. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: is there some gotchas with the contains? function and strings?
I wrote a few examples up for explaining this: http://blog.jayfields.com/2010/12/clojure-get-get-in-contains-and-some.html they might be helpful if you want additional info above and beyond the docs. Cheers, Jay On Aug 24, 2011, at 5:15 PM, Mark Rathwell wrote: > See the doc below. What (contains? [1 2] 1) is testing is whether [1 > 2] has a value at index 1 (the key value for numerically indexed > collections). It does, so it returns true. What you are probably > looking for is the Java method .contains of the vector: > > (.contains ["a" "b"] "a") > ;=> true > > (.contains [1 2 5] 5) > ;=> true > > user> (doc contains?) > - > clojure.core/contains? > ([coll key]) > Returns true if key is present in the given collection, otherwise > returns false. Note that for numerically indexed collections like > vectors and Java arrays, this tests if the numeric key is within the > range of indexes. 'contains?' operates constant or logarithmic time; > it will not perform a linear search for a value. See also 'some'. > > > > > On Wed, Aug 24, 2011 at 4:57 PM, Andrew Xue wrote: >> the below seems odd >> >> user=> (contains? [1 2] 1) >> true >> user=> (contains? ["a" "b"] "a") >> false >> >> am i missing something? >> >> -- >> 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: Michael Fogus will talk about ClojureScript tomorrow night (8/25)
That about sums it up. Specifically, I will talk about how some of the Clojure features (fns, types, protocols, etc.) are emitted in JavaScript and why one compiled form was chosen over any other (with proper caveats for future change). -- 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: mini-version of clojure.jar?
Yes. My applet is signed. So that is not a problem. Any thoughts about difference in performance between "slim" and "full"? My applet mostly does swing-stuff, http GETS and POSTS - and audio playback and recording. On 25 Aug, 10:40, David Powell wrote: > The slim jar probably won't work in an applet, because it does classloader > stuff (unless you have a signed applet). > > -- > Dave -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: mini-version of clojure.jar?
The runtime performance should be the same, but the startup time will be slower because it will have to compile the clojure code at load time. -- Dave On 25 Aug 2011 12:15, "Terje Dahl" wrote: > Yes. My applet is signed. So that is not a problem. > > Any thoughts about difference in performance between "slim" and > "full"? > My applet mostly does swing-stuff, http GETS and POSTS - and audio > playback and recording. > > > > > On 25 Aug, 10:40, David Powell wrote: >> The slim jar probably won't work in an applet, because it does classloader >> stuff (unless you have a signed applet). >> >> -- >> Dave > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- 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: mini-version of clojure.jar?
Hi, Am Donnerstag, 25. August 2011 13:14:51 UTC+2 schrieb Terje Dahl: > Any thoughts about difference in performance between "slim" and > "full"? > The slim version has longer startup time, I presume. Otherwise there shouldn't be a difference in performance. 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: Why can't I print new sequence?
Ken: Thanks for the answer. You're correct about distinct. I'm working through some exercises. cmn -- 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: JVM 7 support (invokedynamic)
This does not really answer Ken's question, does it ? 2011/8/25 Paulo Pinto > invokedynamic reduces drastically the lookup times you require in > dynamic languages. The JVM and JIT understand what you are trying > to do and can optimize the invocation. > > Currently all dynamic languages targeting the JVM generate code > that cannot be easily optimized by the JVM before invokedynamic > was available. > > -- > Paulo > > On Aug 25, 9:59 am, Ken Wesson wrote: > > On Thu, Aug 25, 2011 at 2:49 AM, Tal Liron wrote: > > > Hey folks, > > > > > I just want to reassure y'all that I am working on this. It took a > while to > > > create a test environment: one of the challenges of using invokedynamic > is > > > that the Java language does not support it; so the best way to test > right > > > now is with ASM 4.0, which is still not officially released. > Documentation > > > on the opcode is also somewhat scattered, and mostly out of date, since > > > JSR-292 has changed quite a bit until the final release. The JRuby folk > are > > > definitely at the cutting edge of this right (well, after all, JRuby's > John > > > Rose is the key mover and architect behind the JSR), and I'm trying to > learn > > > from their implementation. Right now I'm working on a code tree outside > the > > > main Clojure source, and once that seems to work, I will try to merge > it > > > into a branch. > > > > > So, it's not *quite* as easy as I hoped, but I still think it will be > much > > > easier to use invokedynamic in Clojure than in JRuby. > > > > > I'll keep the mailing list updated on my (slow) progress, and will > > > definitely make the code public once it becomes ... presentable. > > > > Just out of curiosity, what will this actually enable? Optimizations? > > What can we expect might perform faster -- calling closures? > > Functional function-calls such as map, reduce, etc.? Multimethods, > > protocols, and things like that? > > > > -- > > Protege: What is this seething mass of parentheses?! > > Master: Your father's Lisp REPL. This is the language of a true > > hacker. Not as clumsy or random as C++; a language for a more > > civilized age. > > -- > 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: JVM 7 support (invokedynamic)
Hi, Disclaimer: I have no clue whatsoever about the low-level JVM stuff. I remember Rich saying in one of his talks/interviews, that invokedynamic is not very interesting for Clojure and that Clojure won't really benefit from it. I'm far from understanding these things. So details on what's improved would be very interesting, I guess. 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
(deftrace sample
Does anyone have a deftrace sample handy? I'm getting Caused by: clojure.lang.Compiler$CompilerException: java.lang.Exception: Unable to resolve symbol: deftrace in this context (repl_test.clj:15) in (ns repl-test (:gen-class) (:use clojure.contrib.command-line) (:require [clojure.contrib.string :as cstr]) (:require clojure.contrib.trace) (:use clojure-csv.core)) (def d3 [1 2 3 1 4 1 2]) (defn x-in-seq [x temp-seq] (if (nil? (some #(= x %) temp-seq)) x)) (deftrace f1 [in-seq] (loop [new-seq [] cur-seq in-seq] (if (nil? cur-seq) new-seq (if-not (nil? (x-in-seq (first cur-seq) new-seq)) (recur (conj new-seq (first cur-seq)) (rest cur-seq)) (recur new-seq (rest cur-seq)) (defn -main [& args] -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: JVM 7 support (invokedynamic)
That's correct. That is why Clojure/core hasn't prioritized this work. Cheers, Aaron Bedra -- Clojure/core http://clojure.com On 08/25/2011 08:37 AM, Meikel Brandmeyer (kotarak) wrote: Hi, Disclaimer: I have no clue whatsoever about the low-level JVM stuff. I remember Rich saying in one of his talks/interviews, that invokedynamic is not very interesting for Clojure and that Clojure won't really benefit from it. I'm far from understanding these things. So details on what's improved would be very interesting, I guess. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (deftrace sample
Forgot about doing this: (:require [clojure.contrib.trace :as ctr]) cmn -- 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: Peculiar transients behaviour
Please search through previous messages/tickets before posting new
issues. This issue has been fixed as of commit da412909d36551a526ed and
will be included in the -beta2 release. It was originally ticketed here:
http://dev.clojure.org/jira/browse/CLJ-816
(let [m (into {} (for [x (range 10)] [(rand) (rand)]))]
(println (count (distinct (map hash (keys m)
((juxt count identity) (persistent!
(reduce dissoc! (transient m) (keys m)
10
[0 {}]
Cheers,
Aaron Bedra
--
Clojure/core
http://clojure.com
On 08/24/2011 04:32 AM, Alan Malloy wrote:
On Aug 24, 12:27 am, Alan Malloy wrote:
On Aug 23, 11:38 pm, Ken Wesson wrote:
What does zipmap do if the key seq contains duplications?
That was my instinct too, but (a) a few thousand numbers won't collide
very often at all given the problem space, and (b) some experimenting
indicates that the key-seq is always 100k elements large - no
duplicates.
HOWEVER, I did find the problem: the keys themselves don't collide,
but their hashes do. The number of elements that get messed up is
related to the number of hash collisions, but I still don't quite
understand how they interact.
Here's a modified code snippet that demonstrates the issue:
user> (let [m (apply zipmap (repeatedly 2 #(repeatedly 10 rand)))]
(println (count (distinct (map hash (keys m)
((juxt count identity) (persistent!
(reduce dissoc! (transient m) (keys m)
10 ;; no collisions
[0 {}] ;; map is empty at the end
user> (let [m (apply zipmap (repeatedly 2 #(repeatedly 10 rand)))]
(println (count (distinct (map hash (keys m)
((juxt count identity) (persistent!
(reduce dissoc! (transient m) (keys m)
6 ;; four collisions
[8 {0.30426231137219917 0.8531183785687654, 0.8893047006425385
0.4788315896128895, 0.47854633997540674 0.45133768991797785,
0.5265638224227486 0.7724779126227945}] ;; a four-element map that
reports its count as eight!!!
That last comment seems to indicate a very serious error somewhere:
not only is the transient map broken, but it creates a broken
persistent object. I'll file a JIRA issue for this, and see if I can
find out any more about the cause.
FWIW, I'm using 1.2.1 for the above output.
Ticket is at http://dev.clojure.org/jira/browse/CLJ-829
--
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: mini-version of clojure.jar?
> My company (read: I) develop an web-based educational application (a > language lab) implemented as a Java applet. > > I have spendt the summer porting it to Clojure. I am very happy with > the results. > > Except: The download (and therefore the download-time) has increased > dramatically, as I now include the clojure.jar as part of the > download. > (Actually, I repackage the content together with my application.) > > This, I fear is going to hit alot of the pupils hard, when 20 pupils > at a time attempt to access the applet for the first time over the > mediocre (at best) web-connections at their schools. > > Yes, I do manipulate the java applet cache-params. > But There will always be a need for full downloads - both for first- > time-users, and when I update the applet (frequently). > > My question: > Is there anyway to reduce the size of the jar - drastically? > Can I somehow remove most of the class-files generated from core.clj > etc, and still have everything working properly? > Tips/hints/suggestions? Great question. Post 1.3 we hope to look at a super-slim jar. The design notes are minimal at this point, but FWIW: http://dev.clojure.org/display/design/Build+Profiles Stu Stuart Halloway Clojure/core http://clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. 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
Making clojure.lang.IDeref a protocol
Hey, Has there been discussion about making clojure.lang.IDeref a protocol? I'd like to extend some java types to this the IDeref interface but currently this is not possible. I feel like this is such a common idiom, to get values, and doing so will allow me to leverage the @ reader macro for many data types. Best, Brent -- 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
Web Services with Clojure
Ok after two days I manage to write framework for publishing and calling webservices (yesterday I asked you for such framework but only RESTful are available). Right now this implementation supports only primitve types and was tested in Java distributed environment (needs to extend to arrays, maps,sets and complex types and also test with C#). Here is a snippet of usage code: server.clj (ns bpml.server (:use [bpml ws])) ; publish web service with implementing methods (provide-ws "com.jaaka.michael" "Sales" "http://localhost:8283/"; (String sayHello [ String name String b ] (str "Hello " name)) (Integer addNumbers [ Integer a Integer b ] (+ a b)) (void doSomething[ String dom ] (println dom)) ) and client.clj (ns bpml.client (:use [bpml ws])) ; generate client stub (generate-ws-client-stub "http://localhost:8283/sales?wsdl";) ; first compact way but assumes Service and Port (let [ c (get-jax-ws-client "com.jaaka.michael" "Sales") ] (println "sum is" (.addNumbers c 2 31)) (.doSomething c "this rox")) ; explicite call of generated stub (let [ c (.getSalesPort (get-ws-client-stub "com.jaaka.michael" "SalesService")) ] (.addNumbers c 2 10)) under the cover we have newest jax-ws so it is possible to implement in future rest of ws technologies (transactions, security, attachments and so on). The idea is simple. Generate java class with proper annotations, compile, publish, now for client, fetch the wsdl, generate the client stub with wsimport, call the desired method, and backing to server, invoke clojure code returning its results back to the client. All is dynamic and easy in use as for REPL befits. -- 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: Making clojure.lang.IDeref a protocol
> Hey, > > Has there been discussion about making clojure.lang.IDeref a protocol? > I'd like to extend some java types to this the IDeref interface but > currently this is not possible. I feel like this is such a common > idiom, to get values, and doing so will allow me to leverage the @ > reader macro for many data types. > > Best, > Brent Someday. The challenge is load order. A lot would have to change to make protocols available early enough in Clojure's bootstrap to allow this. That said, I don't know many Java classes that have value-yielding semantics. And if you are writing your own class, you can implement the IDeref interface. Stu Stuart Halloway Clojure/core http://clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - 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
I/O
One of the first things that I want to know how to do when I learn a new programming language is how to read from or print to a file. The problem is that none of the clojure books do a good job of explaining how to do so, in my opinion. What little is said is usually tucked away and not highlighted in any manner (yes I know that "Clojure in Action" has the chapter on databases). I think part of the reason for this is the conception (maybe misconception) that most people are familiar with java and since there is java interopt they should be able to figure this out. As more and more schools are starting to use Python as their beginning CS language, this may well not be the case soon. My hope that the next Clojure book that comes out prominently places a section (chapter?) on IO near the front of the book. -- 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: I/O
I too stumbled upon this a while ago. I might even say that on some level it's so simple that there is not much documentation about it, and at some point it gets 'complex' enough that you should know about java enough. The simplest way is to slurp or spit. slurp reads a file into a string, and spit writes a string into a file. Then there is the with-open macro(?) which opens connections and closes them when one. The reader and writer opens a java Reader and Writer classes respectively. (They're interfaces, but those functions try to figure out what kind of handle you're trying to open). Also the output-stream and input-stream handle it a bit. (with-open [r (reader "http://www.reddit.com";)] (.read r)) And to finish this off with a shameless plug; I wrote a blog post about downloading a random wallpaper from reddit, which handles reading http content, parsing json and reading/writing binary files. http://users.utu.fi/machra/posts/2011-08-24-2-reddit-clojure.html -- Mats Rauhala MasseR pgp9yGpYZlu52.pgp Description: PGP signature
Re: JVM 7 support (invokedynamic)
On Thu, Aug 25, 2011 at 5:18 AM, Paulo Pinto wrote: > invokedynamic reduces drastically the lookup times you require in > dynamic languages. The JVM and JIT understand what you are trying > to do and can optimize the invocation. It's important to note that this only applies to method calls, not function invocations. > Currently all dynamic languages targeting the JVM generate code > that cannot be easily optimized by the JVM before invokedynamic > was available. That's not really true; it's easy in Clojure to optimize with type hints. Since Ruby isn't designed to run on the JVM, it doesn't have any syntax for type hints to avoid reflective calls. I believe method calls that use invokedynamic are much faster than reflective (non-hinted) method calls, but still a bit slower than type-hinted calls. So if you are in a tight loop you'll need to type hint anyway. I suspect we'd get a lot more bang-for-the-buck out of type inference than invokedynamic since that may allow us to get the benefits of type hints without the grunt work of scattering declarations everywhere. -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: Peculiar transients behaviour
I did, of course. I searched for "transient", and didn't find any
describing this issue. And looking at the issue you link to, I still
don't see how it's related: it's a patch specifically for vectors, and
this code doesn't touch vectors; and it involves changes to a
transient "leaking" back into the original persistent, while this code
is about getting the wrong persistent object back after some changes.
I don't have a lot of experience with building clojure, but I'll try
compiling latest master and trying it out. In the meantime, did you
try this code more than once? Because it includes randomness,
sometimes it works without problems.
On Aug 25, 6:03 am, Aaron Bedra wrote:
> Please search through previous messages/tickets before posting new
> issues. This issue has been fixed as of commit da412909d36551a526ed and
> will be included in the -beta2 release. It was originally ticketed here:
>
> http://dev.clojure.org/jira/browse/CLJ-816
>
> (let [m (into {} (for [x (range 10)] [(rand) (rand)]))]
> (println (count (distinct (map hash (keys m)
> ((juxt count identity) (persistent!
> (reduce dissoc! (transient m) (keys m)
> 10
> [0 {}]
>
> Cheers,
>
> Aaron Bedra
> --
> Clojure/corehttp://clojure.com
>
> On 08/24/2011 04:32 AM, Alan Malloy wrote:
>
>
>
>
>
>
>
> > On Aug 24, 12:27 am, Alan Malloy wrote:
> >> On Aug 23, 11:38 pm, Ken Wesson wrote:
>
> >>> What does zipmap do if the key seq contains duplications?
> >> That was my instinct too, but (a) a few thousand numbers won't collide
> >> very often at all given the problem space, and (b) some experimenting
> >> indicates that the key-seq is always 100k elements large - no
> >> duplicates.
>
> >> HOWEVER, I did find the problem: the keys themselves don't collide,
> >> but their hashes do. The number of elements that get messed up is
> >> related to the number of hash collisions, but I still don't quite
> >> understand how they interact.
>
> >> Here's a modified code snippet that demonstrates the issue:
>
> >> user> (let [m (apply zipmap (repeatedly 2 #(repeatedly 10 rand)))]
> >> (println (count (distinct (map hash (keys m)
> >> ((juxt count identity) (persistent!
> >> (reduce dissoc! (transient m) (keys m)
> >> 10 ;; no collisions
> >> [0 {}] ;; map is empty at the end
>
> >> user> (let [m (apply zipmap (repeatedly 2 #(repeatedly 10 rand)))]
> >> (println (count (distinct (map hash (keys m)
> >> ((juxt count identity) (persistent!
> >> (reduce dissoc! (transient m) (keys m)
> >> 6 ;; four collisions
> >> [8 {0.30426231137219917 0.8531183785687654, 0.8893047006425385
> >> 0.4788315896128895, 0.47854633997540674 0.45133768991797785,
> >> 0.5265638224227486 0.7724779126227945}] ;; a four-element map that
> >> reports its count as eight!!!
>
> >> That last comment seems to indicate a very serious error somewhere:
> >> not only is the transient map broken, but it creates a broken
> >> persistent object. I'll file a JIRA issue for this, and see if I can
> >> find out any more about the cause.
>
> >> FWIW, I'm using 1.2.1 for the above output.
> > Ticket is athttp://dev.clojure.org/jira/browse/CLJ-829
--
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: Peculiar transients behaviour
Update: just built master, and issue still exists. If you want to be
"sure" you get it, just add another zero to the input range. I'll
mention that in the ticket as well.
On Aug 25, 10:14 am, Alan Malloy wrote:
> I did, of course. I searched for "transient", and didn't find any
> describing this issue. And looking at the issue you link to, I still
> don't see how it's related: it's a patch specifically for vectors, and
> this code doesn't touch vectors; and it involves changes to a
> transient "leaking" back into the original persistent, while this code
> is about getting the wrong persistent object back after some changes.
>
> I don't have a lot of experience with building clojure, but I'll try
> compiling latest master and trying it out. In the meantime, did you
> try this code more than once? Because it includes randomness,
> sometimes it works without problems.
>
> On Aug 25, 6:03 am, Aaron Bedra wrote:
>
>
>
>
>
>
>
> > Please search through previous messages/tickets before posting new
> > issues. This issue has been fixed as of commit da412909d36551a526ed and
> > will be included in the -beta2 release. It was originally ticketed here:
>
> >http://dev.clojure.org/jira/browse/CLJ-816
>
> > (let [m (into {} (for [x (range 10)] [(rand) (rand)]))]
> > (println (count (distinct (map hash (keys m)
> > ((juxt count identity) (persistent!
> > (reduce dissoc! (transient m) (keys m)
> > 10
> > [0 {}]
>
> > Cheers,
>
> > Aaron Bedra
> > --
> > Clojure/corehttp://clojure.com
>
> > On 08/24/2011 04:32 AM, Alan Malloy wrote:
>
> > > On Aug 24, 12:27 am, Alan Malloy wrote:
> > >> On Aug 23, 11:38 pm, Ken Wesson wrote:
>
> > >>> What does zipmap do if the key seq contains duplications?
> > >> That was my instinct too, but (a) a few thousand numbers won't collide
> > >> very often at all given the problem space, and (b) some experimenting
> > >> indicates that the key-seq is always 100k elements large - no
> > >> duplicates.
>
> > >> HOWEVER, I did find the problem: the keys themselves don't collide,
> > >> but their hashes do. The number of elements that get messed up is
> > >> related to the number of hash collisions, but I still don't quite
> > >> understand how they interact.
>
> > >> Here's a modified code snippet that demonstrates the issue:
>
> > >> user> (let [m (apply zipmap (repeatedly 2 #(repeatedly 10 rand)))]
> > >> (println (count (distinct (map hash (keys m)
> > >> ((juxt count identity) (persistent!
> > >> (reduce dissoc! (transient m) (keys m)
> > >> 10 ;; no collisions
> > >> [0 {}] ;; map is empty at the end
>
> > >> user> (let [m (apply zipmap (repeatedly 2 #(repeatedly 10 rand)))]
> > >> (println (count (distinct (map hash (keys m)
> > >> ((juxt count identity) (persistent!
> > >> (reduce dissoc! (transient m) (keys m)
> > >> 6 ;; four collisions
> > >> [8 {0.30426231137219917 0.8531183785687654, 0.8893047006425385
> > >> 0.4788315896128895, 0.47854633997540674 0.45133768991797785,
> > >> 0.5265638224227486 0.7724779126227945}] ;; a four-element map that
> > >> reports its count as eight!!!
>
> > >> That last comment seems to indicate a very serious error somewhere:
> > >> not only is the transient map broken, but it creates a broken
> > >> persistent object. I'll file a JIRA issue for this, and see if I can
> > >> find out any more about the cause.
>
> > >> FWIW, I'm using 1.2.1 for the above output.
> > > Ticket is athttp://dev.clojure.org/jira/browse/CLJ-829
--
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: I/O
Great question. And great answer. Seriously! I did not know it could be that easy. So an http GET just needs 1 lines!: (slurp (reader "http://google.com";)) (Don't forget: (use 'clojure.java.io) ) Is there an equally easy way to do an http POST? And also a multi-part (including one or more files in the POST)? On 25 Aug, 18:24, Mats Rauhala wrote: > I too stumbled upon this a while ago. I might even say that on some > level it's so simple that there is not much documentation about it, and > at some point it gets 'complex' enough that you should know about java > enough. > > The simplest way is to slurp or spit. slurp reads a file into a string, > and spit writes a string into a file. > > Then there is the with-open macro(?) which opens connections and closes > them when one. The reader and writer opens a java Reader and Writer > classes respectively. (They're interfaces, but those functions try to > figure out what kind of handle you're trying to open). Also the > output-stream and input-stream handle it a bit. > > (with-open [r (reader "http://www.reddit.com";)] > (.read r)) > > And to finish this off with a shameless plug; I wrote a blog post about > downloading a random wallpaper from reddit, which handles reading http > content, parsing json and reading/writing binary files. > > http://users.utu.fi/machra/posts/2011-08-24-2-reddit-clojure.html > > -- > Mats Rauhala > MasseR > > application_pgp-signature_part > < 1 KVisLast ned -- 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: I/O
For that you'll have to look into the clj-http library:
https://github.com/mmcgrana/clj-http
>From the readme: (client/post "http://site.com/resources"; {:body "string"})
On Thu, Aug 25, 2011 at 2:00 PM, Terje Dahl wrote:
> Great question. And great answer.
> Seriously! I did not know it could be that easy.
> So an http GET just needs 1 lines!:
>
>(slurp (reader "http://google.com";))
>
> (Don't forget: (use 'clojure.java.io) )
>
>
> Is there an equally easy way to do an http POST?
> And also a multi-part (including one or more files in the POST)?
>
>
>
> On 25 Aug, 18:24, Mats Rauhala wrote:
> > I too stumbled upon this a while ago. I might even say that on some
> > level it's so simple that there is not much documentation about it, and
> > at some point it gets 'complex' enough that you should know about java
> > enough.
> >
> > The simplest way is to slurp or spit. slurp reads a file into a string,
> > and spit writes a string into a file.
> >
> > Then there is the with-open macro(?) which opens connections and closes
> > them when one. The reader and writer opens a java Reader and Writer
> > classes respectively. (They're interfaces, but those functions try to
> > figure out what kind of handle you're trying to open). Also the
> > output-stream and input-stream handle it a bit.
> >
> > (with-open [r (reader "http://www.reddit.com";)]
> > (.read r))
> >
> > And to finish this off with a shameless plug; I wrote a blog post about
> > downloading a random wallpaper from reddit, which handles reading http
> > content, parsing json and reading/writing binary files.
> >
> > http://users.utu.fi/machra/posts/2011-08-24-2-reddit-clojure.html
> >
> > --
> > Mats Rauhala
> > MasseR
> >
> > application_pgp-signature_part
> > < 1 KVisLast ned
>
> --
> 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: JVM 7 support (invokedynamic)
@Aaron: Could you go into why this is the case? What does jruby do that it needs it so much and clojure does not. @Tal Liron: You seem to differ in your opinion with Aaron (pretty sure you would not be investing your time otherwise). What exactlly are you attempting to speed up and how does invokedynamic 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: JVM 7 support (invokedynamic)
Hmm... If you didn't have to worry about Java <7 compatibility, for one thing with invokedynamic you could remove a lot of code from Clojure. No more IFn or AFn. You simply have a method handle. Second, I think it would allow the JVM to have a better view into optimization, and would allow the JVM to optimize something speculatively and allow for Clojure tell the JVM when to deoptimize with a SwitchPoints and MutableCallSites. I don't think Phil's comparison is actually a fair one. If you're going to use type hints or type inference, then you're basically moving more towards static typing, which of course will be faster. If you're going to do dynamic dispatch without compile time types to aid the compiler, then invokedynamic is most certainly going to be faster than reflection, and make for much simpler code. I think invokedynamic would be great for Clojure. Of course there are other concerns like the fact that it is only for Java 7, so maybe it won't be the best place to put resources at the moment. But that's no reason that Tal can't work on it. Paul -- 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: JVM 7 support (invokedynamic)
On Thu, Aug 25, 2011 at 2:35 PM, Paul Stadig wrote: > I think invokedynamic would be great for Clojure. Of course there are other > concerns like the fact that it is only for Java 7, so maybe it won't be the > best place to put resources at the moment. But that's no reason that Tal > can't work on it. For the record, I didn't mean to discourage anyone from working on it, only to explain why it hasn't been implemented yet. -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: JVM 7 support (invokedynamic)
On 25 Ago, 20:21, Nick Zbinden wrote: > @Aaron: Could you go into why this is the case? What does jruby do > that it needs it so much and clojure does not. > > @Tal Liron: You seem to differ in your opinion with Aaron (pretty sure > you would not be investing your time otherwise). What exactlly are you > attempting to speed up and how does invokedynamic help? I'm neither of them, nor I am a Clojure hacker, but still I think I can contribute something to the discussion. invokedynamic is basically a hook in the JVM's linking system; it allows language implementers to resolve method calls respecting the semantics of their language, but letting the JVM know about it so it can optimize those method calls. invokedynamic is not just that - it has advanced features like the ability to invalidate call sites (thus forcing the JVM to redo the linking) or to emit guarded calls, in order to specialize "fast paths" (e.g. primitive arithmetic) while providing a slow fallback path (e.g. generic arithmetic). It mostly benefits dynamic object-oriented languages - Ruby, Python, Smalltalk etc. - because all their method calls can get promoted to "native" JVM method calls instead of being implemented in user code. In dynamic functional languages like Lisp dialects, method resolution is not a problem - there's a single method, apply (simplifying things a bit). invokedynamic can help with *class* resolution instead: now in Clojure or Common Lisp every function call which is not inlined must pass through the symbol (or Var in Clojure) - e.g. functionNameSymbol.getFunction().apply(...). This is hard to optimize because the actual class implementing the function is not known to the JVM. With indy that pattern can become simply: invokedynamic "functionName" args - and the Lisp system can resolve the function only once (at least until it is redefined). I.e. the JVM will translate that instruction to: invoke TheClassImplementingTheFunction.apply(theFunctionInstance, ...args). This should make function calls more optimized. Advanced uses of invokedynamic - while complex - can implement things like runtime type-based optimizations as well; but I don't know if that's worth the effort for Lisps. And perhaps there are other or alternative uses of invokedynamic that I haven't considered, please share your ideas! Peace, Alessio -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: JVM 7 support (invokedynamic)
Right invokedynamic doesn't just "mostly benefit object-oriented languages." A MethodHandle can be used for anything that the JVM can do from a static method call, to an instance method call, to a constructor, to a field access. And in fact the bootstrap method that links an invokedynamic call site does not have to dispatch on the type of the first argument in an object oriented way, it can actually do completely generic dispatch akin to Clojure's multimethods. You can take a MethodHandle and curry the method by supplying some of the arguments, and this nice little packaged MethodHandle is given to the JVM with complete transparency for it to do it's stuff. You can create collector and spreader methods to do things like RestFn does where it takes rest args. You could probably even do destructuring of arguments in a chain of MethodHandles that the JVM then could understand and optimize. Maybe not all that potential is fully delivered with the current release of Java 7, but I think the transparency that invokedynamic allows should make it much easier for the JVM to do better optimizations. Paul -- 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: I/O
This gives several I/O examples: http://nakkaya.com/2010/06/15/clojure-io-cookbook/ -- 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: JVM 7 support (invokedynamic)
A significant speed improvement without resorting to type hints would be a pretty huge win from a programmer's standpoint. Kenny On Thu, Aug 25, 2011 at 1:21 PM, Nick Zbinden wrote: > @Aaron: Could you go into why this is the case? What does jruby do > that it needs it so much and clojure does not. > > @Tal Liron: You seem to differ in your opinion with Aaron (pretty sure > you would not be investing your time otherwise). What exactlly are you > attempting to speed up and how does invokedynamic 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
Re: Why can't I print new sequence?
On Thu, Aug 25, 2011 at 7:53 AM, octopusgrabbus wrote: > Ken: > > Thanks for the answer. You're welcome. > You're correct about distinct. I'm working through some exercises. Ah. Always good to get to know the language better. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- 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: Making clojure.lang.IDeref a protocol
On Thu, Aug 25, 2011 at 11:40 AM, Stuart Halloway wrote: >> Has there been discussion about making clojure.lang.IDeref a protocol? > > Someday. The challenge is load order. A lot would have to change to make > protocols available early enough in Clojure's bootstrap to allow this. Thinking outside of the box, what about exposing a low level ability to define a Java interface separately somewhere, then erect the rest of the machinery of a protocol around it later? Then IDeref can be just an interface early in bootstrap, but be protocolized late in bootstrap and available in protocol form thereafter. (This could also be applicable to potentially-more-useful interfaces like IFn, ISeq, and Associative, too.) -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- 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
D3 JavaScript data visualization in ClojureScript
We've been experimenting with ClojureScript and D3, a JavaScript DOM-
manipulation with an emphasis on data visualization, and we just put
our work on the Github:
https://github.com/lynaghk/cljs-d3/
Basically, this is a façade that proxies the native D3 JavaScript
functions so that you don't have to constantly use dot and dot-dot
interop macros.
We've also added some syntactic sugar to D3 so you can pass maps to
(attr) and (style);
(-> selection
(attr {:width 10 :height 20
:color #(if (< % 1) "red" "blue")}))
and other functions get a more Clojure-esque api:
(scales/linear :domain [0 1] :range [0 Width])
The official site is here:
http://keminglabs/cljs-d3/
We're switching to ClojureScript from CoffeeScript/JS for all of our
new interface/dataviz work, so we'll be adding a lot to this project
over the next few months.
We've submitted a talk proposal for the Conj:
http://keminglabs/d3.clj/
but in the mean time we are happy to chat with anyone about our
experiences wrapping a JS library for ClojureScript and data
visualization with Clojure in general.
best,
Kevin
Keming Labs
--
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: Lein uberjar hangs when swank is required in the namespace.
It's hanging here too, but I have no idea why; I'm not including swank. Is there any "verbose mode" for lein? -- 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: JVM 7 support (invokedynamic)
So, after setting up a JVM 7 environment to play with Clojure, and enthusiastically rummaging through the codebase, I have good news and bad news. :) (To quickly answer someone's question here -- I do know that it's a low priority for the Clojure project, but thought the potential benefit could be worth *my* personal time. A few people suggested that invokedynamic would not be that useful for Clojure, but I'm a skeptic and wanted to see for myself. I think other questions posed here are answered in the long report below...) The bad news is that I don't think Clojure can benefit from JVM 7's invokedynamic. The good news is that it is unnecessary, because Clojure's compiler is already efficient, and entirely bypasses all the pesky problems other dynamic JVM languages have, for which invokedynamic was introduced. (I work a lot with Rhino, JRuby, Jython, Groovy and Quercus (a JVM PHP engine), and can anecdotally say that Clojure and Quercus are "fastest" of their breed for the kind of web development work I do.) The thing is that Clojure's compiler is itself very Clojure-like, in that it treats functions as a first-class data type, just like maps, sequences, vars, etc. In the runtime, all of these data types share common interfaces, such as ISeq, IVar and -- you guessed it -- IFn. This situation is very unlike many non-Lisp languages, in which functions are often methods bound to classes, modules, interfaces, etc., all that heavy internal structure that Lisps implement in Lisp. So, when Clojure calls a function, it either already has the instance in its entirety (a lambda) or it finds it by dereferencing a binding. Since all functions are instances that implement IFn, the implementation can then call invokeinterface, which is very efficient. [See clojure.lang.Compiler#InvokeExpr.emitArgsAndCall] Clojure can get away with this especially easily because the only variant for function signatures in Clojure is arity. So, all we need is a simple switch to call the IFn method with the correct arity. (Interestingly, this means that Clojure has a fixed set of such signatures, and thus a fixed upper limit to arity: 20, in case you were wondering.) In a language like Ruby, methods are not so free floating, and have much more complex invocation styles as well as flexible signatures. (Clojure has only one style: function calls are simple forms.) So, in order to use invokeinterface, JRuby implementors would have had to create special classes *per* method *per* invocation style if they wanted to be efficient. But this is impossible, because so many classes would exhaust the perm-gen. For those languages, invokedynamic is a terrific solution, because it lets them dynamically link the implementation to the caller via a flexible "bootstrapping" mechanism, allowing them to do entirely without the extra class definition. Since all Clojure functions share essentially the same class as well as interface, none of these challenges exist. Another aspect is the immutability of these IFn instances: you can't refactor them at runtime, all you can do is change the bindings to refer to new functions. So, Clojure achieves runtime dynamics by letting you simply rebind new functions to existing Vars, Refs, Atoms, etc., and the same invocation route continues as usual. In a language like Ruby, the bootstrapping mechanism of invokedynamic lets implementors change the base linkage to reflect a new signature for the method. Again, a terrific JVM 7 feature that Clojure simply does not need. Another issue I examined was how Clojure calls non-Clojure JVM code, thinking that perhaps there invokedynamic would be useful. But, Clojure again has a straightforward approach that poses no problems. Here, Clojure very directly calls non-Clojure code using invokestatic, invokevirtual or invokeinterface as appropriate. A Clojure form with the "." or ".." notations translates quite directly to a JVM method call. In fact, there's no significant difference between how Clojure compiles such code and how a Java compiler (such as javac) would compile such code. Clojure, too, explicitly handles boxing and unboxing of primitive types and other conveniences. Where Clojure slightly differs is in how it picks the correct method to call (it does method reflection, but only once during the compilation phase), and its coercion of types to match the called method -- after all, its type system is dynamic. [See clojure.lang.Compiler#InstanceMethodExpr, StaticMethodExpr, etc.] Again, this is different from an implementation like JRuby, in which the design decision was that non-Ruby code would live in Ruby "as if" it were Ruby code, supporting that Ruby invocation styles. This makes such calls compile like calls to other Ruby functions, and thus represents the same challenges mentioned above. One thought about this: Actually, this is a place where Clojure *could* be more like JRuby, and allow for tighter int
Re: JVM 7 support (invokedynamic)
> > Since Ruby isn't designed to run on the JVM, it doesn't have > any syntax for type hints to avoid reflective calls. I believe method > calls that use invokedynamic are much faster than reflective > (non-hinted) method calls, but still a bit slower than type-hinted > calls. So if you are in a tight loop you'll need to type hint anyway. > I just want to point out that Lisp wasn't designed for the JVM, either, and the JVM presents a few particular challenges for it, too, for example when it comes to special kinds of recursion. invokedynamic actually isn't faster than reflection per se, if you are able to store the reflection method points in a structure to use for later. Actually, if you play with invokedynamic (it's not easy) on the current iteration of the officially released Oracle JDK, you will find that invokedynamic is a bit slower than calling reflected methods! I understand that this was fixed in trunk, and the next release of JDK 7 will have invokedynamic be faster. -- 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: I/O
> I think part of the reason for > this is the conception (maybe misconception) that most people are > familiar with java and since there is java interopt they should be > able to figure this out. As more and more schools are starting to use > Python as their beginning CS language, this may well not be the case > soon. It could also be that if you need to learn Java you'll pick-up a Java book. There is indeed little to say about slurp and spit. -- 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: JVM 7 support (invokedynamic)
> A significant speed improvement without resorting to type hints would be a > pretty huge win from a programmer's standpoint. True, but this is not a problem that invokedynamic can solve. :) It would require, perhaps, better automation in the decision of how to coerce types when calling Java methods. But, I'm not really sure this can be improved upon without hints: moving from a dynamic ally-typed language to a statically-typed language means you would always have to fill in that gap somehow. -Tal -- 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: JVM 7 support (invokedynamic)
> Hmm... If you didn't have to worry about Java <7 compatibility, for one > thing with invokedynamic you could remove a lot of code from Clojure. No > more IFn or AFn. You simply have a method handle. > Actually, Clojure's solution is almost identical to a method handle. An instance of AFn is not much different from an instance of MethodHandle, from the JVM's standpoint. The problem MethodHandle solves for languages like JRuby is that they need *different classes* for each method handling, whereas Clojure gets away with instances. Where using MethodHandle becomes important is when you want to participate in the invokedynamic bootstrapping, which expects MethodHandle instances. If Clojure ever needs to do this, it would be a simple one-to-one translation from AFn. > Second, I think it would allow the JVM to have a better view into > optimization, and would allow the JVM to optimize something speculatively > and allow for Clojure tell the JVM when to deoptimize with a SwitchPoints > and MutableCallSites. > Except that there's no functional mutability in Clojure! I tried hard, but I could not come up with a case in which this could be used. What are you thinking of, specifically? > I don't think Phil's comparison is actually a fair one. If you're going to > use type hints or type inference, then you're basically moving more towards > static typing, which of course will be faster. > See my comments on the issue in my longer report: Clojure does use standard JVM invocations with static typing. In fact, it has no choice. :) It's also pretty smart about coercing types to the what the JVM method expects, and of course there is hinting to help it out. -- 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: D3 JavaScript data visualization in ClojureScript
Very cool! I was actually implemented a little visualization lib
inspired by D3 directly in cljs. I'll clean it up and push it to
http://github.com/ibdknox/pinot tonight.
D3 is awesome, so I'm excited to see stuff like this. :)
Cheers,
Chris.
On Aug 25, 4:42 pm, Kevin Lynagh wrote:
> We've been experimenting with ClojureScript and D3, a JavaScript DOM-
> manipulation with an emphasis on data visualization, and we just put
> our work on the Github:
>
> https://github.com/lynaghk/cljs-d3/
>
> Basically, this is a façade that proxies the native D3 JavaScript
> functions so that you don't have to constantly use dot and dot-dot
> interop macros.
> We've also added some syntactic sugar to D3 so you can pass maps to
> (attr) and (style);
>
> (-> selection
> (attr {:width 10 :height 20
> :color #(if (< % 1) "red" "blue")}))
>
> and other functions get a more Clojure-esque api:
>
> (scales/linear :domain [0 1] :range [0 Width])
>
> The official site is here:
>
> http://keminglabs/cljs-d3/
>
> We're switching to ClojureScript from CoffeeScript/JS for all of our
> new interface/dataviz work, so we'll be adding a lot to this project
> over the next few months.
>
> We've submitted a talk proposal for the Conj:
>
> http://keminglabs/d3.clj/
>
> but in the mean time we are happy to chat with anyone about our
> experiences wrapping a JS library for ClojureScript and data
> visualization with Clojure in general.
>
> best,
>
> Kevin
> Keming Labs
--
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: I/O
On Aug 25, 2011, at 2:00 PM, Terje Dahl wrote: > Great question. And great answer. > Seriously! I did not know it could be that easy. Unfortunately it's not actually that easy, at least for the OP's question of reading from and writing to (presumably local) files. While slurp and spit are beautifully elegant it's not so elegant to tell slurp how to find the file you want it to slurp. In many other languages/environments there's a concept of the working directory or project directory, relative to which you can specify locations. In Clojure you have to deal with the classpath, outside of the language proper, and many of the common ways of running Clojure programs handle this differently. I don't know if there's a good, general solution to this, but for me (both as a programmer and especially as a teacher) it is definitely a pain point. In my current configuration (in Mac OS X running clooj -- which is really shaping up beautifully, BTW) spit with a simple file name seems to go to my Downloads directory. I don't know why or how to change it. Much worse is the problem with interactive console-based I/O, which is often one of the things that a beginner will often want to play with to get the feel of a language; many of my students try to write a simple text adventure game for their first projects, and with Clojure I basically have to tell them to forget about it. (If you don't know what I'm talking about see the exchanges here: http://groups.google.com/group/clojure/browse_thread/thread/9261480fbea72ead/4ec300e9cc76a184?lnk=raot). There are ways to make console-based I/O work , but it fails in ugly ways in many setups. -Lee -- 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: D3 JavaScript data visualization in ClojureScript
Rad!
I used Compojure last time I did web development in Clojure, but since
I've been picking up ClojureScript I've also been using Pinot + Noir---
nice job on those guys. If you're going to the Conj, you'll have to
track me down so I can buy you a drink.
kevin
On Aug 25, 3:44 pm, Chris Granger wrote:
> Very cool! I was actually implemented a little visualization lib
> inspired by D3 directly in cljs. I'll clean it up and push it
> tohttp://github.com/ibdknox/pinottonight.
>
> D3 is awesome, so I'm excited to see stuff like this. :)
>
> Cheers,
> Chris.
>
> On Aug 25, 4:42 pm, Kevin Lynagh wrote:
>
> > We've been experimenting with ClojureScript and D3, a JavaScript DOM-
> > manipulation with an emphasis on data visualization, and we just put
> > our work on the Github:
>
> > https://github.com/lynaghk/cljs-d3/
>
> > Basically, this is a façade that proxies the native D3 JavaScript
> > functions so that you don't have to constantly use dot and dot-dot
> > interop macros.
> > We've also added some syntactic sugar to D3 so you can pass maps to
> > (attr) and (style);
>
> > (-> selection
> > (attr {:width 10 :height 20
> > :color #(if (< % 1) "red" "blue")}))
>
> > and other functions get a more Clojure-esque api:
>
> > (scales/linear :domain [0 1] :range [0 Width])
>
> > The official site is here:
>
> > http://keminglabs/cljs-d3/
>
> > We're switching to ClojureScript from CoffeeScript/JS for all of our
> > new interface/dataviz work, so we'll be adding a lot to this project
> > over the next few months.
>
> > We've submitted a talk proposal for the Conj:
>
> > http://keminglabs/d3.clj/
>
> > but in the mean time we are happy to chat with anyone about our
> > experiences wrapping a JS library for ClojureScript and data
> > visualization with Clojure in general.
>
> > best,
>
> > Kevin
> > Keming Labs
>
>
--
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: I/O
Note that most of those examples look a little dated and would benefit from a heapin' helpin' of clojure.java.io and friends. For instance, slurp is quite happy to read from a java.net.URL so fetch-url is unnecessary. Unfortunately slurp is a little under documented. Dave On Thursday, August 25, 2011, Walter van der Laan < waltervanderl...@gmail.com> wrote: > This gives several I/O examples: > http://nakkaya.com/2010/06/15/clojure-io-cookbook/ > > -- > 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 < clojure%2bunsubscr...@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: I/O
On Thu, Aug 25, 2011 at 6:49 PM, Lee Spector wrote: > While slurp and spit are beautifully elegant it's not so elegant to tell > slurp how to find the file you want it to slurp. In many other > languages/environments there's a concept of the working directory or project > directory, relative to which you can specify locations. In Clojure you have > to deal with the classpath, outside of the language proper, and many of the > common ways of running Clojure programs handle this differently. I don't know > if there's a good, general solution to this, but for me (both as a programmer > and especially as a teacher) it is definitely a pain point. What about (System/getProperty "user.dir")? -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- 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: Making clojure.lang.IDeref a protocol
> That said, I don't know many Java classes that have value-yielding semantics. > And if you are writing your own class, you can implement the IDeref interface. There aren't many value-yielding semantics from many java classes, but the ones I care about, do matter. Also, in my case, I'm adding value- yielding semantics to classes that didn't originally have such things. I'm not writing my own new java class. If I were writing something that I wanted to extend to an interface, making types with defrecord and deftype do that nicely for me. -- 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: I/O
On Aug 25, 2011, at 9:27 PM, Ken Wesson wrote: > On Thu, Aug 25, 2011 at 6:49 PM, Lee Spector wrote: >> While slurp and spit are beautifully elegant it's not so elegant to tell >> slurp how to find the file you want it to slurp. In many other >> languages/environments there's a concept of the working directory or project >> directory, relative to which you can specify locations. In Clojure you have >> to deal with the classpath, outside of the language proper, and many of the >> common ways of running Clojure programs handle this differently. I don't >> know if there's a good, general solution to this, but for me (both as a >> programmer and especially as a teacher) it is definitely a pain point. > > What about (System/getProperty "user.dir")? The value of user.dir depends on how the code is run. Now that I check I see that if I run a lein repl in a project directory then it is set to that directory, which is great. But if I run the code in some other way it may be set to something different. For example, in clooj currently it's set to my Downloads directory. I'll write to the clooj list to see if this can be changed, but I also had problems with this sort of thing in Eclipse/Counterclockwise and I'm wondering: Is it specified somewhere that this should always be set to the project directory? If I run a lein repl from a non-project directory then it's set to my home directory, which makes some sense I guess, but why not the directory from which the repl was launched? FWIW my larger point was just that all of this is less clear than it is in many other languages, and that simple file I/O is therefore less simple than one might hope. Thanks, -Lee -- 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: I/O
On Thu, Aug 25, 2011 at 11:19 PM, Lee Spector wrote: > > On Aug 25, 2011, at 9:27 PM, Ken Wesson wrote: > >> On Thu, Aug 25, 2011 at 6:49 PM, Lee Spector wrote: >>> While slurp and spit are beautifully elegant it's not so elegant to tell >>> slurp how to find the file you want it to slurp. In many other >>> languages/environments there's a concept of the working directory or >>> project directory, relative to which you can specify locations. In Clojure >>> you have to deal with the classpath, outside of the language proper, and >>> many of the common ways of running Clojure programs handle this >>> differently. I don't know if there's a good, general solution to this, but >>> for me (both as a programmer and especially as a teacher) it is definitely >>> a pain point. >> >> What about (System/getProperty "user.dir")? > > The value of user.dir depends on how the code is run. Now that I check I see > that if I run a lein repl in a project directory then it is set to that > directory, which is great. But if I run the code in some other way it may be > set to something different. For example, in clooj currently it's set to my > Downloads directory. I'll write to the clooj list to see if this can be > changed, but I also had problems with this sort of thing in > Eclipse/Counterclockwise and I'm wondering: Is it specified somewhere that > this should always be set to the project directory? If I run a lein repl from > a non-project directory then it's set to my home directory, which makes some > sense I guess, but why not the directory from which the repl was launched? > > FWIW my larger point was just that all of this is less clear than it is in > many other languages, and that simple file I/O is therefore less simple than > one might hope. "user.dir" is the directory from which the JVM was launched, i.e. the initial working directory of the process. So, you're probably double-clicking the Clooj jar which resides in your Downloads folder and thus all further file system operations will be relative to that. For whatever reason it was decided long ago that the JVM wouldn't support the ability to change the current working directory like in most other environments. When you're working on a pure GUI app or server app, it usually doesn't matter, but when you've got a REPL it becomes a bit of a headache. Maybe someone could write a startup script for Clooj that first cds to the project folder before running "java -jar clooj.jar"? Alternatively, Clooj could maintain it's own working directory and override all the file-related ops (maybe??), but that will almost certainly lead to confusion as soon as someone uses a raw (FileInputStream.) and finds that the working directory isn't what they expected. Dave -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
