Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help
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. 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. 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? With gratitude Chris On Fri, Jun 19, 2015 at 1:45 PM, Matt Revelle mreve...@gmail.com 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/dFPOOw8pSGI/unsubscribe. To unsubscribe from this group and all its topics, 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] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help
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: [ANN] Clojure 1.7.0-RC2
After some quick testing, everything is looking good for me. I will pound on it more heavily this weekend, and report back if that changes, although I do not expect it to. Thanks! On Wednesday, June 17, 2015 at 12:44:39 PM UTC-5, Alex Miller wrote: Clojure 1.7.0-RC2 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC2/ - Leiningen: [org.clojure/clojure 1.7.0-RC2] 1.7.0-RC2 has the following changes since 1.7.0-RC1: 1) CLJ-1735 - Throwable-map was missing docstring 2) CLJ-1237 - reduce gives a StackOverflow for seqs that switch back and forth between chunked and unchunked many times This was an old problem that was amplified in 1.7, but has now been fixed. 3) CLJ-1738 - Seqs over Java iterators that return the same mutating object on every next() call Seqs are fundamentally incompatible with Java iterators that return the same mutating object on every call to next(). Some Clojure libraries incorrectly rely on calling seq on such iterators. In 1.7, iterator-seqs are chunked, which will cause many of these incorrect usages to return incorrect results immediately. The `seq` and `iterator-seq` docstrings have been updated to include an explicit warning. Libraries that incorrectly use `seq` and `iterator-seq` will need to be fixed before running against 1.7. 4) CLJ-1745 - Exceptions thrown from macros wrapped in additional CompilerException This was a regression from CLJ-1169 and most of that change has been rolled back. For a full list of changes since 1.6.0, see: https://github.com/clojure/clojure/blob/master/changes.md Please give it a try and let us know if things are working (or not). The more and quicker feedback we get, the sooner we can release 1.7.0 final! - 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/d/optout.
breaking homoiconicity?
This is an interaction with Clojure via CIDER. repl [1] (type (into-array String [Awesome])) [Ljava.lang.String; repl [2] [Ljava.lang.String; RuntimeException EOF while reading, starting at line 1 clojure.lang.Util.runtimeException (Util.java:221) repl [3] (quote [Ljava.lang.String;) CIDER won't let me enter [3] claiming that the input is not complete. What's going on here, apart from things not working? If [Ljava.lang.String; is a valid return value, and can show up in code that I construct programmatically, why is it not valid input? Is this a flaw in CIDER / lein, or are they giving me the right answers 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: breaking homoiconicity?
Most Java types don't have reversible serialisation in Clojure. There's actually only a small subset of data types that can be printed and then read without losing information. - James On 20 June 2015 at 01:08, Joe Corneli holtzerman...@gmail.com wrote: This is an interaction with Clojure via CIDER. repl [1] (type (into-array String [Awesome])) [Ljava.lang.String; repl [2] [Ljava.lang.String; RuntimeException EOF while reading, starting at line 1 clojure.lang.Util.runtimeException (Util.java:221) repl [3] (quote [Ljava.lang.String;) CIDER won't let me enter [3] claiming that the input is not complete. What's going on here, apart from things not working? If [Ljava.lang.String; is a valid return value, and can show up in code that I construct programmatically, why is it not valid input? Is this a flaw in CIDER / lein, or are they giving me the right answers 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. -- 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 19, 2015, at 5:08 PM, Joe Corneli holtzerman...@gmail.com wrote: This is an interaction with Clojure via CIDER. repl [1] (type (into-array String [Awesome])) [Ljava.lang.String; This is a java.lang.Class object whose name is [Ljava.lang.String; because that’s how Java native arrays are encoded. CIDER won't let me enter [3] claiming that the input is not complete. What's going on here, apart from things not working? You can get the Class object like this: (Class/forName [Ljava.lang.String;) ;;= [Ljava.lang.String; — unhelpful but this is the name of the class, as above. and you can see what it really is like this: (.getTypeName (Class/forName [Ljava.lang.String;)) ;;= java.lang.String[] — that is more readable! 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.
Re: ring - setting no-cache for everything?
None of this is applicable for closed intranet sites, and cache-control solves the very annoying situation where users are running an old version of CSS or Javascript. I agree with these points for public facing ‘web sites’. For ‘enterprise SPAs’ there is usually a different context and set of requirements/restrictions to deal with. On 19 Jun 2015, at 13:56, Fluid Dynamics a2093...@trbvm.com wrote: On Friday, June 19, 2015 at 5:54:03 AM UTC-4, James Reeves wrote: Ring doesn't set any caching headers unless you add in middleware to do so. The most common middleware is wrap-not-modified, which returns a 304 response if the etag or last-modified dates indicate the resource hasn't been modified. For resources in jar files, the last-modified date is set to the modification date of the containing jar. You could add some middleware to force the browser not to cache resources via the cache-control header (see here https://stackoverflow.com/questions/49547/making-sure-a-web-page-is-not-cached-across-all-browsers), or if this is just for development, then Chrome at least has a checkbox in the developer tools for disabling caching. 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). Meanwhile, cache-control has all of the following very annoying consequences for users (at lease one of which hits the web site too): * Every page load and navigation step is painfully slow because of all of the various reloading assets and such, if the user is on any typical consumer broadband connection rather than real broadband. * In particular, normally instant back-arrow and forward-arrow navigation are annoyingly slow. * If the user's connection is noticeably flaky, then the page is likely to only partly load, and using back-arrow forward-arrow to try to force the missing elements to load also loses the elements that were already loaded, instead of incrementally loading more and more of the page until eventually it's all there. * It costs both the user and the web site bandwidth. Important to you, and important to at least your mobile users, who probably have metered *and* tightly capped data plans. * In Firefox, at least, cache-control breaks image right-click save-as, because right-click save-as just copies the cached image normally, but if it's not cached instead tries to download it again. If that's combined with typical hotlinking blocking, the result tends to be errors or corrupt jpegs. To see this effect go to a Photobucket album, which serves either the image itself or a webpage with the image in it depending on referer and which also uses cache-control. If you right-click save-as the image you'll get a corrupt jpeg file that, when opened in Notepad, is actually full of HTML. Of course, blocking hotlinking and playing clever redirection tricks with referer is evil too, but cache-control compounds that evil a thousandfold. (The only correct use of referer is for log analysis to discover how your users navigate around your site. Using it to discriminate against users based on where they were linked in from is evil and wrong.) Upshot: Use Ajax push/pull if you really want users to always see up-to-date information, and otherwise let them use refresh as appropriate. And don't get cute serving different content for the same URI depending on referer; that's just wrong. :) -- 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 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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
Re: 1.7.0b2, lein, cljc and tests
Hi Gary, lein does appear to support it as lein test some-test-in-cljc works, just not if I do ‘lein test’. Is this expected? I am running 2.5.1 On 19 Jun 2015, at 14:46, Gary Trakhman gary.trakh...@gmail.com wrote: Leiningen needs to support cljc, right now only the compiler does, and clojure-maven-plugin since a few days ago. https://github.com/technomancy/leiningen/issues/1827 https://github.com/technomancy/leiningen/issues/1827 On Fri, Jun 19, 2015 at 9:41 AM Colin Yates colin.ya...@gmail.com mailto:colin.ya...@gmail.com wrote: First - cljc is (for me) a huge upgrade over cljx, which was a great solution. Not having to run lein clix auto every time I do a clean is far more useful than I realised. The problem I am having is that cljc test files don't seem to be picked up. I have test/clj and test/cljc, my test-paths in project.clj are [test/clj test/cljc] but 'lein test', and 'lein test-refresh' don't see them. If I do a 'lein test some-namespace-in-cljc' then the tests are run. Has anyone else experienced this and if so, any pointers on moving forward? 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 mailto: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 mailto:clojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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: 1.7.0b2, lein, cljc and tests
I encountered a couple of glitches around cljc support through figwheel. Updating a .cljc file was triggering a recompilation in some circumstances. I did not investigate further, it kind of disappeared from my horizon but I do not why exactly. Can't relate this to a change in my project yet. Luc P. Hi Gary, lein does appear to support it as lein test some-test-in-cljc works, just not if I do ‘lein test’. Is this expected? I am running 2.5.1 On 19 Jun 2015, at 14:46, Gary Trakhman gary.trakh...@gmail.com wrote: Leiningen needs to support cljc, right now only the compiler does, and clojure-maven-plugin since a few days ago. https://github.com/technomancy/leiningen/issues/1827 https://github.com/technomancy/leiningen/issues/1827 On Fri, Jun 19, 2015 at 9:41 AM Colin Yates colin.ya...@gmail.com mailto:colin.ya...@gmail.com wrote: First - cljc is (for me) a huge upgrade over cljx, which was a great solution. Not having to run lein clix auto every time I do a clean is far more useful than I realised. The problem I am having is that cljc test files don't seem to be picked up. I have test/clj and test/cljc, my test-paths in project.clj are [test/clj test/cljc] but 'lein test', and 'lein test-refresh' don't see them. If I do a 'lein test some-namespace-in-cljc' then the tests are run. Has anyone else experienced this and if so, any pointers on moving forward? 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 mailto: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 mailto:clojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: stuartsierra/component is oop, can clojure namespace self init to solve the dependencies?
OOP always talks about object (mutable or immutable) in terms of polymorphism, encapsulation and inheritance. Components library misses only inheritance, which, obviously, the killer feature in OOP. So we could say that Components library that take good ideas from OOP. If you want call something on load of module, make call to this something explicit, ie: wrap it into a function and run on your system component start explicitly. This approach will give more flexibility and control on your state. 2015-06-18 13:08 GMT+03:00 Xiangtao Zhou tao...@gmail.com: oop means object oriented programming, which doesn't mean mutable. record is oop and immutable. when you use java, you can asume everthing is immutable. if i use dynamic to implement the object, i can test it with binding; others i can test with with-redefs. so it works, except side effects. On Thursday, June 18, 2015 at 5:21:46 PM UTC+8, Atamert Ölçgen wrote: How is stuartsierra/component OOP when it is building an immutable object graph? (Contrast that to Guava etc.) On Thu, Jun 18, 2015 at 5:15 AM, Xiangtao Zhou tao...@gmail.com wrote: hi guys, Constructing simple clojure project is trival, just make functions. if the project grows large, with more datasources, message queue, and other storages, dependencies problem is on the table. One solution is stuartsierra/component, using system to configure dependencies graph, make component and dependencies resolution separate. If we make namespace must run with code block that init the namespace, like the start method in component, is this a good way to solve the dependencies? You can do that. But it's not a really good idea to have top-level side-effectful code within namespaces. How are you going to test that ns? How will you do (stop)? Namespaces should only define things. because when the namespace is required the first time, the init block worked once. any suggestion is appreciated. - Joe -- 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=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/d/optout. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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. -- Best regards, Serhii Nechyporchuk -- 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.
1.7.0b2, lein, cljc and tests
First - cljc is (for me) a huge upgrade over cljx, which was a great solution. Not having to run lein clix auto every time I do a clean is far more useful than I realised. The problem I am having is that cljc test files don't seem to be picked up. I have test/clj and test/cljc, my test-paths in project.clj are [test/clj test/cljc] but 'lein test', and 'lein test-refresh' don't see them. If I do a 'lein test some-namespace-in-cljc' then the tests are run. Has anyone else experienced this and if so, any pointers on moving forward? 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/d/optout.
Re: 1.7.0b2, lein, cljc and tests
Leiningen needs to support cljc, right now only the compiler does, and clojure-maven-plugin since a few days ago. https://github.com/technomancy/leiningen/issues/1827 On Fri, Jun 19, 2015 at 9:41 AM Colin Yates colin.ya...@gmail.com wrote: First - cljc is (for me) a huge upgrade over cljx, which was a great solution. Not having to run lein clix auto every time I do a clean is far more useful than I realised. The problem I am having is that cljc test files don't seem to be picked up. I have test/clj and test/cljc, my test-paths in project.clj are [test/clj test/cljc] but 'lein test', and 'lein test-refresh' don't see them. If I do a 'lein test some-namespace-in-cljc' then the tests are run. Has anyone else experienced this and if so, any pointers on moving forward? 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/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: ring - setting no-cache for everything?
It is worth mentioning for others that if you are using ring.middleware.defaults/wrap-defaults then this middleware is already in play. On 19 Jun 2015, at 10:53, James Reeves ja...@booleanknot.com wrote: Ring doesn't set any caching headers unless you add in middleware to do so. The most common middleware is wrap-not-modified, which returns a 304 response if the etag or last-modified dates indicate the resource hasn't been modified. For resources in jar files, the last-modified date is set to the modification date of the containing jar. You could add some middleware to force the browser not to cache resources via the cache-control header (see here https://stackoverflow.com/questions/49547/making-sure-a-web-page-is-not-cached-across-all-browsers), or if this is just for development, then Chrome at least has a checkbox in the developer tools for disabling caching. - James On 19 June 2015 at 10:00, Colin Yates colin.ya...@gmail.com mailto:colin.ya...@gmail.com 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 mailto: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 mailto:clojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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: ring - setting no-cache for everything?
On Friday, June 19, 2015 at 5:54:03 AM UTC-4, James Reeves wrote: Ring doesn't set any caching headers unless you add in middleware to do so. The most common middleware is wrap-not-modified, which returns a 304 response if the etag or last-modified dates indicate the resource hasn't been modified. For resources in jar files, the last-modified date is set to the modification date of the containing jar. You could add some middleware to force the browser not to cache resources via the cache-control header (see here https://stackoverflow.com/questions/49547/making-sure-a-web-page-is-not-cached-across-all-browsers), or if this is just for development, then Chrome at least has a checkbox in the developer tools for disabling caching. 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). Meanwhile, cache-control has all of the following very annoying consequences for users (at lease one of which hits the web site too): * Every page load and navigation step is painfully slow because of all of the various reloading assets and such, if the user is on any typical consumer broadband connection rather than real broadband. * In particular, normally instant back-arrow and forward-arrow navigation are annoyingly slow. * If the user's connection is noticeably flaky, then the page is likely to only partly load, and using back-arrow forward-arrow to try to force the missing elements to load also loses the elements that were already loaded, instead of incrementally loading more and more of the page until eventually it's all there. * It costs both the user and the web site bandwidth. Important to you, and important to at least your mobile users, who probably have metered *and* tightly capped data plans. * In Firefox, at least, cache-control breaks image right-click save-as, because right-click save-as just copies the cached image normally, but if it's not cached instead tries to download it again. If that's combined with typical hotlinking blocking, the result tends to be errors or corrupt jpegs. To see this effect go to a Photobucket album, which serves either the image itself or a webpage with the image in it depending on referer and which also uses cache-control. If you right-click save-as the image you'll get a corrupt jpeg file that, when opened in Notepad, is actually full of HTML. Of course, blocking hotlinking and playing clever redirection tricks with referer is evil too, but cache-control compounds that evil a thousandfold. (The only correct use of referer is for log analysis to discover how your users navigate around your site. Using it to discriminate against users based on where they were linked in from is evil and wrong.) Upshot: Use Ajax push/pull if you really want users to always see up-to-date information, and otherwise let them use refresh as appropriate. And don't get cute serving different content for the same URI depending on referer; that's just wrong. :) -- 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?
Ring doesn't set any caching headers unless you add in middleware to do so. The most common middleware is wrap-not-modified, which returns a 304 response if the etag or last-modified dates indicate the resource hasn't been modified. For resources in jar files, the last-modified date is set to the modification date of the containing jar. You could add some middleware to force the browser not to cache resources via the cache-control header (see here https://stackoverflow.com/questions/49547/making-sure-a-web-page-is-not-cached-across-all-browsers), or if this is just for development, then Chrome at least has a checkbox in the developer tools for disabling caching. - James On 19 June 2015 at 10:00, Colin Yates colin.ya...@gmail.com 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. -- 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?
Thanks James. On 19 Jun 2015, at 10:53, James Reeves ja...@booleanknot.com wrote: Ring doesn't set any caching headers unless you add in middleware to do so. The most common middleware is wrap-not-modified, which returns a 304 response if the etag or last-modified dates indicate the resource hasn't been modified. For resources in jar files, the last-modified date is set to the modification date of the containing jar. You could add some middleware to force the browser not to cache resources via the cache-control header (see here https://stackoverflow.com/questions/49547/making-sure-a-web-page-is-not-cached-across-all-browsers), or if this is just for development, then Chrome at least has a checkbox in the developer tools for disabling caching. - James On 19 June 2015 at 10:00, Colin Yates colin.ya...@gmail.com mailto:colin.ya...@gmail.com 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 mailto: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 mailto:clojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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.
ring - setting no-cache for everything?
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] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help
I understand the concept core.matrix tries to achieve, and would be extremely happy if I thought it would be possible, since I would be able to use it and spend time on some other stuff instead of writing C, JNI, OpenCL and such low-level code. Thanks for the pointer to your neural networks experience and benchmark. I have taken a look at the thread you started about that issue, and it clearly shows what (in my opinion) is wrong is core.matrix: it is extremely easy to shoot yourself in the foot with it by (unintentionally) using the backing implementation in a wrong way. And, when you need to be specific an exploit the strength of the implementation, core.matrix gets in your way by making it more difficult in best cases and even impossible. Moreover, the optimizations that you manage to achieve with one implementation, often turn to be hogs with another, with just one configuration change. For example, if you look at the benchmark on the neanderthal's web site, you'd see that for 512x512 matrices, matrix multiplication is 5x faster with clatrix (jblas) than vectorz. Yet, in your implementation, you managed to turn that 5x speedup into a 1000x slowdown (in the 500x500 case) without even one change in code. Quite impressive on the core.matrix side ;) 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. -- 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: stuartsierra/component is oop, can clojure namespace self init to solve the dependencies?
All objects can as well be implemented with message passing, a functional technique. However, if one would do it with stuartsierra/component, it would be so trivial that you could hardly call the lib object orientated. On Friday, June 19, 2015 at 11:14:04 AM UTC+2, Serzh Nechyporchuk wrote: OOP always talks about object (mutable or immutable) in terms of polymorphism, encapsulation and inheritance. Components library misses only inheritance, which, obviously, the killer feature in OOP. So we could say that Components library that take good ideas from OOP. If you want call something on load of module, make call to this something explicit, ie: wrap it into a function and run on your system component start explicitly. This approach will give more flexibility and control on your state. 2015-06-18 13:08 GMT+03:00 Xiangtao Zhou tao...@gmail.com javascript:: oop means object oriented programming, which doesn't mean mutable. record is oop and immutable. when you use java, you can asume everthing is immutable. if i use dynamic to implement the object, i can test it with binding; others i can test with with-redefs. so it works, except side effects. On Thursday, June 18, 2015 at 5:21:46 PM UTC+8, Atamert Ölçgen wrote: How is stuartsierra/component OOP when it is building an immutable object graph? (Contrast that to Guava etc.) On Thu, Jun 18, 2015 at 5:15 AM, Xiangtao Zhou tao...@gmail.com wrote: hi guys, Constructing simple clojure project is trival, just make functions. if the project grows large, with more datasources, message queue, and other storages, dependencies problem is on the table. One solution is stuartsierra/component, using system to configure dependencies graph, make component and dependencies resolution separate. If we make namespace must run with code block that init the namespace, like the start method in component, is this a good way to solve the dependencies? You can do that. But it's not a really good idea to have top-level side-effectful code within namespaces. How are you going to test that ns? How will you do (stop)? Namespaces should only define things. because when the namespace is required the first time, the init block worked once. any suggestion is appreciated. - Joe -- 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=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/d/optout. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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 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/d/optout. -- Best regards, Serhii Nechyporchuk -- 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
Neanderthal seems very cool. You've clearly put a *lot* of work into this. I for one am thankful that you've made available what is a very nice tool, as far as I can see. I don't think there's necessarily a conflict concerning core.matrix, though. You may not want to write a core.matrix wrapper for Neanderthal. There's no reason that you must. Someone else might want to do that; maybe I would be able to help with that project. In that case, those who wanted to use Neanderthal via core.matrix could do so, knowing that they lose out on any potential advantages of writing directly to Neanderthal, and those who want to use Neanderthal in its original form can still do so. I don't see a conflict. In my case, I have existing code that uses core.matrix. I wrote to core.matrix in part because I didn't want to have to worry about which implementation to write to. I would love to try my code on Neanderthal, but I'm not willing to port it. That's my problem, not yours, though. For future projects, I could write to Neanderthal, but I also have to consider the possibility that there might be situations in which another implementation would be better for my code. Neanderthal looks great, but is it always fastest for every application that uses non-tiny matrices? Maybe it would be for anything I would write. I'd rather not have to figure that out. I'm granting that there could be advantages to using Neanderthal in its native form rather than via core.matrix, but for me, personally, it would be simpler to use it via core.matrix if that was an option. It's not your responsibility to enable that unless you wanted to do so, though. What you've done is already more than enough, Dragan. On Friday, June 19, 2015 at 3:57:32 AM UTC-5, Dragan Djuric wrote: I understand the concept core.matrix tries to achieve, and would be extremely happy if I thought it would be possible, since I would be able to use it and spend time on some other stuff instead of writing C, JNI, OpenCL and such low-level code. Thanks for the pointer to your neural networks experience and benchmark. I have taken a look at the thread you started about that issue, and it clearly shows what (in my opinion) is wrong is core.matrix: it is extremely easy to shoot yourself in the foot with it by (unintentionally) using the backing implementation in a wrong way. And, when you need to be specific an exploit the strength of the implementation, core.matrix gets in your way by making it more difficult in best cases and even impossible. Moreover, the optimizations that you manage to achieve with one implementation, often turn to be hogs with another, with just one configuration change. For example, if you look at the benchmark on the neanderthal's web site, you'd see that for 512x512 matrices, matrix multiplication is 5x faster with clatrix (jblas) than vectorz. Yet, in your implementation, you managed to turn that 5x speedup into a 1000x slowdown (in the 500x500 case) without even one change in code. Quite impressive on the core.matrix side ;) 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. -- 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: 1.7.0b2, lein, cljc and tests
Probably this needs updating https://github.com/technomancy/leiningen/blob/master/src/leiningen/test.clj#L137 On Friday, June 19, 2015 at 8:41:49 AM UTC-5, Colin Yates wrote: First - cljc is (for me) a huge upgrade over cljx, which was a great solution. Not having to run lein clix auto every time I do a clean is far more useful than I realised. The problem I am having is that cljc test files don't seem to be picked up. I have test/clj and test/cljc, my test-paths in project.clj are [test/clj test/cljc] but 'lein test', and 'lein test-refresh' don't see them. If I do a 'lein test some-namespace-in-cljc' then the tests are run. Has anyone else experienced this and if so, any pointers on moving forward? 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/d/optout.
Re: 1.7.0b2, lein, cljc and tests
Filed https://github.com/technomancy/leiningen/pull/1920/ On Friday, June 19, 2015 at 10:48:46 AM UTC-5, Alex Miller wrote: Probably this needs updating https://github.com/technomancy/leiningen/blob/master/src/leiningen/test.clj#L137 On Friday, June 19, 2015 at 8:41:49 AM UTC-5, Colin Yates wrote: First - cljc is (for me) a huge upgrade over cljx, which was a great solution. Not having to run lein clix auto every time I do a clean is far more useful than I realised. The problem I am having is that cljc test files don't seem to be picked up. I have test/clj and test/cljc, my test-paths in project.clj are [test/clj test/cljc] but 'lein test', and 'lein test-refresh' don't see them. If I do a 'lein test some-namespace-in-cljc' then the tests are run. Has anyone else experienced this and if so, any pointers on moving forward? 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/d/optout.
Re: ring - setting no-cache for everything?
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. This way old HTML refers to old CSS and new HTML to new CSS, plus you can add Cache-Control: public, max-age=31536000 to the static files which allows the browser to actually SKIP checking if a resource was modified (ie. huge speed gains, no if-modified-since-not modified round trip). Disabling cache is usually the least desirable option and if you care about performance at all you should think twice before doing so (yes, even for intranet sites). /thomas -- 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
That is what I think from the start of the discussion, and I agree with you. The only thing is that i am almost certain that the performance gain will be very easy to reverse, just like in the case of Clatrix. Because it is built on top of blas and atlas, which is the the de facto standard and a state of the art implementation, I am also pretty certain that it will be the fastest library on the CPU even for small matrices. The only exception would be the very teeny ones like 3x2 or something (see the benchmark), and even then Neanderthal is only 2x slower than vectorz despite the FFI dance. If I was you, it is not the speed that I would be concerned about regarding Neanderthal. In my opinion, currently there are only two major drawbacks to using Neanderthal: 1. It is a new and unproven library. The author may win the lottery, decide to retire on the tropical island and abandon all projects. This is less of a trouble if it becomes popular, since someone else could just take over the development. 2. You have to install a native library (atlas). This issue is not even that big, since i (or you, since the build is automatic) could ship atlas statically compiled like jblas does, but then the top performance would depend on the user having similar cpu as I (but even that for the last 10 or 20% of performance, and not in the order of magnitude). On Friday, June 19, 2015, Mars0i marsh...@logical.net wrote: Neanderthal seems very cool. You've clearly put a *lot* of work into this. I for one am thankful that you've made available what is a very nice tool, as far as I can see. I don't think there's necessarily a conflict concerning core.matrix, though. You may not want to write a core.matrix wrapper for Neanderthal. There's no reason that you must. Someone else might want to do that; maybe I would be able to help with that project. In that case, those who wanted to use Neanderthal via core.matrix could do so, knowing that they lose out on any potential advantages of writing directly to Neanderthal, and those who want to use Neanderthal in its original form can still do so. I don't see a conflict. In my case, I have existing code that uses core.matrix. I wrote to core.matrix in part because I didn't want to have to worry about which implementation to write to. I would love to try my code on Neanderthal, but I'm not willing to port it. That's my problem, not yours, though. For future projects, I could write to Neanderthal, but I also have to consider the possibility that there might be situations in which another implementation would be better for my code. Neanderthal looks great, but is it always fastest for every application that uses non-tiny matrices? Maybe it would be for anything I would write. I'd rather not have to figure that out. I'm granting that there could be advantages to using Neanderthal in its native form rather than via core.matrix, but for me, personally, it would be simpler to use it via core.matrix if that was an option. It's not your responsibility to enable that unless you wanted to do so, though. What you've done is already more than enough, Dragan. On Friday, June 19, 2015 at 3:57:32 AM UTC-5, Dragan Djuric wrote: I understand the concept core.matrix tries to achieve, and would be extremely happy if I thought it would be possible, since I would be able to use it and spend time on some other stuff instead of writing C, JNI, OpenCL and such low-level code. Thanks for the pointer to your neural networks experience and benchmark. I have taken a look at the thread you started about that issue, and it clearly shows what (in my opinion) is wrong is core.matrix: it is extremely easy to shoot yourself in the foot with it by (unintentionally) using the backing implementation in a wrong way. And, when you need to be specific an exploit the strength of the implementation, core.matrix gets in your way by making it more difficult in best cases and even impossible. Moreover, the optimizations that you manage to achieve with one implementation, often turn to be hogs with another, with just one configuration change. For example, if you look at the benchmark on the neanderthal's web site, you'd see that for 512x512 matrices, matrix multiplication is 5x faster with clatrix (jblas) than vectorz. Yet, in your implementation, you managed to turn that 5x speedup into a 1000x slowdown (in the 500x500 case) without even one change in code. Quite impressive on the core.matrix side ;) 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. -- 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 javascript:_e(%7B%7D,'cvml','clojure@googlegroups.com'); Note that posts from
Re: 1.7.0b2, lein, cljc and tests
Thanks Alex - you beat me to it! On 19 Jun 2015, at 17:31, Alex Miller a...@puredanger.com wrote: Filed https://github.com/technomancy/leiningen/pull/1920/ On Friday, June 19, 2015 at 10:48:46 AM UTC-5, Alex Miller wrote: Probably this needs updating https://github.com/technomancy/leiningen/blob/master/src/leiningen/test.clj#L137 https://github.com/technomancy/leiningen/blob/master/src/leiningen/test.clj#L137 On Friday, June 19, 2015 at 8:41:49 AM UTC-5, Colin Yates wrote: First - cljc is (for me) a huge upgrade over cljx, which was a great solution. Not having to run lein clix auto every time I do a clean is far more useful than I realised. The problem I am having is that cljc test files don't seem to be picked up. I have test/clj and test/cljc, my test-paths in project.clj are [test/clj test/cljc] but 'lein test', and 'lein test-refresh' don't see them. If I do a 'lein test some-namespace-in-cljc' then the tests are run. Has anyone else experienced this and if so, any pointers on moving forward? 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 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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: 1.7.0b2, lein, cljc and tests
Colin, in the meantime you can still test by stating your ns as arg: lein test my.ns.test.core On 19 Jun 2015 18:21, Karsten Schmidt i...@toxi.co.uk wrote: Hi Alex, I looked at this a couple of weeks ago and it actually also has to do with the bultitude fn called within that fn you patched. Bultitude has been fixed and there was a new release end of May, but not sure if lein has been updated meanwhile... https://github.com/Raynes/bultitude/commit/d8c12b62eb8302cf9d2e9f8566541dbf95981a51 On 19 Jun 2015 17:31, Alex Miller a...@puredanger.com wrote: Filed https://github.com/technomancy/leiningen/pull/1920/ On Friday, June 19, 2015 at 10:48:46 AM UTC-5, Alex Miller wrote: Probably this needs updating https://github.com/technomancy/leiningen/blob/master/src/leiningen/test.clj#L137 On Friday, June 19, 2015 at 8:41:49 AM UTC-5, Colin Yates wrote: First - cljc is (for me) a huge upgrade over cljx, which was a great solution. Not having to run lein clix auto every time I do a clean is far more useful than I realised. The problem I am having is that cljc test files don't seem to be picked up. I have test/clj and test/cljc, my test-paths in project.clj are [test/clj test/cljc] but 'lein test', and 'lein test-refresh' don't see them. If I do a 'lein test some-namespace-in-cljc' then the tests are run. Has anyone else experienced this and if so, any pointers on moving forward? 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/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: 1.7.0b2, lein, cljc and tests
Hi Alex, I looked at this a couple of weeks ago and it actually also has to do with the bultitude fn called within that fn you patched. Bultitude has been fixed and there was a new release end of May, but not sure if lein has been updated meanwhile... https://github.com/Raynes/bultitude/commit/d8c12b62eb8302cf9d2e9f8566541dbf95981a51 On 19 Jun 2015 17:31, Alex Miller a...@puredanger.com wrote: Filed https://github.com/technomancy/leiningen/pull/1920/ On Friday, June 19, 2015 at 10:48:46 AM UTC-5, Alex Miller wrote: Probably this needs updating https://github.com/technomancy/leiningen/blob/master/src/leiningen/test.clj#L137 On Friday, June 19, 2015 at 8:41:49 AM UTC-5, Colin Yates wrote: First - cljc is (for me) a huge upgrade over cljx, which was a great solution. Not having to run lein clix auto every time I do a clean is far more useful than I realised. The problem I am having is that cljc test files don't seem to be picked up. I have test/clj and test/cljc, my test-paths in project.clj are [test/clj test/cljc] but 'lein test', and 'lein test-refresh' don't see them. If I do a 'lein test some-namespace-in-cljc' then the tests are run. Has anyone else experienced this and if so, any pointers on moving forward? 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/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: 1.7.0b2, lein, cljc and tests
Hi Karsten, yep, that is what I am doing now - thanks. On 19 Jun 2015, at 18:23, Karsten Schmidt i...@toxi.co.uk wrote: Colin, in the meantime you can still test by stating your ns as arg: lein test my.ns.test.core On 19 Jun 2015 18:21, Karsten Schmidt i...@toxi.co.uk mailto:i...@toxi.co.uk wrote: Hi Alex, I looked at this a couple of weeks ago and it actually also has to do with the bultitude fn called within that fn you patched. Bultitude has been fixed and there was a new release end of May, but not sure if lein has been updated meanwhile... https://github.com/Raynes/bultitude/commit/d8c12b62eb8302cf9d2e9f8566541dbf95981a51 https://github.com/Raynes/bultitude/commit/d8c12b62eb8302cf9d2e9f8566541dbf95981a51 On 19 Jun 2015 17:31, Alex Miller a...@puredanger.com mailto:a...@puredanger.com wrote: Filed https://github.com/technomancy/leiningen/pull/1920/ https://github.com/technomancy/leiningen/pull/1920/ On Friday, June 19, 2015 at 10:48:46 AM UTC-5, Alex Miller wrote: Probably this needs updating https://github.com/technomancy/leiningen/blob/master/src/leiningen/test.clj#L137 https://github.com/technomancy/leiningen/blob/master/src/leiningen/test.clj#L137 On Friday, June 19, 2015 at 8:41:49 AM UTC-5, Colin Yates wrote: First - cljc is (for me) a huge upgrade over cljx, which was a great solution. Not having to run lein clix auto every time I do a clean is far more useful than I realised. The problem I am having is that cljc test files don't seem to be picked up. I have test/clj and test/cljc, my test-paths in project.clj are [test/clj test/cljc] but 'lein test', and 'lein test-refresh' don't see them. If I do a 'lein test some-namespace-in-cljc' then the tests are run. Has anyone else experienced this and if so, any pointers on moving forward? 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 mailto: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 mailto:clojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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.
ANN: org.clojure/tools.namespace 0.2.11
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.
