Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help
On Friday, June 19, 2015 at 11:17:02 PM UTC+2, Christopher Small wrote: I see now Dragan; you're concerned not about whether easily implementing and swapping in/out implementations of core.matrix is possible, but whether it can be done while maintaining the performance characteristics of Neanderthal, yes? That did not come through in your earlier comments in this thread. This, with the addition that for *any* library, not only Neanderthal, there would be many leaking abstractions. It is easy to define common function/method names and parameters, but there are many things that just flow through the API regardless, and taming this is the hardest part of any API. Certainly, performance is one of those things that can leak in an abstraction. But I'd like to echo Matt's enquiry: If you think a unified API might be possible but that core.matrix isn't it, I think we'd all love to hear what you think it's missing and/or what would would need to be rearchitected in order for it to fit the bill. For an unified API, if it is at all feasible, I think there is one place it should be looked at first: BLAS 1, 2, 3 and LAPACK. This is THE de facto standard for matrix computations for dense and banded matrices. Sparse APIs are not that uniform, bat in that space, also, there is a lot of previous work. So, what's wrong with BLAS/LAPACK that core.matrix choose not to follow it and arbitrarily invent (in my opinion) unintuitive and complicated API? I am genuinely interested, maybe I don't see something that other people do. In my opinion, the best way to create a standard API is to grow it from successful implementations, instead of writing it first, and then shoehorning the implementations to fit it. As for any sort of responsibility to implement core.matrix, I don't think anyone is arguing you have such a responsibility, and I hope our _pleading_ hasn't come across as such. We are simply impressed with your work, and would like to take advantage of it, but also see a drawback you don't: at present Neanderthal is less interoperable with many existing tools, and trying it out on an existing project would require a rewrite (as would migrating away from it if we weren't happy). Certainly, a third party library implementing core.matrix with Neanderthal is a possibility, but I'm a bit worried that a) it would add extra burden keeping things in sync and feel a little second class; and more importantly b) it might be easier to maintain more of the performance benefits if it's directly integrating (I could imagine less indirection this way, but could be totally wrong). So let me ask you this: Assuming a) someone forks Neanderthal and makes a core.matrix implementation with close performance parity to the direct Neanderthal API and/or b) folks working on core.matrix are able to address some of your issues with the core.matrix architecture, would you consider a merge? a) I would rather see the core.matrix interoperability as an additional separate project first, and when/if it shows its value, and there is a person willing to maintain that part of the code, consider adding it to Neanderthal. I wouldn't see it as a second rate, and no fork is needed because of Clojure's extend-type/extend-protocol mechanism. b) I am not sure about what's exactly wrong with core.matrix. Maybe nothing is wrong. The first thing that I am interested in is what do core.matrix team think is wrong with BLAS/LAPACK in the first place to be able to form an opinion in that regard. Best Wishes, Dragan With gratitude Chris On Fri, Jun 19, 2015 at 1:45 PM, Matt Revelle mrev...@gmail.com javascript: wrote: On Friday, June 19, 2015 at 4:57:32 AM UTC-4, Dragan Djuric wrote: I do not even claim that an unified api is not possible. I think that to some extent it is. I just doubt in core.matrix eligibility for THE api in numerical computing. For it makes easy things easy and hard things impossible. Are you saying you don't believe core.matrix should be _the_ abstract API for matrices/arrays in Clojure? If so, what are your concerns? Feel free to point to me a previous post if it's already been stated. It also sounds like you're alluding to the thread in the Numerical Clojure group about a broad numerical computing lib for complex numbers and various math functions, but I'm not following how that matters here. -- 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 javascript: 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 a topic in the Google Groups Clojure group.
Re: breaking homoiconicity?
On Saturday, June 20, 2015 at 4:15:30 AM UTC+1, Sean Corfield wrote: (.getTypeName (Class/forName [Ljava.lang.String;)) ;;= java.lang.String[] — that is more readable! Thanks, that's helpful for me. By chance do you know if the class is natively recoverable from the TypeName for Clojure/Java? Class/forName can't roundtrip that string. I could implement a look-up table to translate between the two formats, but that seems rather kludgey. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help
It is difficult to say exactly, since the documentation is almost non-existent, which is especially bad for a standard API. Please see my answer to Christopher for more elaboration. On Friday, June 19, 2015 at 10:45:53 PM UTC+2, Matt Revelle wrote: On Friday, June 19, 2015 at 4:57:32 AM UTC-4, Dragan Djuric wrote: I do not even claim that an unified api is not possible. I think that to some extent it is. I just doubt in core.matrix eligibility for THE api in numerical computing. For it makes easy things easy and hard things impossible. Are you saying you don't believe core.matrix should be _the_ abstract API for matrices/arrays in Clojure? If so, what are your concerns? Feel free to point to me a previous post if it's already been stated. It also sounds like you're alluding to the thread in the Numerical Clojure group about a broad numerical computing lib for complex numbers and various math functions, but I'm not following how that matters here. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: let vs. let*
I don't think this is a let me google that for you question. Let vs let* in Clojure is not at all the same as the popular usages of these forms in popular lisp dialects like Common Lisp. I've thought it was confusing why let* existed in Clojure since let binding is only done in a sequential manner, but I think some answers given here are helpful. Just to point out Clojure dynamic var binding is done in a parallel/unordered way which resembles how Common Lisp let was done. However this is a completely different function and not a special form. Just for comparison with CL. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Creating jar specific defaults
Hi everyone, I want to specify some defaults for a library that I pack as a jar, for instance standard port a server. It should be read from a property file in the respective jar file automatically. However, when I include a jar in my class path, the file is not loaded from the included jar path but rather from the path of the parent application. What would be the best practice to specify jar specific constants. Should I define them in the source code? Thanks in advance! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: ring - setting no-cache for everything?
On Friday, June 19, 2015 at 12:14:10 PM UTC-4, Thomas Heller wrote: Cache-control is evil. Users concerned with seeing the most up-to-date information know to hit reload (and probably do anyway, just to be sure), and there's also the option of AJAX polling for that (or whatever precisely sites like Facebook do). I don't even a wrong Cache-Control will cause problems but Cache-Control is probably one of the most important headers to set for your webapp. It is also one of the harder ones to get right but the benefits are significant. As for preventing users from seeing stale CSS/Javascript I'd recommend serving files with a unique name which changes with each new release. Doing that will break bookmarks and deep links! Unless you keep all the old versions around, with ways to get to the newest for users who want to. It's almost always better to rely on the user knowing when to reload (to be sure they have the latest) and when to use the Wayback Machine (for when they specifically want to look at an old version). The latter also works much better if the URL for your page stays stable, so all of its versions are presented with a single timeline on that site. Do what you suggested with *just* the CSS/JS files, maybe, but do not do it with the page itself, or images or other stuff meant for the end user to see! Though then the user will still have stale scripts until they reload and get a new version of the page pointing to the new scripts. Which then means you need to update every HTML file on the site every time you change to a new version of some script, so that it now points to the new scripts ... which is another giant mess that suggests it's better to just keep all of them at stable URLs too and rely on the browser reload button DTRT by checking all assets for 304 Not Modified vs. shiny and new. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: [ANN] Clojure 1.7.0-RC2
Tested RC2 in a project with a lot of .cljc going on - seems to be working fine. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: ANN: org.clojure/tools.namespace 0.2.11
Thanks! Have been waiting for this. Working with .cljc-files is quite nice after these changes. :) On Friday, June 19, 2015 at 9:46:08 PM UTC+2, Stuart Sierra wrote: tools.namespace: parse namespace declarations and reload files in dependency order. https://github.com/clojure/tools.namespace Release 0.2.11 contains the following changes: * [TNS-34] Support for reader conditionals tools.namespace still works only in Clojure(JVM), not ClojureScript. But it is now able to parse both .clj files and .cljc source files containing reader conditionals. This release of tools.namespace remains backwards-compatible with older versions of Clojure back to 1.3.0. Leiningen dependency information: [org.clojure/tools.namespace 0.2.11] This is a Clojure-contrib project, http://dev.clojure.org/display/doc/Clojure+Contrib [TNS-34]: http://dev.clojure.org/jira/browse/TNS-34 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: Recur arg type problem
Ah, wrapping the initial `acc` val in `(num)` works... On 20 June 2015 at 15:05, Karsten Schmidt i...@toxi.co.uk wrote: I just encountered a problem with recur, I never came across before. Am trying to generate `coll-reduce` implementations over primitive nd-arrays and get bitten by special type restrictions on recur args if they're an initially primitive value (using 1.7.0-RC2): (loop [acc (aget ^bytes a 0) i 1] (if ( i 2) (recur (+ acc (aget ^bytes a i)) (inc i CompilerException java.lang.IllegalArgumentException: recur arg for primitive local: acc is not matching primitive, had: long, needed: byte Is there any way to avoid this compiler error, since I can't predict what type the reduction fn (`+` in the example) will return... Usually one wants of course as little boxing as possible, but here're I'd very much like to, but don't know how to do so with that initial `acc` val... -- Karsten Schmidt http://postspectacular.com | http://thi.ng | http://toxiclibs.org -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: breaking homoiconicity?
Thanks, that's helpful for me. By chance do you know if the class is natively recoverable from the TypeName for Clojure/Java? Class/forName can't roundtrip that string. I could implement a look-up table to translate between the two formats, but that seems rather kludgey. I actually just wrote a library for this sort of thing that works with any java.io.Serializable: https://bitbucket.org/morgon/jfreeze It's only meant to work with pr-dup (set the *print-dup* dynamic to true before printing), not necessarily the standard REPL printer, but generally if you're printing something you want to read back in you should be using pr-dup anyway. -- Morgon -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Recur arg type problem
I just encountered a problem with recur, I never came across before. Am trying to generate `coll-reduce` implementations over primitive nd-arrays and get bitten by special type restrictions on recur args if they're an initially primitive value (using 1.7.0-RC2): (loop [acc (aget ^bytes a 0) i 1] (if ( i 2) (recur (+ acc (aget ^bytes a i)) (inc i CompilerException java.lang.IllegalArgumentException: recur arg for primitive local: acc is not matching primitive, had: long, needed: byte Is there any way to avoid this compiler error, since I can't predict what type the reduction fn (`+` in the example) will return... Usually one wants of course as little boxing as possible, but here're I'd very much like to, but don't know how to do so with that initial `acc` val... -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: ring - setting no-cache for everything?
Sounds like your URLs could use some cache busting. :) Then you can add far future Expires headers, with no worries that users are seeing stale files. Optimus is one way to inject some front-end performance in your Ring-app. https://github.com/magnars/optimus On Friday, June 19, 2015 at 11:00:57 AM UTC+2, Colin Yates wrote: Hi all, is there a quick way to disable caching for everything or alternatively hash based on the contents of the resource. I am talking specifically about CSS and javascript issues served from the JAR's class path? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: ANN: org.clojure/tools.namespace 0.2.11
Btw, what's the point of maintaining compatibility with 1.3? According to the last state of Clojure survey pretty much no one uses 1.3 and 1.4 and the upgrade path to 1.5 is not exactly hard... On 20 June 2015 at 16:32, Magnar Sveen magn...@gmail.com wrote: Thanks! Have been waiting for this. Working with .cljc-files is quite nice after these changes. :) On Friday, June 19, 2015 at 9:46:08 PM UTC+2, Stuart Sierra wrote: tools.namespace: parse namespace declarations and reload files in dependency order. https://github.com/clojure/tools.namespace Release 0.2.11 contains the following changes: * [TNS-34] Support for reader conditionals tools.namespace still works only in Clojure(JVM), not ClojureScript. But it is now able to parse both .clj files and .cljc source files containing reader conditionals. This release of tools.namespace remains backwards-compatible with older versions of Clojure back to 1.3.0. Leiningen dependency information: [org.clojure/tools.namespace 0.2.11] This is a Clojure-contrib project, http://dev.clojure.org/display/doc/Clojure+Contrib [TNS-34]: http://dev.clojure.org/jira/browse/TNS-34 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: ANN: org.clojure/tools.namespace 0.2.11
Hooray for compatibility in general. Let us always remember the less fortunate. (Ehem - users of Emacs 23 for example.) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help
Dragan, this just occurred to me--a small comment about the slow speed that I reported https://groups.google.com/forum/#!topic/numerical-clojure/WZ-CRchDyl8 from clatrix, which you mentioned earlier. I'm not sure whether the slow speed I experienced on 500x500 matrices itself provides evidence for general conclusions about using the core.matrix api as an interface to BLAS. There was still a lot of work to be done on clatrix at that point--maybe there still is. My understanding is that clatrix supported the core.matrix api at that stage, but it was known that it didn't do so in an optimized way, in many respects. Optimizing remaining areas was left for future work. I think your general point doesn't depend on my experience with clatrix a year ago, however. I understand you to be saying that there are some coding strategies that provide efficient code with BLAS and LAPACK, and that are easy to use in Neanderthal, but that are difficult or impossible using the core.matrix api. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/d/optout.
Re: breaking homoiconicity?
On Jun 20, 2015, at 3:58 AM, Joe Corneli holtzerman...@gmail.com wrote: On Saturday, June 20, 2015 at 4:15:30 AM UTC+1, Sean Corfield wrote: (.getTypeName (Class/forName [Ljava.lang.String;)) ;;= java.lang.String[] — that is more readable! Thanks, that's helpful for me. By chance do you know if the class is natively recoverable from the TypeName for Clojure/Java? Class/forName can't roundtrip that string. I’m not sure what you mean? The type of the array displays as [Ljava.lang.String; and when you do Class/forName on [Ljava.lang.String; you get back a Class that represents an array of String. The TypeName is just a human-readable form, not an actual Class name. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ 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/d/optout.
