Re: [ANN] Public Early Access Program for Cursive, the IntelliJ-based Clojure IDE
Oh thanx, didn't see it up there. I guess there are million things you have in mind for this IDE, but speaking of REPL, I think that starting a REPL should not be a project level feature, but be exposed as one type of Run Configurations since its classpath (and maybe some other settings) can vary accross project's modules, or even module's profiles, so its good to have few REPL configurations. Of course, one can argue that this has to be developed with Leiningen support in mind, since it has profiles and subprojects (via lein-sub), so maybe this isn't trivially to design... Anyway, good work. -Vjeran On Tuesday, October 8, 2013 11:10:33 PM UTC+2, Colin Fleming wrote: Hi Vjeran, Thanks! I'm glad you're liking it. The namespace in the current REPL is displayed at the top of the window, in the REPL tab name. Cheers, Colin On 9 October 2013 07:52, vmar...@gmail.com javascript: wrote: Congratulations! EAP looks promising - its already much better than La Clojure. I don't know if this is intentionally done so, or is it some problem with Windows or whatever, but local nREPL session doesn't display current namespace which is very helpful of course. I had to use *ns* occasionaly to recall where I am. Anyway, great work. -Vjeran -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Cut down uberjar size
Thanks, Maik, I'll try to tune my uberjar using this option! вторник, 8 октября 2013 г., 23:11:32 UTC+3 пользователь Maik Schünemann написал: You can use a regex to exclude files from uberjars, see the leiningen sample file and the :uberjar-exclusions key ;; Files with names matching any of these patterns will be excluded from jars. :jar-exclusions [#(?:^|/).svn/] ;; Same thing, but for uberjars. :uberjar-exclusions [#META-INF/DUMMY.SF] hope that helps On Tue, Oct 8, 2013 at 5:56 AM, Ruslan Prokopchuk fer@gmail.comjavascript: wrote: What are the best practices to cut down uberjar size? Is it able to automagically :exclude from project unused parts dependencies of big libraries, and will it affect on uberjar size? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Grenchman, for running Clojure code quickly
How does this vary from flatland/drip? -Zack On Tuesday, October 8, 2013 9:49:16 PM UTC-5, Phil Hagelberg wrote: When we've polled Leiningen users in the past[1], the #1 pain point people always report is its startup time. While there have been a number of strategies suggested to reduce the annoyance of slow JVM startup time and project loading, keeping your JVMs around can lead to awkward workflows in some situations given the tooling we've had so far. To this end I'm happy to announce the release of Grenchman, a tool for executing Clojure code in a running process *quickly*: http://leiningen.org/grench.html With Grenchman you can launch an nREPL server in the background (typically with `lein trampoline repl :headless`, but you can also embed an nREPL server in a production setting) and then connect to it directly From the command-line with minimal overhead: $ time grench eval '(println Hello, world!)' Hello, world! real0m0.117s user0m0.024s sys 0m0.024s This opens up a number of new command-line-centric workflows. You can also invoke Leiningen tasks from Grenchman if you launch a separate out-of-project `lein repl :headless` server: $ time grench lein version Leiningen 2.3.3 on Java 1.6.0_27 OpenJDK 64-Bit Server VM real0m0.118s user0m0.032s sys 0m0.020s Finally, Grenchman includes its own interactive nREPL client using GNU Readline: $ grench repl user= (System/getProperty user.dir) /home/phil/src/syme [...] Plans for the next version[3] include completion in the repl client and support for repl history and multi-line form input. While it is a very young project, the non-interactive functionality is quite stable. Please give Grenchman a try if this sounds interesting to you. The install process is the same as Leiningen where you download and chmod an executable, except that there is a different executable for different platforms; I have precompiled binaries for several common platforms at the link above and will post user-contributed builds for other platforms I don't have access to if there is demand. thanks, Phil [1] - https://lein-survey-2013.herokuapp.com/results and https://lein-survey-2012.herokuapp.com/results [2] - https://github.com/technomancy/leiningen/wiki/Faster [3] - https://github.com/technomancy/grenchman/issues?milestone=2state=open [4] - Grenchman was inspired to a degree by Jark (http://icylisper.github.io/jark/) but does not share any code with it. [5] - Timings above are taken from my 4½-year-old laptop; newer hardware would perform 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Fwd: ▶ Datomic: up and running - YouTube
Another very nice and useful screencast by James Trunk. Everything become easy to understand when he explains it. mimmo https://www.youtube.com/watch?v=ao7xEwCjrWQ -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Regarding http://clojuredocs.org
On Tue, 8 Oct 2013 21:55:08 -0700 Andy Fingerhut andy.finger...@gmail.com wrote: Those who created ClojureDocs.org made some progress towards rewriting the server side code in Clojure (it was originally developed in Ruby on Rails, IIRC), but have found it challenging to find enough time to finish that work. I recall a month or two ago someone mentioning that they would be interested in finishing that work and updating the site, I think in a message on this group. There was also a Clojure Cup entry which was doing a ClojureDocs alternative, but no idea how far they got. regards, Marek -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Teaching Clojure to students (how ?)
Nando Breiter na...@aria-media.com writes: To me, this begins to look more like a user interface issue than strictly a programming issue. The folks who do interface design have a technique - pretend it's magic. What would the solution look like if it was magic ( setting all programming considerations aside for the moment) ? This is, indeed, the case. When teaching programming to new programmers the minimum of pain points is an important consideration. At the moment, clojure is quite hard to get going with. Of course, Java is a total pain to get going with also (hello new programmer, this is an IDE -- just ignore most of it), so this isn't the only consideration. The student installs something ... opens something ... and something just works. How would you flesh that out? Someone else installs something for the student. A persistant REPL would be nice (although, of course, as most evaluative programmers restart periodically to avoid a balked environment, it might introduce problems as well). A nice simple environment is key, but with a good path to more complex functionality, as they become familiar the environment. I'd love to have an IDE with a newbie mode which took away all the nonsense, and then slowly turned it on with a here's a new feature dialog. Guess that's not going to happen any time soon! 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Teaching Clojure to students (how ?)
2013/10/9 Phillip Lord phillip.l...@newcastle.ac.uk Nando Breiter na...@aria-media.com writes: To me, this begins to look more like a user interface issue than strictly a programming issue. The folks who do interface design have a technique - pretend it's magic. What would the solution look like if it was magic ( setting all programming considerations aside for the moment) ? This is, indeed, the case. When teaching programming to new programmers the minimum of pain points is an important consideration. At the moment, clojure is quite hard to get going with. Of course, Java is a total pain to get going with also (hello new programmer, this is an IDE -- just ignore most of it), so this isn't the only consideration. The student installs something ... opens something ... and something just works. How would you flesh that out? Someone else installs something for the student. A persistant REPL would be nice (although, of course, as most evaluative programmers restart periodically to avoid a balked environment, it might introduce problems as well). A nice simple environment is key, but with a good path to more complex functionality, as they become familiar the environment. I'd love to have an IDE with a newbie mode which took away all the nonsense, and then slowly turned it on with a here's a new feature dialog. Guess that's not going to happen any time soon! A web based simplified development environment, but directly connected to github underneath, and with a never stopped VM for each student (can be snapshotted, though). When time comes to know better, switch to the editor/IDE of your choice and get all things back from the github repo (but the persistent VM). ? 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
The best explanation of these misunderstandings I've come across is What to Know Before Debating Type Systems: http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ I have learned quite a lot from reading this article and following this discussion, particularly that type and type checking is much more nuanced and complex than I have understood until now, and that the terms static and dynamic expand into a much larger range of issues upon close examination, such as the difference between explicitly declaring types (as in Java) and implicitly inferring types from code context. Quoting from the article: *Many programmers approach the question of whether they prefer static or dynamic types by comparing some languages they know that use both techniques. This is a reasonable approach to most questions of preference. The problem, in this case, is that most programmers have limited experience, and haven’t tried a lot of languages. For context, here, six or seven doesn't count as “a lot.”* * * So I can say I prefer dynamic typing, but the reasons are more personal, and molded by my development experience. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
let's see... really used: sql java javascript basic pascal/delphi scala experimented with: logo (some old language intended to teach people to make their first steps) haskell kotlin clojure seen in action: php groovy still prefer smart static typing :D 2013/10/9 Nando Breiter na...@aria-media.com The best explanation of these misunderstandings I've come across is What to Know Before Debating Type Systems: http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ I have learned quite a lot from reading this article and following this discussion, particularly that type and type checking is much more nuanced and complex than I have understood until now, and that the terms static and dynamic expand into a much larger range of issues upon close examination, such as the difference between explicitly declaring types (as in Java) and implicitly inferring types from code context. Quoting from the article: *Many programmers approach the question of whether they prefer static or dynamic types by comparing some languages they know that use both techniques. This is a reasonable approach to most questions of preference. The problem, in this case, is that most programmers have limited experience, and haven’t tried a lot of languages. For context, here, six or seven doesn't count as “a lot.”* * * So I can say I prefer dynamic typing, but the reasons are more personal, and molded by my development experience. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Teaching Clojure to students (how ?)
John Gabriele jmg3...@gmail.com writes: Thanks Phil! Didn't know you could do that! Wrote up some notes on getting it working: http://www.unexpected-vortices.com/blog/2013/scripts-in-clojure.html That's useful! 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
Let's see: strong data typing: Fortran Cobol Pl/1 Pascal C/C++ Java C# Ruby à la carte data typing or no data typing at all: Basic (more or less depending on the implementation) Lisp Clojure A dozen assemblers A dozen scripting languages And I probably forgot some while excluding the ones I worked with (Algol, Simula, GPSS, ...) in academic projects. I used the above ones on real projects at work and not small projects. Lets keep SQL out of the picture, it's an exaggeration to call this a programming language. Still prefer less data typing or no typing at all :) Luc P. let's see... really used: sql java javascript basic pascal/delphi scala experimented with: logo (some old language intended to teach people to make their first steps) haskell kotlin clojure seen in action: php groovy still prefer smart static typing :D 2013/10/9 Nando Breiter na...@aria-media.com The best explanation of these misunderstandings I've come across is What to Know Before Debating Type Systems: http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ I have learned quite a lot from reading this article and following this discussion, particularly that type and type checking is much more nuanced and complex than I have understood until now, and that the terms static and dynamic expand into a much larger range of issues upon close examination, such as the difference between explicitly declaring types (as in Java) and implicitly inferring types from code context. Quoting from the article: *Many programmers approach the question of whether they prefer static or dynamic types by comparing some languages they know that use both techniques. This is a reasonable approach to most questions of preference. The problem, in this case, is that most programmers have limited experience, and haven’t tried a lot of languages. For context, here, six or seven doesn't count as “a lot.”* * * So I can say I prefer dynamic typing, but the reasons are more personal, and molded by my development experience. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
especially haskell scala are missing in your list :) as long as you haven't at least seen haskell, you haven't seen the creme de la creme of statically typed languages 2013/10/9 Softaddicts lprefonta...@softaddicts.ca Let's see: strong data typing: Fortran Cobol Pl/1 Pascal C/C++ Java C# Ruby à la carte data typing or no data typing at all: Basic (more or less depending on the implementation) Lisp Clojure A dozen assemblers A dozen scripting languages And I probably forgot some while excluding the ones I worked with (Algol, Simula, GPSS, ...) in academic projects. I used the above ones on real projects at work and not small projects. Lets keep SQL out of the picture, it's an exaggeration to call this a programming language. Still prefer less data typing or no typing at all :) Luc P. let's see... really used: sql java javascript basic pascal/delphi scala experimented with: logo (some old language intended to teach people to make their first steps) haskell kotlin clojure seen in action: php groovy still prefer smart static typing :D 2013/10/9 Nando Breiter na...@aria-media.com The best explanation of these misunderstandings I've come across is What to Know Before Debating Type Systems: http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ I have learned quite a lot from reading this article and following this discussion, particularly that type and type checking is much more nuanced and complex than I have understood until now, and that the terms static and dynamic expand into a much larger range of issues upon close examination, such as the difference between explicitly declaring types (as in Java) and implicitly inferring types from code context. Quoting from the article: *Many programmers approach the question of whether they prefer static or dynamic types by comparing some languages they know that use both techniques. This is a reasonable approach to most questions of preference. The problem, in this case, is that most programmers have limited experience, and haven’t tried a lot of languages. For context, here, six or seven doesn't count as “a lot.”* * * So I can say I prefer dynamic typing, but the reasons are more personal, and molded by my development experience. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_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
Re: How to go about 'proving' why dynamically typed languages are better.
And JavaScript is missing (OK, a dozen scripting language) But today, JavaScript is very important in the picture. Even Clojure has ClojureScript On Wed, Oct 9, 2013 at 8:36 AM, Dennis Haupt d.haup...@gmail.com wrote: especially haskell scala are missing in your list :) as long as you haven't at least seen haskell, you haven't seen the creme de la creme of statically typed languages 2013/10/9 Softaddicts lprefonta...@softaddicts.ca Let's see: strong data typing: Fortran Cobol Pl/1 Pascal C/C++ Java C# Ruby à la carte data typing or no data typing at all: Basic (more or less depending on the implementation) Lisp Clojure A dozen assemblers A dozen scripting languages And I probably forgot some while excluding the ones I worked with (Algol, Simula, GPSS, ...) in academic projects. I used the above ones on real projects at work and not small projects. Lets keep SQL out of the picture, it's an exaggeration to call this a programming language. Still prefer less data typing or no typing at all :) Luc P. let's see... really used: sql java javascript basic pascal/delphi scala experimented with: logo (some old language intended to teach people to make their first steps) haskell kotlin clojure seen in action: php groovy still prefer smart static typing :D 2013/10/9 Nando Breiter na...@aria-media.com The best explanation of these misunderstandings I've come across is What to Know Before Debating Type Systems: http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ I have learned quite a lot from reading this article and following this discussion, particularly that type and type checking is much more nuanced and complex than I have understood until now, and that the terms static and dynamic expand into a much larger range of issues upon close examination, such as the difference between explicitly declaring types (as in Java) and implicitly inferring types from code context. Quoting from the article: *Many programmers approach the question of whether they prefer static or dynamic types by comparing some languages they know that use both techniques. This is a reasonable approach to most questions of preference. The problem, in this case, is that most programmers have limited experience, and haven’t tried a lot of languages. For context, here, six or seven doesn't count as “a lot.”* * * So I can say I prefer dynamic typing, but the reasons are more personal, and molded by my development experience. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to
Re: Teaching Clojure to students (how ?)
Laurent PETIT laurent.pe...@gmail.com writes: 2013/10/9 Phillip Lord phillip.l...@newcastle.ac.uk A persistant REPL would be nice (although, of course, as most evaluative programmers restart periodically to avoid a balked environment, it might introduce problems as well). A nice simple environment is key, but with a good path to more complex functionality, as they become familiar the environment. I'd love to have an IDE with a newbie mode which took away all the nonsense, and then slowly turned it on with a here's a new feature dialog. Guess that's not going to happen any time soon! A web based simplified development environment, but directly connected to github underneath, and with a never stopped VM for each student (can be snapshotted, though). When time comes to know better, switch to the editor/IDE of your choice and get all things back from the github repo (but the persistent VM). Yeah, that's a nice idea. Wouldn't be too hard to get it to work. 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Teaching Clojure to students (how ?)
Thanks for all the feedback. I had already made sure that LightTable is already installed, and the plug-in for eclipse (that they already use). But I don't expect too much trouble on this front as they are already somewhat proficient (with even some converts to the church of Emacs ☺). Cheers, B. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
That's what I said earlier, I need to find some type to dive into it. As far as Scala is concerned, it's not on my list of items to learn. Too Java-ish to me and clunky. It's not because you mix all the latest features in a single language that the result is a significant landmark. It took a significant amount if time to Haskell designers to think about feature set, it's not the same caliber at all. Before choosing Clojure for our product, I looked at it and rejected it and still have no regrets doing so. Java in it's future releases will follow on the same slippery road of feature aggregation w/o coherency, the let's please everyone approach never led to anything exceptional. It makes only things more confusing thanks to these guys... http://search.dilbert.com/search?p=Rsrid=S3-USESD01lbc=dilbertw=marketing%20ideaurl=http%3a%2f%2fdilbert.com%2fstrips%2fcomic%2f1999-02-06%2frk=7uid=203834662sid=2ts=customrsc=YmDLFs%3as9q%3aosTfUmethod=andisort=dateview=listfilter=type%3acomic Luc P. especially haskell scala are missing in your list :) as long as you haven't at least seen haskell, you haven't seen the creme de la creme of statically typed languages 2013/10/9 Softaddicts lprefonta...@softaddicts.ca Let's see: strong data typing: Fortran Cobol Pl/1 Pascal C/C++ Java C# Ruby à la carte data typing or no data typing at all: Basic (more or less depending on the implementation) Lisp Clojure A dozen assemblers A dozen scripting languages And I probably forgot some while excluding the ones I worked with (Algol, Simula, GPSS, ...) in academic projects. I used the above ones on real projects at work and not small projects. Lets keep SQL out of the picture, it's an exaggeration to call this a programming language. Still prefer less data typing or no typing at all :) Luc P. let's see... really used: sql java javascript basic pascal/delphi scala experimented with: logo (some old language intended to teach people to make their first steps) haskell kotlin clojure seen in action: php groovy still prefer smart static typing :D 2013/10/9 Nando Breiter na...@aria-media.com The best explanation of these misunderstandings I've come across is What to Know Before Debating Type Systems: http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ I have learned quite a lot from reading this article and following this discussion, particularly that type and type checking is much more nuanced and complex than I have understood until now, and that the terms static and dynamic expand into a much larger range of issues upon close examination, such as the difference between explicitly declaring types (as in Java) and implicitly inferring types from code context. Quoting from the article: *Many programmers approach the question of whether they prefer static or dynamic types by comparing some languages they know that use both techniques. This is a reasonable approach to most questions of preference. The problem, in this case, is that most programmers have limited experience, and haven’t tried a lot of languages. For context, here, six or seven doesn't count as “a lot.”* * * So I can say I prefer dynamic typing, but the reasons are more personal, and molded by my development experience. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit
Re: How to go about 'proving' why dynamically typed languages are better.
Yeah but I hate JavaScript so no wonder it's not on the list. I do however code in ClojureScript and avoid JS interop like the plague as much as possible :) I had to deal too much with browser based GUIs before things like JQuery and similar things came to life or because the back end framework did not allow me to use something more brilliant than plain JS... it got me disgusted pretty much. ClojureScript has changed my approach to browser based apps but w/o JS as much as possible, now I can conceal my app logic in the browser while using the back end as a resource provider. No more Dr Jekyll and Mr Hide syndrom... Luc P. And JavaScript is missing (OK, a dozen scripting language) But today, JavaScript is very important in the picture. Even Clojure has ClojureScript On Wed, Oct 9, 2013 at 8:36 AM, Dennis Haupt d.haup...@gmail.com wrote: especially haskell scala are missing in your list :) as long as you haven't at least seen haskell, you haven't seen the creme de la creme of statically typed languages 2013/10/9 Softaddicts lprefonta...@softaddicts.ca Let's see: strong data typing: Fortran Cobol Pl/1 Pascal C/C++ Java C# Ruby à la carte data typing or no data typing at all: Basic (more or less depending on the implementation) Lisp Clojure A dozen assemblers A dozen scripting languages And I probably forgot some while excluding the ones I worked with (Algol, Simula, GPSS, ...) in academic projects. I used the above ones on real projects at work and not small projects. Lets keep SQL out of the picture, it's an exaggeration to call this a programming language. Still prefer less data typing or no typing at all :) Luc P. let's see... really used: sql java javascript basic pascal/delphi scala experimented with: logo (some old language intended to teach people to make their first steps) haskell kotlin clojure seen in action: php groovy still prefer smart static typing :D 2013/10/9 Nando Breiter na...@aria-media.com The best explanation of these misunderstandings I've come across is What to Know Before Debating Type Systems: http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ I have learned quite a lot from reading this article and following this discussion, particularly that type and type checking is much more nuanced and complex than I have understood until now, and that the terms static and dynamic expand into a much larger range of issues upon close examination, such as the difference between explicitly declaring types (as in Java) and implicitly inferring types from code context. Quoting from the article: *Many programmers approach the question of whether they prefer static or dynamic types by comparing some languages they know that use both techniques. This is a reasonable approach to most questions of preference. The problem, in this case, is that most programmers have limited experience, and haven’t tried a lot of languages. For context, here, six or seven doesn't count as “a lot.”* * * So I can say I prefer dynamic typing, but the reasons are more personal, and molded by my development experience. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: GSoC Report: CinC, port of the clojure compiler in clojure
Nicola Mometto brobro...@gmail.com writes: I don't think that's what Mike was talking about. Say we have (defn x ^long [] 1), clojure will use the IFn$L and emit an public long invokePrim() method. When we do (defn y [] (let [a (x)] a) the compiler will call .invokePrim instead of invoke. If we redefine (defn x [] ) then y won't work because the new version of x doesn't implement IFn$L, we'd need to recompile y too. Actually I am talking about the same problem. For virtual calls the JIT compiler can determine that only one implementation of the method is being used, inline the call and perform object explosion, effectively removing boxing of primitives. When new implementation becomes available it dynamically recompiles affected bytecode. I don't know if the current implementation does this for invokedynamic calls, but there is a potential. It just does not feel right to invent a whole new complex optimization layer on the Clojure side until we fully use the optimization capabilities of the JVM. -- Mikhail pgpKVfcWvSsNF.pgp Description: PGP signature
How to type hint a String array?
Clojure provide built-in type hint for primitive types such as: ^ints, ^doubles, but how to type hint an array of arbitrary Class? The following way dosn't work, too: user= (definterface MyInterface #_= (^[Ljava.lang.String method1 [])) user.MyInterface user= (.method1 (reify MyInterface (^[Ljava.lang.String; method1 [this] ))) CompilerException java.lang.NoClassDefFoundError: [Ljava/lang/String, compiling:(NO_SOURCE_PATH:1:11) 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
Oh! I don't hate JavaScript ;-) I'm not a Clojure programmer, (and not a ClojureScript programmer). But I usually program in C#, Java, PHP and JavaScript. I know Lisp, Ruby and Python, but I don't work with them, only toy projects. I found JavaScript the most flexible programming language (less ceremony than Ruby or Python), and combined with Node.js at server, browsers at client, JSON for messaging, and TDD, it shines! Any quirk on JS language is easy to circumvent (ie. using module pattern, build and exercised with TDD), and IMO, it pays a lot to use it. Angel Java Lopez @ajlopez On Wed, Oct 9, 2013 at 9:26 AM, Softaddicts lprefonta...@softaddicts.cawrote: Yeah but I hate JavaScript so no wonder it's not on the list. I do however code in ClojureScript and avoid JS interop like the plague as much as possible :) I had to deal too much with browser based GUIs before things like JQuery and similar things came to life or because the back end framework did not allow me to use something more brilliant than plain JS... it got me disgusted pretty much. ClojureScript has changed my approach to browser based apps but w/o JS as much as possible, now I can conceal my app logic in the browser while using the back end as a resource provider. No more Dr Jekyll and Mr Hide syndrom... Luc P. And JavaScript is missing (OK, a dozen scripting language) But today, JavaScript is very important in the picture. Even Clojure has ClojureScript On Wed, Oct 9, 2013 at 8:36 AM, Dennis Haupt d.haup...@gmail.com wrote: especially haskell scala are missing in your list :) as long as you haven't at least seen haskell, you haven't seen the creme de la creme of statically typed languages 2013/10/9 Softaddicts lprefonta...@softaddicts.ca Let's see: strong data typing: Fortran Cobol Pl/1 Pascal C/C++ Java C# Ruby à la carte data typing or no data typing at all: Basic (more or less depending on the implementation) Lisp Clojure A dozen assemblers A dozen scripting languages And I probably forgot some while excluding the ones I worked with (Algol, Simula, GPSS, ...) in academic projects. I used the above ones on real projects at work and not small projects. Lets keep SQL out of the picture, it's an exaggeration to call this a programming language. Still prefer less data typing or no typing at all :) Luc P. let's see... really used: sql java javascript basic pascal/delphi scala experimented with: logo (some old language intended to teach people to make their first steps) haskell kotlin clojure seen in action: php groovy still prefer smart static typing :D 2013/10/9 Nando Breiter na...@aria-media.com The best explanation of these misunderstandings I've come across is What to Know Before Debating Type Systems: http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ I have learned quite a lot from reading this article and following this discussion, particularly that type and type checking is much more nuanced and complex than I have understood until now, and that the terms static and dynamic expand into a much larger range of issues upon close examination, such as the difference between explicitly declaring types (as in Java) and implicitly inferring types from code context. Quoting from the article: *Many programmers approach the question of whether they prefer static or dynamic types by comparing some languages they know that use both techniques. This is a reasonable approach to most questions of preference. The problem, in this case, is that most programmers have limited experience, and haven’t tried a lot of languages. For context, here, six or seven doesn't count as “a lot.”* * * So I can say I prefer dynamic typing, but the reasons are more personal, and molded by my development experience. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out -- -- You received this message
Re: How to type hint a String array?
From the 1.3 docs: ;; Currently Clojure does not permit type hints of arrays, e.g. ^ints as ;; argument types or return types in a definterface. This may be enhanced ;; later. Jim ps: also, non-primitive arrays are hinted like this if I'm not mistaken: #^[Ljava.lang.String; On 09/10/13 13:55, Qiu Xiafei wrote: Clojure provide built-in type hint for primitive types such as: ^ints, ^doubles, but how to type hint an array of arbitrary Class? The following way dosn't work, too: user= (definterface MyInterface #_= (^[Ljava.lang.String method1 [])) user.MyInterface user= (.method1 (reify MyInterface (^[Ljava.lang.String; method1 [this] ))) CompilerException java.lang.NoClassDefFoundError: [Ljava/lang/String, compiling:(NO_SOURCE_PATH:1:11) 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
I hate quirks, too many things to achieve, less time remaining, less brain estate to remember quirks :) Luc P. Oh! I don't hate JavaScript ;-) I'm not a Clojure programmer, (and not a ClojureScript programmer). But I usually program in C#, Java, PHP and JavaScript. I know Lisp, Ruby and Python, but I don't work with them, only toy projects. I found JavaScript the most flexible programming language (less ceremony than Ruby or Python), and combined with Node.js at server, browsers at client, JSON for messaging, and TDD, it shines! Any quirk on JS language is easy to circumvent (ie. using module pattern, build and exercised with TDD), and IMO, it pays a lot to use it. Angel Java Lopez @ajlopez On Wed, Oct 9, 2013 at 9:26 AM, Softaddicts lprefonta...@softaddicts.cawrote: Yeah but I hate JavaScript so no wonder it's not on the list. I do however code in ClojureScript and avoid JS interop like the plague as much as possible :) I had to deal too much with browser based GUIs before things like JQuery and similar things came to life or because the back end framework did not allow me to use something more brilliant than plain JS... it got me disgusted pretty much. ClojureScript has changed my approach to browser based apps but w/o JS as much as possible, now I can conceal my app logic in the browser while using the back end as a resource provider. No more Dr Jekyll and Mr Hide syndrom... Luc P. And JavaScript is missing (OK, a dozen scripting language) But today, JavaScript is very important in the picture. Even Clojure has ClojureScript On Wed, Oct 9, 2013 at 8:36 AM, Dennis Haupt d.haup...@gmail.com wrote: especially haskell scala are missing in your list :) as long as you haven't at least seen haskell, you haven't seen the creme de la creme of statically typed languages 2013/10/9 Softaddicts lprefonta...@softaddicts.ca Let's see: strong data typing: Fortran Cobol Pl/1 Pascal C/C++ Java C# Ruby à la carte data typing or no data typing at all: Basic (more or less depending on the implementation) Lisp Clojure A dozen assemblers A dozen scripting languages And I probably forgot some while excluding the ones I worked with (Algol, Simula, GPSS, ...) in academic projects. I used the above ones on real projects at work and not small projects. Lets keep SQL out of the picture, it's an exaggeration to call this a programming language. Still prefer less data typing or no typing at all :) Luc P. let's see... really used: sql java javascript basic pascal/delphi scala experimented with: logo (some old language intended to teach people to make their first steps) haskell kotlin clojure seen in action: php groovy still prefer smart static typing :D 2013/10/9 Nando Breiter na...@aria-media.com The best explanation of these misunderstandings I've come across is What to Know Before Debating Type Systems: http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ I have learned quite a lot from reading this article and following this discussion, particularly that type and type checking is much more nuanced and complex than I have understood until now, and that the terms static and dynamic expand into a much larger range of issues upon close examination, such as the difference between explicitly declaring types (as in Java) and implicitly inferring types from code context. Quoting from the article: *Many programmers approach the question of whether they prefer static or dynamic types by comparing some languages they know that use both techniques. This is a reasonable approach to most questions of preference. The problem, in this case, is that most programmers have limited experience, and haven’t tried a lot of languages. For context, here, six or seven doesn't count as “a lot.”* * * So I can say I prefer dynamic typing, but the reasons are more personal, and molded by my development experience. -- -- 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
Re: How to type hint a String array?
On 09/10/13 14:12, Jim - FooBar(); wrote: ps: also, non-primitive arrays are hinted like this if I'm not mistaken: #^[Ljava.lang.String; actually you can use both #^ ^ in regular 'defn' Jim -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: GSoC Report: CinC, port of the clojure compiler in clojure
One of the problems with these sort of discussions is the total lack of hard facts. Words such as could do this or doesn't do that when referring to HotSpot are very rarely backed up by actual benchmarks, or ASM printouts. I would imagine that any serious attempt at an optimization layer will be prefixed by lots of research into where the current compiler fails, and what the proper enhancements should be. Timothy On Wed, Oct 9, 2013 at 6:29 AM, Mikhail Kryshen mikh...@kryshen.net wrote: Nicola Mometto brobro...@gmail.com writes: I don't think that's what Mike was talking about. Say we have (defn x ^long [] 1), clojure will use the IFn$L and emit an public long invokePrim() method. When we do (defn y [] (let [a (x)] a) the compiler will call .invokePrim instead of invoke. If we redefine (defn x [] ) then y won't work because the new version of x doesn't implement IFn$L, we'd need to recompile y too. Actually I am talking about the same problem. For virtual calls the JIT compiler can determine that only one implementation of the method is being used, inline the call and perform object explosion, effectively removing boxing of primitives. When new implementation becomes available it dynamically recompiles affected bytecode. I don't know if the current implementation does this for invokedynamic calls, but there is a potential. It just does not feel right to invent a whole new complex optimization layer on the Clojure side until we fully use the optimization capabilities of the JVM. -- Mikhail -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Grenchman, for running Clojure code quickly
On Wed, Oct 9, 2013 at 2:32 AM, Zack Maril thewitzb...@gmail.com wrote: How does this vary from flatland/drip? -Zack Grenchman connects to a JVM-with-nrepl you previously launched. Repeated invocations from the command line will hit that same JVM, potentially building up state over time, and Grenchman knows nothing of the JVM's lifecycle. Drip is a JVM pre-launcher, so every time you run drip (with the same classpath), you're running in a fresh JVM, with no state hanging around from previous invocations. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Type annonations in clojure.instant/print-date result in speedup of 3
Hi, I have a web service returning edn representations containing many java.util.Date values. Using a profiler, one Hot Spot is inside the clojure.instant/print-date function. The relevant reflections warnings are: Reflection warning, instant.cljhttps://github.com/clojure/clojure/blob/master/src/clj/clojure/instant.clj:172:20 - reference to field get can't be resolved. Reflection warning, instant.clj:174:15 - call to format can't be resolved. Reflection warning, instant.clj:174:5 - call to write can't be resolved. Adding a ^ThreadLocal annotation to thread-local-utc-date-format and a ^java.text.DateFormat to utc-format resolves all reflection warnings. I tested the speedup with (time (let [d (java.util.Date.)] (doseq [_ (range 10)] (pr-str d which takes about 1500 ms without the type annotations and about 500 ms with type annotations. A single web service access is speeded up from about 350 ms to 250 ms. The response contains about 3000 java.util.Date values. I could create a pull request if that would help. But I like to discuss the change first. I have no CA so I use Clojure instead of Clojure Dev. Alex -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Type annonations in clojure.instant/print-date result in speedup of 3
Could you take a look at the patch on ticket CLJ-1080 and see if it contains all of the improvements you mention? Let me know if it doesn't, and we can look at combining your improvements into that patch. http://dev.clojure.org/jira/browse/CLJ-1080 Andy On Wed, Oct 9, 2013 at 8:57 AM, Alexander Kiel alexanderk...@gmx.netwrote: Hi, I have a web service returning edn representations containing many java.util.Date values. Using a profiler, one Hot Spot is inside the clojure.instant/print-date function. The relevant reflections warnings are: Reflection warning, instant.cljhttps://github.com/clojure/clojure/blob/master/src/clj/clojure/instant.clj:172:20 - reference to field get can't be resolved. Reflection warning, instant.clj:174:15 - call to format can't be resolved. Reflection warning, instant.clj:174:5 - call to write can't be resolved. Adding a ^ThreadLocal annotation to thread-local-utc-date-format and a ^java.text.DateFormat to utc-format resolves all reflection warnings. I tested the speedup with (time (let [d (java.util.Date.)] (doseq [_ (range 10)] (pr-str d which takes about 1500 ms without the type annotations and about 500 ms with type annotations. A single web service access is speeded up from about 350 ms to 250 ms. The response contains about 3000 java.util.Date values. I could create a pull request if that would help. But I like to discuss the change first. I have no CA so I use Clojure instead of Clojure Dev. Alex -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
London Clojure opportunities
I hold my hands up immediately and make it clear I am a recruiter! Please before you automatically assume I am a typical recruiter and block me from any correspondence ever take a look at my linkedin profile! I am engaged on a search for Clojure and Clojurescript developers for central London and I am keen to speak to London based (or those willing to be based in London) Clojure developers. You do not need to have developed commercially in Clojure previously, but if you haven't you should have a code repository full to the brim with Clojure code. Regardless if the opportunity is not right for you, I am always keen to speak to Clojure developers. I work almost exclusively in the Clojure market and I am always interested to learn more about Clojurians! Dave david.shroder@nicollcurtin,com 0207 397 0195 -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Go block and call back functions
Hello I'm wondering where the call back function will run in a go block. For example, if I use http-kit asynchronous mode, I will register a call back function. If I call http/get within a goroutine, will the callback run in the same goroutine or an arbitrary thread? Also, since goroutine can't be blocked, I'm wondering what kinds of tasks are good to do in goroutine. http-kit sounds ok since it's non-blocking, but how about mongodb, redis operations etc. Thanks Gary -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Type annonations in clojure.instant/print-date result in speedup of 3
Hi Andy, http://dev.clojure.org/jira/browse/CLJ-1080 has not the same type hints as I propose. You can see my patch here: https://github.com/alexanderkiel/clojure/compare/instant-type-hints I have an additional type hint at thread-local-utc-date-format and I use java.text.DateFormat instead of java.text.SimpleDateFormat at utc-format. Alex Am Mittwoch, 9. Oktober 2013 18:49:32 UTC+2 schrieb Andy Fingerhut: Could you take a look at the patch on ticket CLJ-1080 and see if it contains all of the improvements you mention? Let me know if it doesn't, and we can look at combining your improvements into that patch. http://dev.clojure.org/jira/browse/CLJ-1080 Andy On Wed, Oct 9, 2013 at 8:57 AM, Alexander Kiel alexan...@gmx.netjavascript: wrote: Hi, I have a web service returning edn representations containing many java.util.Date values. Using a profiler, one Hot Spot is inside the clojure.instant/print-date function. The relevant reflections warnings are: Reflection warning, instant.cljhttps://github.com/clojure/clojure/blob/master/src/clj/clojure/instant.clj:172:20 - reference to field get can't be resolved. Reflection warning, instant.clj:174:15 - call to format can't be resolved. Reflection warning, instant.clj:174:5 - call to write can't be resolved. Adding a ^ThreadLocal annotation to thread-local-utc-date-format and a ^java.text.DateFormat to utc-format resolves all reflection warnings. I tested the speedup with (time (let [d (java.util.Date.)] (doseq [_ (range 10)] (pr-str d which takes about 1500 ms without the type annotations and about 500 ms with type annotations. A single web service access is speeded up from about 350 ms to 250 ms. The response contains about 3000 java.util.Date values. I could create a pull request if that would help. But I like to discuss the change first. I have no CA so I use Clojure instead of Clojure Dev. Alex -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ▶ Datomic: up and running - YouTube
Thanks for the nice complement mimmo! When I created the screencast I announced it in the Datomic group, but I didn't think to do it here too. Though because I introduce the database via a TDD Clojure project, hopefully it's relevant (and useful) for folks here as well. Cheers, James On Wednesday, October 9, 2013 9:56:17 AM UTC+2, Magomimmo wrote: Another very nice and useful screencast by James Trunk. Everything become easy to understand when he explains it. mimmo https://www.youtube.com/watch?v=ao7xEwCjrWQ -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Teaching Clojure to students (how ?)
Another very useful getting started plugin is lein-try:
https://github.com/rkneufeld/lein-try
Then you can do stuff like:
lein try [quil 1.6.0]
;; taken from the quil getting started wiki:
(use 'quil.core)
(sketch :setup (fn [] (background 20) (ellipse 50 50 80 80)) :title
The moon delights the night)
and you're off to the races without even needing a project created or
worrying about editing dependencies.
Sean
On Mon, Oct 7, 2013 at 8:12 PM, John Gabriele jmg3...@gmail.com wrote:
On Monday, October 7, 2013 4:28:57 AM UTC-4, Phillip Lord wrote:
Lee Spector lspe...@hampshire.edu writes:
Also IMHO (just trying to deflect some flames here) the Clojure
ecosystem currently lacks the ideal environment for this.
Tend to agree with this also. As nice as leiningen is, Clojure seems to
inherit from Java bulky projects. Compare these two hello worlds:
(println hello world)
to
#!/usr/bin/python
print( hello world )
Both equivalently simple, up and till the point you actually try to run
them. The best I came up with is...
java -jar ~/.m2/repository/org/clojure/clojure/1.5.1/clojure-1.5.1.jar
hello_world.clj
which, of course, depends on me having installed leiningen and used it.
For new users who want to get their feet wet right on the first day, I'd
suggest this (after they make sure they've got Java installed):
#. Download `lein`, drop it into your ~/bin, and `chmod +x` it if
necessary,
#. `lein version` (so it installs and thus creates ~/.lein directory (see
next step))
#. `touch ~/.lein/profiles.clj`, and into that file put `{:user {:plugins
[[lein-exec 0.3.1]]}}` (or whatever the current version of [lein-exec] is
when you're reading this. :) )
[lein-exec]: https://github.com/kumarshantanu/lein-exec
Now you can create your hello world about as simply as with P{erl,ython}:
#. create a ~/wherever/foo.clj file,
#. into it goes `(println hi)`, then
#. run it in the prescribed way: `lein exec foo.clj`.
-- John
--
--
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 unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: boolean java interopt puzzle/bug?!
Thanks for the help and clarifications. My problem is that I'm working on a tool, as a part of my thesis, to randomly execute annotated java classes to try discover its behavior. So if a class has a (b|B)oolean field and I read its value using reflection it returns (using Field.get()) a Boolean that for clojure will be always false. In order to solve this issue I created the follow fn: (defn- get-val [^java.lang.reflect.Field f instance] (let [value (.get f instance)] (if (instance? java.lang.Boolean value) (boolean value) value))) Thanks and regards, -- Bauna On 10/06/2013 10:57 PM, Andy Fingerhut wrote: There is also this page on ClojureDocs that might shed some light on this quirk: http://clojuredocs.org/clojure_core/clojure.core/if On Sun, Oct 6, 2013 at 6:14 PM, Rob Browning r...@defaultvalue.org wrote: Gary Trakhman gary.trakh...@gmail.com writes: Clojure's false and true are Boolean/FALSE and Boolean/TRUE, and for speed reasons (I think) anything that checks for truthiness uses java's ==, which will fail on any new Boolean object. Usually, this isn't a problem, but sometimes it is. You can see that this assumption is pervasive by looking at the implementations of 'true?' and 'false?', which use identical? and the check for != Boolean.FALSE in https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L2569 ...and further, my understanding is that the Boolean constructors are more or less considered a mistake, and you should effectively never use them. For example: http://rayfd.me/2007/01/17/the-evil-boolean-constructors/ Hope this helps -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to
Re: [ANN] Show the latest version of the library on your Github README page
Thank you for this! What could be done to make the text highlightable/copyable? On Tuesday, October 8, 2013 6:25:07 AM UTC-7, Alexander Yakushev wrote: Have you ever felt annoyed to update the README after you released a new version of your project? Have your users ever struggled to make the older version work because you forgot to update that README? Suffer no more, because Clojars has just the right medicine for you. From now on, you can append */latest-version.svg* to your artefact's link, which will resolve to an image that shows the latest version of your project. Then you can embed this image in your README, or Wiki, or wherever else you like. A couple examples: https://clojars.org/leiningen/latest-version.svg https://clojars.org/com.palletops/pallet-cli/latest-version.svg The only downside of using this feature is that the user can't just select and copy the dependency line anymore. Although Webkit-based browsers support text selection in SVGs (and Firefox's support for one is on the way) it works only when opening the single image, but not when the image is embedded into the page. But I hope it can be worked around somehow in future. Thanks to Nelson Morris and Phil Hagelberg for pushing this 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Show the latest version of the library on your Github README page
The inability to select the text in SVG comes from img tag limitations. The following two ways of embedding SVG image into the webpage allows selecting text in both Webkit browsers and Firefox (in the latter via double-clicking and then right-click-Copy): object data=https://clojars.org/leiningen/latest-version.svg; type=image/svg+xml/object embed src=https://clojars.org/leiningen/latest-version.svg; type=image/svg+xml / Unfortunately, Github supports neither of them in its READMEs/wikis. So it can be used only when you have direct access to page's HTML, for instance on your own website or Github Pages. Perhaps the inclusion of embed on Github might be lobbied someday, but I'm afraid not in the foreseeable future. On Wednesday, October 9, 2013 11:47:37 PM UTC+2, Christopher Allen wrote: Thank you for this! What could be done to make the text highlightable/copyable? On Tuesday, October 8, 2013 6:25:07 AM UTC-7, Alexander Yakushev wrote: Have you ever felt annoyed to update the README after you released a new version of your project? Have your users ever struggled to make the older version work because you forgot to update that README? Suffer no more, because Clojars has just the right medicine for you. From now on, you can append */latest-version.svg* to your artefact's link, which will resolve to an image that shows the latest version of your project. Then you can embed this image in your README, or Wiki, or wherever else you like. A couple examples: https://clojars.org/leiningen/latest-version.svg https://clojars.org/com.palletops/pallet-cli/latest-version.svg The only downside of using this feature is that the user can't just select and copy the dependency line anymore. Although Webkit-based browsers support text selection in SVGs (and Firefox's support for one is on the way) it works only when opening the single image, but not when the image is embedded into the page. But I hope it can be worked around somehow in future. Thanks to Nelson Morris and Phil Hagelberg for pushing this 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Teaching Clojure to students (how ?)
Show interactive programing with the REPL. For example implementing a data transformation function incrementally in the REPL. By starting with an example of input. And successively bringing it closer to the final output. (Threading macros work great for that). I showed it to a few java developers who knew only TDD (or worst `public static void main`). Most of them were very impressed On Oct 6, 2013 12:01 AM, bernardH un.compte.pour.tes...@gmail.com wrote: Hi all, I intend to (ab)use my authority as a teacher to enlighten unsuspecting students about Clojure. On the plus side, I may give them insights that they did not even know they needed. On the minus side, I cannot expect (all of) them to be curious about Clojure. Hence, I want to make a demand driven introduction. My goal is to : 1. identify what novelties Clojure brings to the table to Java developers - homoiconicity : macros - syntaxing sugar (e.g -, cond) - programming paradigms as libraries - core.logic - core.async - dynamic typing - simple concurrency handling : - immutable data structures - ref - atoms - STM - open-ended dynamic dispatching (protocols, namespaced vs. monkey patching) - multiple dispatching (multimethods) - maps instead of classes (no privacy accessors needed thx to dynamic typing and immutable data) and composable libraries instead of frameworks. 2. For as many of those features as possible, I'd like to find a minimal use case that will be : - genuinely interesting (so that they find it beliveable that they might actually want to solve a similar problem) - complex (if possible hard!) / tedious to solve in Java (I will provide the Java code) - simple (if possible easy) to solve in Clojure. The idea being that they would conclude from : 1. that the want to solve these problems 2. that Java won't help them much but Clojure would help them a lot (+ 1. 2.) → 3. They want to learn Clojure ! ☺ I'd be most grateful for any help, either to complete/amend my list in 1., or to provide ideas for 2. Best Regards, B. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to type hint a String array?
Thanks, Jim. On Wed, Oct 9, 2013 at 9:27 PM, Jim - FooBar(); jimpil1...@gmail.comwrote: On 09/10/13 14:12, Jim - FooBar(); wrote: ps: also, non-primitive arrays are hinted like this if I'm not mistaken: #^[Ljava.lang.String; actually you can use both #^ ^ in regular 'defn' Jim -- -- 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+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: GSoC Report: CinC, port of the clojure compiler in clojure
On Wednesday, 9 October 2013 20:29:46 UTC+8, Mikhail Kryshen wrote:
Nicola Mometto brob...@gmail.com javascript: writes:
I don't think that's what Mike was talking about.
Say we have (defn x ^long [] 1), clojure will use the IFn$L and emit an
public long invokePrim() method.
When we do (defn y [] (let [a (x)] a) the compiler will call .invokePrim
instead of invoke.
If we redefine (defn x [] ) then y won't work because the new version
of x doesn't implement IFn$L, we'd need to recompile y too.
Actually I am talking about the same problem. For virtual calls the JIT
compiler can determine that only one implementation of the method is
being used, inline the call and perform object explosion, effectively
removing boxing of primitives. When new implementation becomes
available it dynamically recompiles affected bytecode. I don't know if
the current implementation does this for invokedynamic calls, but there
is a potential. It just does not feel right to invent a whole new
complex optimization layer on the Clojure side until we fully use the
optimization capabilities of the JVM.
The JVM is certainly amazing at optimising virtual calls (to be expected
since that's the usual calling convention for majority of Java OOP code)
Clojure currently doesn't use virtual calls for functions however: that's
part of the problem here. It pretty much always emits invokeinterface calls
(via IFn and IFn's primitive variants). invokeinterface is slower than
invokevirtual in many cases. They can certainly perform the same in cases
where the JIT can eliminate the possibility of multiple implementations,
but that's probably not going to be the case for IFn :-)
So part of making Clojure faster / making the most of the JVM should
probably involve finding ways to use invokevirtual (or invokespecial)
instead of invokeinterface where possible.
P.S. in the name of having some real performance data and to reassure
myself that my knowledge of JVM behaviour is roughly correct, I made a
quick caliper microbenchmark in Java to demonstrate the difference between
interface and virtual dispatch:
0% Scenario{vm=java, trial=0, benchmark=Interface} 13.04 ns; σ=0.19 ns @
10 trials
50% Scenario{vm=java, trial=0, benchmark=Virtual} 7.39 ns; σ=0.26 ns @ 10
trials
benchmarkns linear runtime
Interface 13.04 ==
Virtual 7.39 =
vm: java
trial: 0
Test code here for those interested:
https://github.com/mikera/vectorz/blob/develop/src/test/java/mikera/vectorz/performance/InterfaceVsVirtualBenchmark.java
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Public Early Access Program for Cursive, the IntelliJ-based Clojure IDE
Yeah, that's on my list to do very shortly - it'll make starting debug REPLs much easier, too, as well as allowing saved configurations for various remote servers. Cheers, Colin On 9 October 2013 19:13, vmarci...@gmail.com wrote: Oh thanx, didn't see it up there. I guess there are million things you have in mind for this IDE, but speaking of REPL, I think that starting a REPL should not be a project level feature, but be exposed as one type of Run Configurations since its classpath (and maybe some other settings) can vary accross project's modules, or even module's profiles, so its good to have few REPL configurations. Of course, one can argue that this has to be developed with Leiningen support in mind, since it has profiles and subprojects (via lein-sub), so maybe this isn't trivially to design... Anyway, good work. -Vjeran On Tuesday, October 8, 2013 11:10:33 PM UTC+2, Colin Fleming wrote: Hi Vjeran, Thanks! I'm glad you're liking it. The namespace in the current REPL is displayed at the top of the window, in the REPL tab name. Cheers, Colin On 9 October 2013 07:52, vmar...@gmail.com wrote: Congratulations! EAP looks promising - its already much better than La Clojure. I don't know if this is intentionally done so, or is it some problem with Windows or whatever, but local nREPL session doesn't display current namespace which is very helpful of course. I had to use *ns* occasionaly to recall where I am. Anyway, great work. -Vjeran -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: GSoC Report: CinC, port of the clojure compiler in clojure
Good point Timothy - 100% agreed on the value of hard facts / benchmarks. Though I think it's still useful to have some discussions first, in order to determine where to start / what to benchmark / where the problems are likely to be hiding. Good research should start with an understanding of the relevant issues, some hypotheses to test and a sensible experimental design - ideally before you start collecting too much data. Also we shouldn't underestimate the value of sharing the wisdom and intuition gained from many years of optimising code on the JVM, which I'm sure many people around here can contribute :-) On Wednesday, 9 October 2013 21:39:33 UTC+8, tbc++ wrote: One of the problems with these sort of discussions is the total lack of hard facts. Words such as could do this or doesn't do that when referring to HotSpot are very rarely backed up by actual benchmarks, or ASM printouts. I would imagine that any serious attempt at an optimization layer will be prefixed by lots of research into where the current compiler fails, and what the proper enhancements should be. Timothy On Wed, Oct 9, 2013 at 6:29 AM, Mikhail Kryshen mik...@kryshen.netjavascript: wrote: Nicola Mometto brob...@gmail.com javascript: writes: I don't think that's what Mike was talking about. Say we have (defn x ^long [] 1), clojure will use the IFn$L and emit an public long invokePrim() method. When we do (defn y [] (let [a (x)] a) the compiler will call .invokePrim instead of invoke. If we redefine (defn x [] ) then y won't work because the new version of x doesn't implement IFn$L, we'd need to recompile y too. Actually I am talking about the same problem. For virtual calls the JIT compiler can determine that only one implementation of the method is being used, inline the call and perform object explosion, effectively removing boxing of primitives. When new implementation becomes available it dynamically recompiles affected bytecode. I don't know if the current implementation does this for invokedynamic calls, but there is a potential. It just does not feel right to invent a whole new complex optimization layer on the Clojure side until we fully use the optimization capabilities of the JVM. -- Mikhail -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Regarding http://clojuredocs.org
On Tue, Oct 8, 2013 at 9:55 PM, Bruce Wang br...@brucewang.net wrote: The official docs is at http://clojure.org/documentation, http://clojure.github.io/clojure/ Sure, but the nice thing about clojuredocs is that it includes examples for most of the functions and for a while, it was updated more frequently than the regular documentation site. For example, I noticed the other day that in the main documentation site, in the java interop section, there isn't much discussion about the possibility of annotating functions of up to four arguments with primitive types. The fib example still shows the old way of handling primitives. Where is one to learn these details? Similarly, I noticed that the only documentation about reducers is still a link to the original blog posts which outline the idea, but are by no means thorough. It would be great to get back to having an active documentation repository for community contributions. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Regarding http://clojuredocs.org
On Thu, Oct 10, 2013 at 1:44 PM, Mark Engelberg mark.engelb...@gmail.comwrote: On Tue, Oct 8, 2013 at 9:55 PM, Bruce Wang br...@brucewang.net wrote: The official docs is at http://clojure.org/documentation, http://clojure.github.io/clojure/ Sure, but the nice thing about clojuredocs is that it includes examples for most of the functions and for a while, it was updated more frequently than the regular documentation site. For example, I noticed the other day that in the main documentation site, in the java interop section, there isn't much discussion about the possibility of annotating functions of up to four arguments with primitive types. The fib example still shows the old way of handling primitives. Where is one to learn these details? Similarly, I noticed that the only documentation about reducers is still a link to the original blog posts which outline the idea, but are by no means thorough. It would be great to get back to having an active documentation repository for community contributions. Yep, you are right, I didn't realise The Clojure Cheatsheet[1] is actually pointing to clojuredocs.org [1] http://jafingerhut.github.io/cheatsheet-clj-1.3/cheatsheet-tiptip-cdocs-summary.html -- simple is good http://brucewang.net http://twitter.com/number5 -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Question about vector-of
(def a (conj (vector-of :long) 1 2 3) (inc (a 1)) Is Clojure smart enough to figure out that (a 1) is a primitive long and call the fast primitive version of inc? -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Regarding http://clojuredocs.org
For all but the few functions and macros added to Clojure since 1.3, ClojureDocs can be as actively maintained as people choose to update it. I add new facts that come to my attention there every so often, e.g.: http://clojuredocs.org/clojure_core/clojure.core/subs http://clojuredocs.org/clojure_core/clojure.core/read http://clojuredocs.org/clojure_core/clojure.core/sorted-set-by I'm not saying this is an ideal situation, but it isn't terrible, either. There is also clojure-doc.org which is updated quite often, although it has a different focus than ClojureDocs.org. The Clojure Cheatsheet pointing at clojuredocs.org was my choice. It didn't seem terribly useful to have the links point at the Autodoc-generated documentation, because I am pretty sure those are not much more than the doc strings, which are available much more quickly in the cheat sheet pop-up tool tips. Andy On Wed, Oct 9, 2013 at 9:21 PM, Bruce Wang br...@brucewang.net wrote: On Thu, Oct 10, 2013 at 1:44 PM, Mark Engelberg mark.engelb...@gmail.comwrote: On Tue, Oct 8, 2013 at 9:55 PM, Bruce Wang br...@brucewang.net wrote: The official docs is at http://clojure.org/documentation, http://clojure.github.io/clojure/ Sure, but the nice thing about clojuredocs is that it includes examples for most of the functions and for a while, it was updated more frequently than the regular documentation site. For example, I noticed the other day that in the main documentation site, in the java interop section, there isn't much discussion about the possibility of annotating functions of up to four arguments with primitive types. The fib example still shows the old way of handling primitives. Where is one to learn these details? Similarly, I noticed that the only documentation about reducers is still a link to the original blog posts which outline the idea, but are by no means thorough. It would be great to get back to having an active documentation repository for community contributions. Yep, you are right, I didn't realise The Clojure Cheatsheet[1] is actually pointing to clojuredocs.org [1] http://jafingerhut.github.io/cheatsheet-clj-1.3/cheatsheet-tiptip-cdocs-summary.html -- simple is good http://brucewang.net http://twitter.com/number5 -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Regarding http://clojuredocs.org
Sometimes, it's also useful to be able to take things out. I keep seeing people get confused by clojuredocs references to contrib libraries that have completely different names now. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Type annonations in clojure.instant/print-date result in speedup of 3
Thanks for checking, Alexander. I have created ticket CLJ-1277 with a patch that improves the performance of the case you found, as well as for java.sql.Timestamp printing that also had reflection in it nearly identical to what you found. http://dev.clojure.org/jira/browse/CLJ-1277 Feel free to create an account on JIRA and vote for it, if you want to help draw attention to it: http://dev.clojure.org/jira/secure/Signup!default.jspa You can also click the Watch link (after logging in) if you want to be emailed of updates to the ticket's status. I can make no promises on when or if that might happen. Andy On Wed, Oct 9, 2013 at 10:47 AM, Alexander Kiel alexanderk...@gmx.netwrote: Hi Andy, http://dev.clojure.org/jira/browse/CLJ-1080 has not the same type hints as I propose. You can see my patch here: https://github.com/alexanderkiel/clojure/compare/instant-type-hints I have an additional type hint at thread-local-utc-date-format and I use java.text.DateFormat instead of java.text.SimpleDateFormat at utc-format. Alex Am Mittwoch, 9. Oktober 2013 18:49:32 UTC+2 schrieb Andy Fingerhut: Could you take a look at the patch on ticket CLJ-1080 and see if it contains all of the improvements you mention? Let me know if it doesn't, and we can look at combining your improvements into that patch. http://dev.clojure.org/jira/**browse/CLJ-1080http://dev.clojure.org/jira/browse/CLJ-1080 Andy On Wed, Oct 9, 2013 at 8:57 AM, Alexander Kiel alexan...@gmx.net wrote: Hi, I have a web service returning edn representations containing many java.util.Date values. Using a profiler, one Hot Spot is inside the clojure.instant/print-date function. The relevant reflections warnings are: Reflection warning, instant.cljhttps://github.com/clojure/clojure/blob/master/src/clj/clojure/instant.clj:172:20 - reference to field get can't be resolved. Reflection warning, instant.clj:174:15 - call to format can't be resolved. Reflection warning, instant.clj:174:5 - call to write can't be resolved. Adding a ^ThreadLocal annotation to thread-local-utc-date-**format and a ^java.text.DateFormat to utc-format resolves all reflection warnings. I tested the speedup with (time (let [d (java.util.Date.)] (doseq [_ (range 10)] (pr-str d which takes about 1500 ms without the type annotations and about 500 ms with type annotations. A single web service access is speeded up from about 350 ms to 250 ms. The response contains about 3000 java.util.Date values. I could create a pull request if that would help. But I like to discuss the change first. I have no CA so I use Clojure instead of Clojure Dev. Alex -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@**googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
