Re: Newbie re-implement 'interleave' found type conversion error
Instead of : (if (s1) You just want : (if s1 s1 is a Long, not a function. On Thu, Apr 2, 2015 at 8:56 AM michael zhuang zhuangdeyouxi...@gmail.com wrote: : i'm new to clojure, when I try to implementation 'interleave', get error from type convertion java.lang。Long cannot be cast to clojure.lang.IFN. ; Now im reading stack trace, try to figure out what's going on.. (defn myIL [col1 col2] (loop [m [] s1 (first col1) s2 (first col2)] (if (s1) m (recur (conj (conj m s1) s2) (first (next col1)) (first (next col2))) ))) (myIL [1 3] [2 4]) Any helps ? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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.
Newbie re-implement 'interleave' found type conversion error
: i'm new to clojure, when I try to implementation 'interleave', get error from type convertion java.lang。Long cannot be cast to clojure.lang.IFN. ; Now im reading stack trace, try to figure out what's going on.. (defn myIL [col1 col2] (loop [m [] s1 (first col1) s2 (first col2)] (if (s1) m (recur (conj (conj m s1) s2) (first (next col1)) (first (next col2))) ))) (myIL [1 3] [2 4]) Any helps ? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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-alpha6 released
Yeller (yellerapp.com) (which I maintain) has a comprehensive benchmark suite (using criterium, with a heck of a lot of work put into getting real and good results). I've run Yeller's benchmark suite against clojure 1.7 alpha6 - it's pretty comprehensive, and covers a wide range of things. Results are below. Mostly some things got very minorly slower (but not enough to make a real impact for the application), but quite a few benchmarks saw **dramatic** speedups. Given these promising results, I ran Yeller's `test.check` suite for 8 hours in CI, and didn't see any failures, so I've deployed 1.7 alpha6 to production, and haven't seen any issues as of yet. Yeller's build also got ~24 seconds faster, which is super awesome (and it no longer breaks under CLJ-1604 because that patch is in). Much love to all the folk who put time and work into this release. Benchmark names retracted because they're proprietary. Each line is a seperate benchmark, recorded on production level hardware, with the same jvm options/version used in production. Each benchmark is run in its own JVM (because otherwise JIT path dependence will kill you). Benchmarks that were slower under 1.7 alpha6 vs 1.6.0 (with percentage changed amounts): 3.12% 2.62% 2.27% 2.19% 2.17% 2.06% 1.97% 1.43% 1.29% 0.89% 0.74% 0.71% 0.58% 0.45% 0.42% 0.34% 0.27% 0.25% 0.21% 0.2% 0.08% 0.03% Benchmarks that were faster under 1.7 alpha6 vs 1.6.0 (with percentage changed amounts): +0.0% +0.0% +0.01% +0.02% +0.03% +0.03% +0.03% +0.04% +0.04% +0.09% +0.12% +0.16% +0.31% +0.33% +0.52% +0.53% +0.85% +1.74% +1.84% +1.99% +2.14% +2.17% +2.42% +2.96% +3.0% +5.18% +5.36% +9.86% +11.93% +12.41% +14.36% +16.95% +24.71% +53.5% +53.62% +72.07% Thanks again! Super excited about this release. On Wednesday, 1 April 2015 01:51:13 UTC+9, Alex Miller wrote: Clojure 1.7.0-alpha6 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/ - Leiningen: [org.clojure/clojure 1.7.0-alpha6] Regression fixes from previous alphas (and one from 1.6): 1) CLJ-1544 was rolled back and will be investigated for a future release. 2) CLJ-1637 fixed regression with vec on MapEntry 3) CLJ-1663 fixed regression in classloader (affected Cursive) 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) method 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for literal nil arg 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that prevented update Some highlights new in alpha6: ## Transducer-related changes: The LazyTransformer introduced to create lazy transforming sequences has been replaced with a TransformingIterator. This was done to simplify the code around transformations and to make certain use cases around eduction more efficient. ## Faster reduce, iterator, and sequence paths A lot of work has been done across a set of tickets to improve the ability of collections to provide more efficient reduce or iterator performance, and also to make common sequence generators create faster sequence and reduce paths. You should see significant performance in many reduce-related paths (this includes reduce, transduce, into, and anything else built on reduce). Many of those changes also have beneficial sequence performance, so you may see some benefits even in code that does not use transducers. * Most uses of SeqIterator have now been replaced with iterators that directly walk the underlying source for improved efficiency. This includes maps, sets, records, etc. * repeat - now returns a faster sequence with a fast reduce path * cycle - now returns a faster sequence with a fast reduce path * iterate - now returns a faster sequence with a fast reduce path * range - (did not quite make it in, but coming soon...) * keys - iterates directly over the keys of a map, without seq or MapEntry allocation * vals - iterates directly over the vals of a map, without seq or MapEntry allocation * iterator-seq - now creates a chunked sequence when previously it was unchunked * vec and set - were not changed in this release but were set up in a previous alpha to take advantage of the reduce and iterator changes above ## Reader conditionals Reader Conditionals is a new capability to support portable code that can run on multiple Clojure platforms with only small changes. In particular, this feature aims to support the increasingly common case of libraries targeting both Clojure and ClojureScript. Code intended to be common across multiple platforms should use a new supported file extension: .cljc. When requested to load a namespace, the platform-specific file extension (.clj, .cljs) will be checked prior to .cljc. A new reader form can be used to specify reader conditional code in cljc files (and *only* cljc files). Each platform defines a feature identifying the platform (:clj, :cljs, :cljr). The reader
Re: Transducers: sequence versus eduction
Alex Miller a...@puredanger.com writes: Ok. But to me, if I can call `seq` on a thing and iterate it using `first` and `rest`, that's a sequable thing to me. :-) Fair enough. I just meant it no longer implements Seqable. :) Yes, I got that. But I think that's an implementation detail. I go with the sequable definition of Clojure Programming which says The set of types that are /sequable/ -- that is, those for which `seq` can produce a valid value -- include: - All Clojure collection types - All Java collections - ... - Anything that implements Clojure's clojure.lang.Sequable interface So we can agree on eduction not being a Sequable but still being sequable. :-) I think my prime use-case is deeply nested mapcatting where the mapcatted function gets an object and returns a java collection, and filtering with usually a quite cheap predicate. E.g. (sequence-or-eduction (comp (mapcat ...) (filter ...) (mapcat ...) ... (filter ...)) coll) That's part of a larger search algorithm which either stops after finding the first match (in which case the resulting sequence is likely not to be realized completely) or runs till all matches are found (in which case all these transducer-produced sequences would be fully realized). If that would make sense, I could use eduction when I know everything will be realized and sequence in the other case (or vice versa). In this case, I don't know that I'd expect much difference. sequence is going to create a TransformerIterator, and wrap it in an chunkedIteratorSeq. Using (seq (eduction ...) should give you exactly the same thing, except calling through an Eduction type. So, I doubt it matters. Ok, thanks. Could you also comment on my other question namely the full realization of intermediate operations in: ,[ Docs of sequence at http://clojure.org/transducers ] | The resulting sequence elements are incrementally computed. These | sequences will consume input incrementally as needed and fully realize | intermediate operations. This behavior differs from the equivalent | operations on lazy sequences. ` Does that mean I'm better off with a traditionally nested map/mapcat/filter cascade instead of transducers in the case where the intermediate mapcatting functions return possibly not so cheap/large lazy sequences and it is likely that I won't fully realize the result sequence or eduction? Hm, I now benchmarked a bit with criterium and measured (sequence (comp (mapcat #(range %)) (mapcat #(range %))) (range 1000)) versus (eduction (comp (mapcat #(range %)) (mapcat #(range %))) (range 1000)) versus the traditional (mapcat #(range %) (mapcat #(range %) (range 1000))) and either taking just the first element of the result using (first ...), taking the first 1000 elements of the result using (dorun (take 1000 ...)), or realizing everything using (dorun ...). These are the timings: | Version| first | first 1000 | everything | |+---++| | transd. (sequence) | 10 μs | 214 μs | 21 sec | | transd. (eduction) | 10 μs | 216 μs | 21 sec | | traditional| 3 μs | 151 μs | 7 sec | So as you see, the traditional version is about three times faster in the first and everything scenario, and just a littlebit faster in the first 1000 scenario. When I test (sequence (comp (mapcat #(range % 1000)) (mapcat #(range % 1000))) (range 1000)) versus (eduction (comp (mapcat #(range % 1000)) (mapcat #(range % 1000))) (range 1000)) versus (mapcat #(range % 1000) (mapcat #(range % 1000) (range 1000))) so that the larger intermediate sequences come first, I get these timings: | Version| first | first 1000 | everything | |+---++| | transd. (sequence) | 24 ms | 24 ms | 21 sec | | transd. (eduction) | 24 ms | 24 ms | 21 sec | | traditional| 4 μs | 102 μs | 7 sec | So here the results are even much worse than above. If you don't fully realize the resulting sequence the traditional version can be many orders of magnitudes faster. I guess that's because of the cited statement above, i.e., intermediate operations are always fully realized. However, at least I had expected that in the case where all elements are realized the transducer version should have been faster than the traditional version which also needs to fully realize all intermediate lazy seqs. Why is it still three times slower? So my conclusion is that you cannot use transducers as a kind of drop-in replacement of traditional sequence manipulation functions. They pay off only when you can make very strong assumptions about
Re: clojure, not the go to for data science
Fluid Dynamics a2093...@trbvm.com writes: On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote: The benefit is that Emacs is that its not constantly changing, and it gives you some stability over the years. I like latex, for instance, for the same reason. I can still access a 10 year old document and use it. First of all, there are other posts in this thread complaining about constantly changing stuff breaking things! One such post is by Colin Yates. Yes. Obviously, newer stuff is changing. Second, to the extent that it isn't changing, it is legacy. It makes little sense to complain about things changing, and then to say things are legacy when they are not changing. Legacy code is not code that is old. Legacy code is not code that you wish were better. Legacy code is not even code that is nasty and hairy. Legacy code is code for which there is a better alternative, but which the activation energy of removing is too high. I scanned most of the rest of your post. It's a bit of a ramble, and doesn't relate to much of the software that I use. Broadly, I agree, that old software sometimes behaves in a way that we would not write today. Equally, software which has been written today sometimes suffers from problems that were long solved in older software. The costs from using old software are real, yes, but then so are the costs of using new software, especially, if this entails constantly trying out the latest and greatest technology just for the sake of it. Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
I put a site with usable JavaDoc for Clojure.
https://github.com/PoleKilroySoft/ClojureJavadoc There are the package level Javadocs for latest versions of Clojure, now from Clojure 1.3.0 to 1.7.0-alpha6. Link to the Javadoc site, corresponding release sources and zipped sites for a local usage... I'll try to go until the version 1.0 for educational purpose. So you'll be able to add the javadoc command link to reach the internal documentation whatever version you use -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: clojure, not the go to for data science
I think the credit here has to go to RStudio for doing such a good job of making an easy to install complete development environment. I'd say just comparing base Clojure to base R, it's a wash. Install java and either download the Clojure jar, or the leiningen script, and you're good to go. Similar effort with R, just install the R distribution. Either way you don't get much more than a REPL prompt. It is possible to get a working, fully-featured Clojure development environment going without *much* more difficulty than RStudio. In fact, I did precisely cover install and setup in two easy videos :-) See http://gorilla-repl.org/videos.html , bottom of the page. I would still say that RStudio deserves kudos here though, as they've made it really easy to get going. And I think there is value in this, as my experience with getting inexperienced programmers started is that they easily get stuck on the little set up details. I'd like to make Gorilla REPL easier to get started with, but haven't figured out how to do that in a way that's compatible with the amount of time I have to work on it! Jony On Thursday, 2 April 2015 22:14:08 UTC+1, Sayth Renshaw wrote: You appear to have vastly misinterpreted my intention regards Emacs. My mention of Emacs (I use emacs with prelude) was not based on my usage but as a perception of those who might be attracted to Clojure For Purely Data Science And wishes to get installed and moving quickly. R offers to get you installed in 2 quick point and click installs and gives you the language and R studio . What would that person think when looking at Clojure? If they saw emacs would they know about prelude, how to configure it with so many configuration options? If someone out organisation was running a data science course would they choose R because they can cover install and setup in 2 easy videos compared to current Clojure options which may be less clear. Sometimes often times onboarding people to a new language is about as much as ease of install or at least making a default set of optiins clear. Could the default set abs best options be made easier to new comers? Sayth Emacs can use the native windowing system on every major platform. It still *looks* like a terminal app, but doesn't have to be one. Pretty much everything you are saying here doesn't apply to Emacs at all, and you would know it's all false if you knew anything about Emacs. On Wednesday, April 1, 2015 at 4:55:08 PM UTC-7, Fluid Dynamics wrote: On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote: The benefit is that Emacs is that its not constantly changing, and it gives you some stability over the years. I like latex, for instance, for the same reason. I can still access a 10 year old document and use it. First of all, there are other posts in this thread complaining about constantly changing stuff breaking things! One such post is by Colin Yates. Second, to the extent that it isn't changing, it is legacy. Which helps to explain the Wordperfect for DOS style of UI, which is dependent on vast numbers of complex key-combinations being memorized by the user, instead of a just-sit-down-and-start-using-it UI like everything originating after, say, 1995 or so has tended to have. Of course, the result is that Wordperfect (and emacs) seemed to require a great deal of specialized training just to accomplish even the most basic tasks, whereas with modern interfaces the way to do such basic tasks (save, open, copy and paste, move around, select, etc.) tends to be obvious and special training can focus exclusively on doing advanced things (scripting, complicated Photoshop filters and tricks, things like those). Legacy also, obviously, tends to present problems in other areas besides UI-boneheadedness: * I18n and l10n * Compatibility, with modern hardware and with modern operating systems, though that can be alleviated by people porting the code * Boneheaded internal limits, along the same general lines as 640K ought to be enough for anybody. It may be unable to use more than a small fraction of what modern hardware can offer it in the way of memory, storage, cores, ... * Accessibility. Interposing a terminal emulator between the app and screen reading software might cause problems, though on the other hand a text mode app may ultimately have advantages in that area too. On the other hand, it may not play well with accessibility tools that rely on standard UI conventions. Anything that responds to some voice command by generating control-V keystrokes to paste, or that relies on the presence of normal menus and/or mouse support is going to blow up spectacularly when used with 1980s-vintage Unix (or MS-DOS) software, or at best will end up controlling the xterm/Command Prompt window instead of the underlying app. * Interoperation with other (non-operating-system) software.
Re: clojure, not the go to for data science
On Thursday, April 2, 2015 at 5:54:34 PM UTC-4, Jony Hudson wrote: I think the credit here has to go to RStudio for doing such a good job of making an easy to install complete development environment. I'd say just comparing base Clojure to base R, it's a wash. Install java and either download the Clojure jar, or the leiningen script, and you're good to go. Similar effort with R, just install the R distribution. Either way you don't get much more than a REPL prompt. It is possible to get a working, fully-featured Clojure development environment going without *much* more difficulty than RStudio. Umm, it's as easy as downloading the Counterclockwise Standalone binary and running it. So probably exactly equal to just install the R distribution. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: clojure, not the go to for data science
You appear to have vastly misinterpreted my intention regards Emacs. My mention of Emacs (I use emacs with prelude) was not based on my usage but as a perception of those who might be attracted to Clojure For Purely Data Science And wishes to get installed and moving quickly. R offers to get you installed in 2 quick point and click installs and gives you the language and R studio . What would that person think when looking at Clojure? If they saw emacs would they know about prelude, how to configure it with so many configuration options? If someone out organisation was running a data science course would they choose R because they can cover install and setup in 2 easy videos compared to current Clojure options which may be less clear. Sometimes often times onboarding people to a new language is about as much as ease of install or at least making a default set of optiins clear. Could the default set abs best options be made easier to new comers? Sayth Emacs can use the native windowing system on every major platform. It still *looks* like a terminal app, but doesn't have to be one. Pretty much everything you are saying here doesn't apply to Emacs at all, and you would know it's all false if you knew anything about Emacs. On Wednesday, April 1, 2015 at 4:55:08 PM UTC-7, Fluid Dynamics wrote: On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote: The benefit is that Emacs is that its not constantly changing, and it gives you some stability over the years. I like latex, for instance, for the same reason. I can still access a 10 year old document and use it. First of all, there are other posts in this thread complaining about constantly changing stuff breaking things! One such post is by Colin Yates. Second, to the extent that it isn't changing, it is legacy. Which helps to explain the Wordperfect for DOS style of UI, which is dependent on vast numbers of complex key-combinations being memorized by the user, instead of a just-sit-down-and-start-using-it UI like everything originating after, say, 1995 or so has tended to have. Of course, the result is that Wordperfect (and emacs) seemed to require a great deal of specialized training just to accomplish even the most basic tasks, whereas with modern interfaces the way to do such basic tasks (save, open, copy and paste, move around, select, etc.) tends to be obvious and special training can focus exclusively on doing advanced things (scripting, complicated Photoshop filters and tricks, things like those). Legacy also, obviously, tends to present problems in other areas besides UI-boneheadedness: * I18n and l10n * Compatibility, with modern hardware and with modern operating systems, though that can be alleviated by people porting the code * Boneheaded internal limits, along the same general lines as 640K ought to be enough for anybody. It may be unable to use more than a small fraction of what modern hardware can offer it in the way of memory, storage, cores, ... * Accessibility. Interposing a terminal emulator between the app and screen reading software might cause problems, though on the other hand a text mode app may ultimately have advantages in that area too. On the other hand, it may not play well with accessibility tools that rely on standard UI conventions. Anything that responds to some voice command by generating control-V keystrokes to paste, or that relies on the presence of normal menus and/or mouse support is going to blow up spectacularly when used with 1980s-vintage Unix (or MS-DOS) software, or at best will end up controlling the xterm/Command Prompt window instead of the underlying app. * Interoperation with other (non-operating-system) software. On Windows it won't speak OLE, DDE, OCX, or etc., and copying text in it and attempting to paste into something else (web browser, calculator, etc.) is doomed to failure. This is a general problem with pre-window-system software, much like the stuff listed under Accessibility, with no easy solution. Terminal emulators tend to provide some way to copy from their display into the host-native clipboard, but it tends to be clunky (the Windows command prompt appears to require mouse use, with no keyboard shortcuts) and runs into the obvious difficulties as soon as you want to copy more than will fit on one screen. Ironically, really primitive stuff like ls and dir that just dump possibly-paginated noninteractive listings to the term are easier to make big copies from than text-mode, interactive applications like screen-oriented editors, because you can copy from the backscroll buffer of the terminal emulator in the first case. Pre-window-system *graphical* apps are the absolute worst, e.g. later, WYSIWYG word processor versions on MS-DOS, or pre-window-system X applications. No internal support for the host clipboard and, at the same time, nothing the emulator will recognize as text, meaning if you try to native copy and paste you'll end up with a PNG or
Re: clojure, not the go to for data science
On Monday, 30 March 2015 14:46:53 UTC+1, Christian Weilbach wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have started working on R integration with the help of rinancanter (1) and it was nice to have dedicated R code cells with at least syntax highlighting that I can mix with Clojure code in the same JVM environment. http://viewer.gorilla-repl.org/view.html?source=githubuser=ghubberrepo=cncpath=rincanter.clj I am not sure whether this fits the design atm. though. I also had a look at renjin, but I think the native plugins mandate an RVM integration atm. You might find http://beakernotebook.com interesting, if you haven't seen it before. It allows several languages in the same notebook, and has a simple mechanism for sharing data between the language environments. It's pretty green at the moment, but it has some serious backing, so could be pretty useful once it's got a bit more polish on it. I chatted a little with someone who was hoping to implement a Clojure plugin for it, although I don't know how they've gotten on since. I also have taken a paper I liked and implemented a quick version of SNE, which was fairly nice to do in Gorilla REPL: http://viewer.gorilla-repl.org/view.html?source=githubuser=ghubberrepo=cncpath=stochastic-neighbour-embedding.clj A problem seems to be unicode support, I tried to use some math symbols from the notation in the paper directly, but the viewer seems to have a problem with it. Not sure what the problem is there - my feeling is it should just work, on the Gorilla side. If there's a test case you can point to (with an expected result) I can take a look at it. Jony -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: clojure, not the go to for data science
Agree Chris, I think Clojure has a lot of advantage. I never intended to knock Clojure just question as a person returning to look at the project at the potential roadblocks whether real or perceived that were potentially limiting its adoption. Sayth On Fri, 3 Apr 2015 at 10:07 Christopher Small metasoar...@gmail.com wrote: Editors as they apply to data science adoption is certainly relevant, particularly as relates to ease of adoption for beginners. It's easy for an experienced developer to dismiss the difference of ease in adopting something like RStudio vs R by itself; Those with experience already have workflows they're used to (vim/emacs + tmux / whatever), but getting to that point is not trivial. And there are certainly those who come to R and python looking to do data science who have little programming experience. I've seen a lot of this among biologists in particular. The Gorilla REPL does certainly take us a good way there, for those interested in the notebook model. But the RStudio/MATLAB workbench model is also something worth considering. Some easy to install packages gluing together Incanter, core.matrix, Gorilla REPL, Quil, and perhaps tools/interfaces that don't exist yet, with excellent documentation and guidance, could make a huge difference in adoption. As for broader thoughts coming to mind: My experience has been that R is great for exploration, but is terrible for scaling into bigger systems from an architectural standpoint (but other's might disagree with me). It can also feel rather cumbersome when developing algorithms. Python feels much better along these lines, but also has its own warts as a language (concurrency for example). It's my opinion that the shortcomings of Clojure for data science are much more easily addressable than those of R or python, as they're less about the language itself than things missing from ecosystem which can be added. And I think the value of a language which scales from exploration to production naturally is not something to be undervalued. Chris -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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/vsjUlAWm64g/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: clojure, not the go to for data science
RStudio is really nice! I'm taking some Coursera classes using R, and RStudio is great. Maybe that's because I'm an IDE kind of guy: using Cursive for Clojure, PyCharm for Python, RStudio for R, etc. On Thursday, April 2, 2015 at 5:54:34 PM UTC-4, Jony Hudson wrote: I think the credit here has to go to RStudio for doing such a good job of making an easy to install complete development environment. I'd say just comparing base Clojure to base R, it's a wash. Install java and either download the Clojure jar, or the leiningen script, and you're good to go. Similar effort with R, just install the R distribution. Either way you don't get much more than a REPL prompt. It is possible to get a working, fully-featured Clojure development environment going without *much* more difficulty than RStudio. In fact, I did precisely cover install and setup in two easy videos :-) See http://gorilla-repl.org/videos.html , bottom of the page. I would still say that RStudio deserves kudos here though, as they've made it really easy to get going. And I think there is value in this, as my experience with getting inexperienced programmers started is that they easily get stuck on the little set up details. I'd like to make Gorilla REPL easier to get started with, but haven't figured out how to do that in a way that's compatible with the amount of time I have to work on it! Jony On Thursday, 2 April 2015 22:14:08 UTC+1, Sayth Renshaw wrote: You appear to have vastly misinterpreted my intention regards Emacs. My mention of Emacs (I use emacs with prelude) was not based on my usage but as a perception of those who might be attracted to Clojure For Purely Data Science And wishes to get installed and moving quickly. R offers to get you installed in 2 quick point and click installs and gives you the language and R studio . What would that person think when looking at Clojure? If they saw emacs would they know about prelude, how to configure it with so many configuration options? If someone out organisation was running a data science course would they choose R because they can cover install and setup in 2 easy videos compared to current Clojure options which may be less clear. Sometimes often times onboarding people to a new language is about as much as ease of install or at least making a default set of optiins clear. Could the default set abs best options be made easier to new comers? Sayth Emacs can use the native windowing system on every major platform. It still *looks* like a terminal app, but doesn't have to be one. Pretty much everything you are saying here doesn't apply to Emacs at all, and you would know it's all false if you knew anything about Emacs. On Wednesday, April 1, 2015 at 4:55:08 PM UTC-7, Fluid Dynamics wrote: On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote: The benefit is that Emacs is that its not constantly changing, and it gives you some stability over the years. I like latex, for instance, for the same reason. I can still access a 10 year old document and use it. First of all, there are other posts in this thread complaining about constantly changing stuff breaking things! One such post is by Colin Yates. Second, to the extent that it isn't changing, it is legacy. Which helps to explain the Wordperfect for DOS style of UI, which is dependent on vast numbers of complex key-combinations being memorized by the user, instead of a just-sit-down-and-start-using-it UI like everything originating after, say, 1995 or so has tended to have. Of course, the result is that Wordperfect (and emacs) seemed to require a great deal of specialized training just to accomplish even the most basic tasks, whereas with modern interfaces the way to do such basic tasks (save, open, copy and paste, move around, select, etc.) tends to be obvious and special training can focus exclusively on doing advanced things (scripting, complicated Photoshop filters and tricks, things like those). Legacy also, obviously, tends to present problems in other areas besides UI-boneheadedness: * I18n and l10n * Compatibility, with modern hardware and with modern operating systems, though that can be alleviated by people porting the code * Boneheaded internal limits, along the same general lines as 640K ought to be enough for anybody. It may be unable to use more than a small fraction of what modern hardware can offer it in the way of memory, storage, cores, ... * Accessibility. Interposing a terminal emulator between the app and screen reading software might cause problems, though on the other hand a text mode app may ultimately have advantages in that area too. On the other hand, it may not play well with accessibility tools that rely on standard UI conventions. Anything that responds to some voice command by generating control-V keystrokes to paste, or that relies on the presence of
Re: [ANN] Clojure 1.7.0-alpha6 released
The recent changes to iterate come with an interesting consequence: reducing an iterate multiple times will cause the entire chain of x, (f x), (f (f x)) .. to be recalculated every time. I'd argue that this is not desiderable and a regression (even though probably one considered by design), and that this change in behaviour is going to produce a degradation in performance when the function to iterate actually does some computation rather than being a trivial function like the one used in the benchmarks in the CLJ-1603 ticket (inc) since its result won't be cached. If changing the new behaviour is out of the question I'd suggest to at least document this new behaviour. The docstring of iterate talks about returning a lazy-seq while when used with reduce it is actually a generator. To show what I mean here's a silly example using Threa/sleep to simulate computation: Clojure 1.7.0-alpha5 user= (def a (iterate #(do (Thread/sleep 2) (inc %)) 0)) #'user/a user= (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a)) Elapsed time: 106.385891 msecs nil user= (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a)) Elapsed time: 0.560275 msecs nil Clojure 1.7.0-master-SNAPSHOT user= (def a (iterate #(do (Thread/sleep 2) (inc %)) 0)) #'user/a user= (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a)) Elapsed time: 109.088477 msecs nil user= (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a)) Elapsed time: 109.51494 msecs nil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: clojure, not the go to for data science
Sure. I wasn't under the impression you were knocking it. On the contrary, I appreciate the reflection. As someone who uses (and loves) Clojure for data science, I'm keen to consider what can be done to broaden its adoption in this area. Chris Sent via phone -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: clojure, not the go to for data science
Editors as they apply to data science adoption is certainly relevant, particularly as relates to ease of adoption for beginners. It's easy for an experienced developer to dismiss the difference of ease in adopting something like RStudio vs R by itself; Those with experience already have workflows they're used to (vim/emacs + tmux / whatever), but getting to that point is not trivial. And there are certainly those who come to R and python looking to do data science who have little programming experience. I've seen a lot of this among biologists in particular. The Gorilla REPL does certainly take us a good way there, for those interested in the notebook model. But the RStudio/MATLAB workbench model is also something worth considering. Some easy to install packages gluing together Incanter, core.matrix, Gorilla REPL, Quil, and perhaps tools/interfaces that don't exist yet, with excellent documentation and guidance, could make a huge difference in adoption. As for broader thoughts coming to mind: My experience has been that R is great for exploration, but is terrible for scaling into bigger systems from an architectural standpoint (but other's might disagree with me). It can also feel rather cumbersome when developing algorithms. Python feels much better along these lines, but also has its own warts as a language (concurrency for example). It's my opinion that the shortcomings of Clojure for data science are much more easily addressable than those of R or python, as they're less about the language itself than things missing from ecosystem which can be added. And I think the value of a language which scales from exploration to production naturally is not something to be undervalued. Chris -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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-alpha6 released
Actaully caching makes a difference even with inc and a sequence of just 1000 elements: Clojure 1.7.0-alpha5 user= (def a (iterate inc 0)) #'user/a user= (time (reduce (fn [_ x]) nil (take 1000 a))) Elapsed time: 4.170778 msecs nil user= (time (reduce (fn [_ x]) nil (take 1000 a))) Elapsed time: 1.589569 msecs nil Clojure 1.7.0-master-SNAPSHOT user= (def a (iterate inc 0)) #'user/a user= (time (reduce (fn [_ x]) nil (take 1000 a))) Elapsed time: 4.831726 msecs nil user= (time (reduce (fn [_ x]) nil (take 1000 a))) Elapsed time: 4.058695 msecs nil Nicola Mometto writes: The recent changes to iterate come with an interesting consequence: reducing an iterate multiple times will cause the entire chain of x, (f x), (f (f x)) .. to be recalculated every time. I'd argue that this is not desiderable and a regression (even though probably one considered by design), and that this change in behaviour is going to produce a degradation in performance when the function to iterate actually does some computation rather than being a trivial function like the one used in the benchmarks in the CLJ-1603 ticket (inc) since its result won't be cached. If changing the new behaviour is out of the question I'd suggest to at least document this new behaviour. The docstring of iterate talks about returning a lazy-seq while when used with reduce it is actually a generator. To show what I mean here's a silly example using Threa/sleep to simulate computation: Clojure 1.7.0-alpha5 user= (def a (iterate #(do (Thread/sleep 2) (inc %)) 0)) #'user/a user= (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a)) Elapsed time: 106.385891 msecs nil user= (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a)) Elapsed time: 0.560275 msecs nil Clojure 1.7.0-master-SNAPSHOT user= (def a (iterate #(do (Thread/sleep 2) (inc %)) 0)) #'user/a user= (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a)) Elapsed time: 109.088477 msecs nil user= (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a)) Elapsed time: 109.51494 msecs nil -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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] leaflet-gorilla 0.1.2 released with GeoJSON support
I've been using PostGIS extensively at work for the past year or so and used it intermittently before then. To really get the most out of the system, I would strongly recommend grabbing a copy of PostGIS in Action, 2nd Edition by Regina O. Obe. I feel like I went from a casual user to a power user in one read-through. Happy hacking, ~Gary -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Any chance of a module system being added to the language?
I'd love a module system solving the following problems: 1. Dependency isolation 2. Being able to export vars without having to think about namespace layout in the project 1. Is a serious problem where transitive dependencies on the classpath put consumers in jar hell and force library and tooling authors to either inline code, re-invent the wheel, attempt to run their code in isolated classloaders or turn to source rewriting. 2. Is a nice to have which is solved today by in potemkin's import-vars, but I think this makes sense to include if modules are added to the language. We might get some of this for free whenever project jigsaw gets released, but considering it was due in 2007, originally, I'm hoping this can be solved without the help of Oracle. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: Transducers: sequence versus eduction
On Apr 2, 2015, at 4:09 AM, Tassilo Horn t...@gnu.org wrote: So we can agree on eduction not being a Sequable but still being sequable. :-) Agreed. :) I think my prime use-case is deeply nested mapcatting where the mapcatted function gets an object and returns a java collection, and filtering with usually a quite cheap predicate. E.g. (sequence-or-eduction (comp (mapcat ...) (filter ...) (mapcat ...) ... (filter ...)) coll) That's part of a larger search algorithm which either stops after finding the first match (in which case the resulting sequence is likely not to be realized completely) or runs till all matches are found (in which case all these transducer-produced sequences would be fully realized). If that would make sense, I could use eduction when I know everything will be realized and sequence in the other case (or vice versa). In this case, I don't know that I'd expect much difference. sequence is going to create a TransformerIterator, and wrap it in an chunkedIteratorSeq. Using (seq (eduction ...) should give you exactly the same thing, except calling through an Eduction type. So, I doubt it matters. Ok, thanks. Could you also comment on my other question namely the full realization of intermediate operations in: ,[ Docs of sequence at http://clojure.org/transducers ] | The resulting sequence elements are incrementally computed. These | sequences will consume input incrementally as needed and fully realize | intermediate operations. This behavior differs from the equivalent | operations on lazy sequences. ` Does that mean I'm better off with a traditionally nested map/mapcat/filter cascade instead of transducers in the case where the intermediate mapcatting functions return possibly not so cheap/large lazy sequences and it is likely that I won't fully realize the result sequence or eduction? If you're going to use expanding transformations and not realize all of the results then I think sequences are likely a better choice for you. Hm, I now benchmarked a bit with criterium and measured (sequence (comp (mapcat #(range %)) (mapcat #(range %))) (range 1000)) versus (eduction (comp (mapcat #(range %)) (mapcat #(range %))) (range 1000)) versus the traditional (mapcat #(range %) (mapcat #(range %) (range 1000))) and either taking just the first element of the result using (first ...), taking the first 1000 elements of the result using (dorun (take 1000 ...)), or realizing everything using (dorun ...). These are the timings: | Version| first | first 1000 | everything | |+---++| | transd. (sequence) | 10 μs | 214 μs | 21 sec | | transd. (eduction) | 10 μs | 216 μs | 21 sec | | traditional| 3 μs | 151 μs | 7 sec | So as you see, the traditional version is about three times faster in the first and everything scenario, and just a littlebit faster in the first 1000 scenario. When I test (sequence (comp (mapcat #(range % 1000)) (mapcat #(range % 1000))) (range 1000)) versus (eduction (comp (mapcat #(range % 1000)) (mapcat #(range % 1000))) (range 1000)) versus (mapcat #(range % 1000) (mapcat #(range % 1000) (range 1000))) so that the larger intermediate sequences come first, I get these timings: | Version| first | first 1000 | everything | |+---++| | transd. (sequence) | 24 ms | 24 ms | 21 sec | | transd. (eduction) | 24 ms | 24 ms | 21 sec | | traditional| 4 μs | 102 μs | 7 sec | So here the results are even much worse than above. If you don't fully realize the resulting sequence the traditional version can be many orders of magnitudes faster. I guess that's because of the cited statement above, i.e., intermediate operations are always fully realized. However, at least I had expected that in the case where all elements are realized the transducer version should have been faster than the traditional version which also needs to fully realize all intermediate lazy seqs. Why is it still three times slower? I think my main suggestion here is that you are using a non-reducible source (range) throughout these timings, so transducers have no leverage on the input side. CLJ-1515 will make range reducible and should help a lot on this particular example. So my conclusion is that you cannot use transducers as a kind of drop-in replacement of traditional sequence manipulation functions. They pay off only when you can make very strong assumptions about the sizes and compututation costs of intermediate collections, and I think you cannot
Re: [ANN] Clojure 1.7.0-alpha6 released
Not a bug imho, you're invoking reduce with no init arg so you're forcing the realization of at least two elements in the coll, one for init and one for step -- the step one causes the exception. Ambrose Bonnaire-Sergeant writes: Here's some weird behaviour I found from 1.6. user= (take 1 (iterate zero? true)) (true) user= (reduce (fn [l _] (reduced l)) (iterate zero? true)) ClassCastException java.lang.Boolean cannot be cast to java.lang.Number clojure.lang.Numbers.isZero (Numbers.java:90) Is this a bug, and should this be fixed? Thanks, Ambrose On Wed, Apr 1, 2015 at 10:28 PM, Alex Miller a...@puredanger.com wrote: Thanks! If anyone wants to throw a patch, would love to have one. Must include test ... On Wednesday, April 1, 2015 at 8:14:52 PM UTC-5, Ambrose Bonnaire-Sergeant wrote: http://dev.clojure.org/jira/browse/CLJ-1692 On Wed, Apr 1, 2015 at 9:12 PM, Ambrose Bonnaire-Sergeant abonnair...@gmail.com wrote: Ok. On Wed, Apr 1, 2015 at 9:10 PM, Alex Miller al...@puredanger.com wrote: I would love a jira for the iterate thIng. -- 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. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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] Clojure 1.7.0-alpha6 released
Great to hear feedback like this! I'd be particularly interested if you had any suspicions about the characteristics of the ones that are slower. On Apr 2, 2015, at 3:22 AM, tcrayford tcrayf...@gmail.com wrote: Yeller (yellerapp.com) (which I maintain) has a comprehensive benchmark suite (using criterium, with a heck of a lot of work put into getting real and good results). I've run Yeller's benchmark suite against clojure 1.7 alpha6 - it's pretty comprehensive, and covers a wide range of things. Results are below. Mostly some things got very minorly slower (but not enough to make a real impact for the application), but quite a few benchmarks saw **dramatic** speedups. Given these promising results, I ran Yeller's `test.check` suite for 8 hours in CI, and didn't see any failures, so I've deployed 1.7 alpha6 to production, and haven't seen any issues as of yet. Yeller's build also got ~24 seconds faster, which is super awesome (and it no longer breaks under CLJ-1604 because that patch is in). Much love to all the folk who put time and work into this release. Benchmark names retracted because they're proprietary. Each line is a seperate benchmark, recorded on production level hardware, with the same jvm options/version used in production. Each benchmark is run in its own JVM (because otherwise JIT path dependence will kill you). Benchmarks that were slower under 1.7 alpha6 vs 1.6.0 (with percentage changed amounts): 3.12% 2.62% 2.27% 2.19% 2.17% 2.06% 1.97% 1.43% 1.29% 0.89% 0.74% 0.71% 0.58% 0.45% 0.42% 0.34% 0.27% 0.25% 0.21% 0.2% 0.08% 0.03% Benchmarks that were faster under 1.7 alpha6 vs 1.6.0 (with percentage changed amounts): +0.0% +0.0% +0.01% +0.02% +0.03% +0.03% +0.03% +0.04% +0.04% +0.09% +0.12% +0.16% +0.31% +0.33% +0.52% +0.53% +0.85% +1.74% +1.84% +1.99% +2.14% +2.17% +2.42% +2.96% +3.0% +5.18% +5.36% +9.86% +11.93% +12.41% +14.36% +16.95% +24.71% +53.5% +53.62% +72.07% Thanks again! Super excited about this release. On Wednesday, 1 April 2015 01:51:13 UTC+9, Alex Miller wrote: Clojure 1.7.0-alpha6 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/ - Leiningen: [org.clojure/clojure 1.7.0-alpha6] Regression fixes from previous alphas (and one from 1.6): 1) CLJ-1544 was rolled back and will be investigated for a future release. 2) CLJ-1637 fixed regression with vec on MapEntry 3) CLJ-1663 fixed regression in classloader (affected Cursive) 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) method 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for literal nil arg 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that prevented update Some highlights new in alpha6: ## Transducer-related changes: The LazyTransformer introduced to create lazy transforming sequences has been replaced with a TransformingIterator. This was done to simplify the code around transformations and to make certain use cases around eduction more efficient. ## Faster reduce, iterator, and sequence paths A lot of work has been done across a set of tickets to improve the ability of collections to provide more efficient reduce or iterator performance, and also to make common sequence generators create faster sequence and reduce paths. You should see significant performance in many reduce-related paths (this includes reduce, transduce, into, and anything else built on reduce). Many of those changes also have beneficial sequence performance, so you may see some benefits even in code that does not use transducers. * Most uses of SeqIterator have now been replaced with iterators that directly walk the underlying source for improved efficiency. This includes maps, sets, records, etc. * repeat - now returns a faster sequence with a fast reduce path * cycle - now returns a faster sequence with a fast reduce path * iterate - now returns a faster sequence with a fast reduce path * range - (did not quite make it in, but coming soon...) * keys - iterates directly over the keys of a map, without seq or MapEntry allocation * vals - iterates directly over the vals of a map, without seq or MapEntry allocation * iterator-seq - now creates a chunked sequence when previously it was unchunked * vec and set - were not changed in this release but were set up in a previous alpha to take advantage of the reduce and iterator changes above ## Reader conditionals Reader Conditionals is a new capability to support portable code that can run on multiple Clojure platforms with only small changes. In particular, this feature aims to support the increasingly common case of libraries targeting both Clojure and ClojureScript. Code intended to be common across multiple platforms should use a new supported file extension: .cljc. When
Fwd: [ANN] Clojure 1.7.0-alpha6 released
core.typed 0.2.86 should be 1.7.0-alpha6 compatible now. Thanks, Ambrose On Thu, Apr 2, 2015 at 4:22 AM, tcrayford tcrayf...@gmail.com wrote: Yeller (yellerapp.com) (which I maintain) has a comprehensive benchmark suite (using criterium, with a heck of a lot of work put into getting real and good results). I've run Yeller's benchmark suite against clojure 1.7 alpha6 - it's pretty comprehensive, and covers a wide range of things. Results are below. Mostly some things got very minorly slower (but not enough to make a real impact for the application), but quite a few benchmarks saw **dramatic** speedups. Given these promising results, I ran Yeller's `test.check` suite for 8 hours in CI, and didn't see any failures, so I've deployed 1.7 alpha6 to production, and haven't seen any issues as of yet. Yeller's build also got ~24 seconds faster, which is super awesome (and it no longer breaks under CLJ-1604 because that patch is in). Much love to all the folk who put time and work into this release. Benchmark names retracted because they're proprietary. Each line is a seperate benchmark, recorded on production level hardware, with the same jvm options/version used in production. Each benchmark is run in its own JVM (because otherwise JIT path dependence will kill you). Benchmarks that were slower under 1.7 alpha6 vs 1.6.0 (with percentage changed amounts): 3.12% 2.62% 2.27% 2.19% 2.17% 2.06% 1.97% 1.43% 1.29% 0.89% 0.74% 0.71% 0.58% 0.45% 0.42% 0.34% 0.27% 0.25% 0.21% 0.2% 0.08% 0.03% Benchmarks that were faster under 1.7 alpha6 vs 1.6.0 (with percentage changed amounts): +0.0% +0.0% +0.01% +0.02% +0.03% +0.03% +0.03% +0.04% +0.04% +0.09% +0.12% +0.16% +0.31% +0.33% +0.52% +0.53% +0.85% +1.74% +1.84% +1.99% +2.14% +2.17% +2.42% +2.96% +3.0% +5.18% +5.36% +9.86% +11.93% +12.41% +14.36% +16.95% +24.71% +53.5% +53.62% +72.07% Thanks again! Super excited about this release. On Wednesday, 1 April 2015 01:51:13 UTC+9, Alex Miller wrote: Clojure 1.7.0-alpha6 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1. 7.0-alpha6/ - Leiningen: [org.clojure/clojure 1.7.0-alpha6] Regression fixes from previous alphas (and one from 1.6): 1) CLJ-1544 was rolled back and will be investigated for a future release. 2) CLJ-1637 fixed regression with vec on MapEntry 3) CLJ-1663 fixed regression in classloader (affected Cursive) 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) method 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for literal nil arg 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that prevented update Some highlights new in alpha6: ## Transducer-related changes: The LazyTransformer introduced to create lazy transforming sequences has been replaced with a TransformingIterator. This was done to simplify the code around transformations and to make certain use cases around eduction more efficient. ## Faster reduce, iterator, and sequence paths A lot of work has been done across a set of tickets to improve the ability of collections to provide more efficient reduce or iterator performance, and also to make common sequence generators create faster sequence and reduce paths. You should see significant performance in many reduce-related paths (this includes reduce, transduce, into, and anything else built on reduce). Many of those changes also have beneficial sequence performance, so you may see some benefits even in code that does not use transducers. * Most uses of SeqIterator have now been replaced with iterators that directly walk the underlying source for improved efficiency. This includes maps, sets, records, etc. * repeat - now returns a faster sequence with a fast reduce path * cycle - now returns a faster sequence with a fast reduce path * iterate - now returns a faster sequence with a fast reduce path * range - (did not quite make it in, but coming soon...) * keys - iterates directly over the keys of a map, without seq or MapEntry allocation * vals - iterates directly over the vals of a map, without seq or MapEntry allocation * iterator-seq - now creates a chunked sequence when previously it was unchunked * vec and set - were not changed in this release but were set up in a previous alpha to take advantage of the reduce and iterator changes above ## Reader conditionals Reader Conditionals is a new capability to support portable code that can run on multiple Clojure platforms with only small changes. In particular, this feature aims to support the increasingly common case of libraries targeting both Clojure and ClojureScript. Code intended to be common across multiple platforms should use a new supported file extension: .cljc. When requested to load a namespace, the platform-specific file extension (.clj, .cljs) will be checked prior to .cljc.
Re: Transducers: sequence versus eduction
Alex Miller a...@puredanger.com writes: Hi Alex, Just for fun, I ran the (dorun (sequence (comp (mapcat #(range %)) (mapcat # (range %))) (range 1000))) and eduction version with the CLJ-1515 patch. I saw ~ 20 seconds before and 15 seconds after. But the new version also makes pure seqs better and I saw the full (dorun ...) drop from 6 seconds before to 3 seconds after too. Just a hint of the benefits coming in CLJ-1515. Awesome! Can't wait for alpha7 then. :-) Bye, Tassilo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: Transducers: sequence versus eduction
Just for fun, I ran the (dorun (sequence (comp (mapcat #(range %)) (mapcat #(range %))) (range 1000))) and eduction version with the CLJ-1515 patch. I saw ~20 seconds before and 15 seconds after. But the new version also makes pure seqs better and I saw the full (dorun ...) drop from 6 seconds before to 3 seconds after too. Just a hint of the benefits coming in CLJ-1515. On Thursday, April 2, 2015 at 9:21:08 AM UTC-5, Michał Marczyk wrote: It may be worth noting that while the return value of range is wrapped in lazy-seq and thus isn't itself a clojure.lang.IChunkedSeq, what you get when you realize it is indeed chunked: (contains? (ancestors (class (seq (range 128 clojure.lang.IChunkedSeq) true It doesn't implement c.l.IReduce, but clojure.core.protocols/InternalReduce has an implementation for c.l.IChunkedSeq. At least transduce should be able to take advantage of the InternalReduce implementation (via CollReduce). transduce could be used for short-circuiting search with (reduced …), so it might be a legitimate contender here. Cheers, Michał On 2 April 2015 at 15:38, Tassilo Horn ts...@gnu.org javascript: wrote: Alex Miller al...@puredanger.com javascript: writes: Hi Alex, If you're going to use expanding transformations and not realize all of the results then I think sequences are likely a better choice for you. Ok, I see. However, at least I had expected that in the case where all elements are realized the transducer version should have been faster than the traditional version which also needs to fully realize all intermediate lazy seqs. Why is it still three times slower? I think my main suggestion here is that you are using a non-reducible source (range) throughout these timings, so transducers have no leverage on the input side. CLJ-1515 will make range reducible and should help a lot on this particular example. Well, even if I revamp the (admittedly contrieved) example to have reducible vectors as source and also intermediates (let [v (vec (range 0 1000)) vs (zipmap (range 0 1000) (for [i (range 0 1000)] (vec (range i 1000] (time (dorun (sequence (comp (mapcat (fn [i] (vs i))) (mapcat (fn [i] (vs i v it still takes 18 seconds instead of 21 with lazy seqs produced by range, or just 7 seconds with normal lazy seq functions. In my real scenario, I think there's also no IReduces paths because the mapcat functions either return normal lazy seqs or Java Collections (which are not actually clojure collections). But usually, the transformations are not so freaking expanding as the example above. I benchmarked a bit, and there sometimes using transducers is faster and sometimes it is not. So I've made than configurable (with normal lazy seqs as default) so users can benchmark and then decide, and I don't need to choose for them. :-) Oh, and actually *you* have made that possible by making me aware of (sequence (comp xform*) start-coll) is almost identical to (- start-coll xform*) that is, when my macro computes xforms as if they were meant for transducing, I can also use them traditionally with -. Until now, I've newer used - but before I had implemented the expansion for transducers, I used a for with gensyms for intermediates like: (for [G__1 start-coll G__2 (xform1 G__1) G__3 (xform2 G__2)] G__3) That's pretty much different to generate. But since the xforms for transducers and - are the same, switching between lazy seq fns and transducers is just changing how start-coll and xforms are composed. Awesome! So my conclusion is that you cannot use transducers as a kind of drop-in replacement of traditional sequence manipulation functions. They pay off only when you can make very strong assumptions about the sizes and compututation costs of intermediate collections, and I think you cannot do that in general. Or well, maybe you can when you program an application but you almost certainly cannot when you program a library and thus have no clue about how that's gonna be used by users. Transducers make different trade offs than sequences and there will always be cases where one or the other is a better choice. I really appreciate this thread as highlighting some of the nuances. Yes, thanks a lot for your patience. I appreciate that very much. Transducers break transformations into three parts - source iteration, composed transforms, and output collection. In the case of reducible inputs, multiple transforms, and full realization, transducers can be much faster. If not all of those are in play, then the results are more subtle. One thing I've found in perf testing a lot of stuff is that chunked sequences continually surprise me at how fast they can be. Then maybe I should experiment with
Re: [ANN] leaflet-gorilla 0.1.2 released with GeoJSON support
Absolutely awesome! Finally, an easy-to-use renderer for PostGIS queries. Well done! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: Transducers: sequence versus eduction
Alex Miller a...@puredanger.com writes: Hi Alex, If you're going to use expanding transformations and not realize all of the results then I think sequences are likely a better choice for you. Ok, I see. However, at least I had expected that in the case where all elements are realized the transducer version should have been faster than the traditional version which also needs to fully realize all intermediate lazy seqs. Why is it still three times slower? I think my main suggestion here is that you are using a non-reducible source (range) throughout these timings, so transducers have no leverage on the input side. CLJ-1515 will make range reducible and should help a lot on this particular example. Well, even if I revamp the (admittedly contrieved) example to have reducible vectors as source and also intermediates (let [v (vec (range 0 1000)) vs (zipmap (range 0 1000) (for [i (range 0 1000)] (vec (range i 1000] (time (dorun (sequence (comp (mapcat (fn [i] (vs i))) (mapcat (fn [i] (vs i v it still takes 18 seconds instead of 21 with lazy seqs produced by range, or just 7 seconds with normal lazy seq functions. In my real scenario, I think there's also no IReduces paths because the mapcat functions either return normal lazy seqs or Java Collections (which are not actually clojure collections). But usually, the transformations are not so freaking expanding as the example above. I benchmarked a bit, and there sometimes using transducers is faster and sometimes it is not. So I've made than configurable (with normal lazy seqs as default) so users can benchmark and then decide, and I don't need to choose for them. :-) Oh, and actually *you* have made that possible by making me aware of (sequence (comp xform*) start-coll) is almost identical to (- start-coll xform*) that is, when my macro computes xforms as if they were meant for transducing, I can also use them traditionally with -. Until now, I've newer used - but before I had implemented the expansion for transducers, I used a for with gensyms for intermediates like: (for [G__1 start-coll G__2 (xform1 G__1) G__3 (xform2 G__2)] G__3) That's pretty much different to generate. But since the xforms for transducers and - are the same, switching between lazy seq fns and transducers is just changing how start-coll and xforms are composed. Awesome! So my conclusion is that you cannot use transducers as a kind of drop-in replacement of traditional sequence manipulation functions. They pay off only when you can make very strong assumptions about the sizes and compututation costs of intermediate collections, and I think you cannot do that in general. Or well, maybe you can when you program an application but you almost certainly cannot when you program a library and thus have no clue about how that's gonna be used by users. Transducers make different trade offs than sequences and there will always be cases where one or the other is a better choice. I really appreciate this thread as highlighting some of the nuances. Yes, thanks a lot for your patience. I appreciate that very much. Transducers break transformations into three parts - source iteration, composed transforms, and output collection. In the case of reducible inputs, multiple transforms, and full realization, transducers can be much faster. If not all of those are in play, then the results are more subtle. One thing I've found in perf testing a lot of stuff is that chunked sequences continually surprise me at how fast they can be. Then maybe I should experiment with chunged seqs. Bye, Tassilo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: Any chance of a module system being added to the language?
I'm not really in a position to say which implementation is superior. We tried both source re-writing and an isolated classloader for refactor-nrepl and I couldn't get the classpath to work right (we want our own deps isolated, but also access to the project's deps, resources etc for refactorings) so we ended up with source re-writing. But I do feel the pain of this problem, and judging by the issues I see pop up on clj projects on github others are suffering too. On Thursday, April 2, 2015 at 3:28:05 PM UTC+2, Andy Fingerhut wrote: Dependency isolation without isolated class loaders or source rewriting would be interesting, but how would you propose to achieve dependency isolation without using either of those techniques? Or perhaps a solution where the module system did the source level rewriting for you 'under the hood' would be acceptable? Andy On Thu, Apr 2, 2015 at 4:05 AM, Lars Andersen ex...@expez.com javascript: wrote: I'd love a module system solving the following problems: 1. Dependency isolation 2. Being able to export vars without having to think about namespace layout in the project 1. Is a serious problem where transitive dependencies on the classpath put consumers in jar hell and force library and tooling authors to either inline code, re-invent the wheel, attempt to run their code in isolated classloaders or turn to source rewriting. 2. Is a nice to have which is solved today by in potemkin's import-vars, but I think this makes sense to include if modules are added to the language. We might get some of this for free whenever project jigsaw gets released, but considering it was due in 2007, originally, I'm hoping this can be solved without the help of Oracle. -- 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. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: Any chance of a module system being added to the language?
I agree that it's important to think about how you should organize your namespaces, but it would be nice present a clean outward API without disturbing the implementation too much. I think the rational for import-vars in the potemkin readme makes a good case: https://github.com/ztellman/potemkin#import-vars On Thursday, April 2, 2015 at 4:11:09 PM UTC+2, Alex Miller wrote: It's possible we could make use of Java's module system if it ever actually gets released in Java 9. While I followed it pretty extensively when they first started discussing it (7 or 8 years ago!) I have not been keeping up on it lately. Some people have used OSGi with Clojure but I don't gather that it's a picnic. Designing a good module system, especially one that takes into account Java's classloader architecture, is a challenging task. Personally, I think it's probably useful to think about your namespace layout, so I'm not really looking to get rid of the thinking part. :) On Thursday, April 2, 2015 at 6:05:25 AM UTC-5, Lars Andersen wrote: I'd love a module system solving the following problems: 1. Dependency isolation 2. Being able to export vars without having to think about namespace layout in the project 1. Is a serious problem where transitive dependencies on the classpath put consumers in jar hell and force library and tooling authors to either inline code, re-invent the wheel, attempt to run their code in isolated classloaders or turn to source rewriting. 2. Is a nice to have which is solved today by in potemkin's import-vars, but I think this makes sense to include if modules are added to the language. We might get some of this for free whenever project jigsaw gets released, but considering it was due in 2007, originally, I'm hoping this can be solved without the help of Oracle. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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] clj-amp 0.9.0
I am pleased to announce the release of clj-amp 0.9.0[1][2], a Clojure implementation of the AMP[3] protocol (the reference implementation of which is found in the Twisted networking framework for Python). clj-amp is implemented on top of Aleph/Manifold/Gloss; Special thanks to Zach Tellman for the assistance on the Aleph mailing list in getting the low-level protocol working. While AMP is currently a somewhat obscure protocol, if you need to interoperate with an existing system or service using it, this library should prove useful. It may also be of interest for anyone implementing a new system and needing an asynchronous[4] RPC-type protocol with support in multiple languages/frameworks, although there are other, more popular choices that might be more suitable. Despite this being the first release, clj-amp is essentially feature complete: you can define commands using any of the standard argument types, issue and respond to calls, and define new argument types of your own if necessary. The 0.9.0 version number reflects my reluctance to designate this 1.0.0 for the following reasons: * Lack of users and real-world testing: the project was just released. * API instability: while I do not have any immediate plans to break API compatibility, I would like to reserve the right to make API changes based on initial feedback from users (assuming anyone uses it...) in order to correct any glaring issues with the API that may be discovered. * Minimal test coverage and documentation: I would still like to expand the test coverage to include more specimens of AMP encodings, as well as expand the documentation. * Depending on alpha and SNAPSHOT versions of things: this will be fixed as the various things I'm relying on make it into release versions. Any feedback on the API as well as the documentation would be greatly appreciated. [1] https://github.com/mithrandi/clj-amp [2] https://clojars.org/clj-amp [3] http://amp-protocol.net/ [4] AMP is both asynchronous, in that requests and responses can be interleaved and calls (commands, in AMP terminology) can be overlapped; it is also symmetric, in that the client and server can both issue and respond to requests, should this be desired. -- mithrandi, i Ainil en-Balandor, a faer Ambar -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: Any chance of a module system being added to the language?
I did it with protege-nrepl. Protege is a tool build on eclipse, which is build on OSGi. protege-nrepl embed clojure inside Protege, and enables it to put up an NREPL server. I found it to be a bit of a nightmare to be honest. The key problem was was that for protege-nrepl to be useful, I need to able to expand the running Clojure dynamically. Otherwise, I have to bundle all of the clojure that I want to use with protege. Theoretically, this should be easy with pomegranate, but in practice this fails because OSGi requires the package to state before what classes a package is going to use when the OSGi package is built. But I don't know what those are! The eventually solution was to add this DynamicImport-Package*/DynamicImport-Package to my maven config. https://github.com/phillord/protege-nrepl/blob/master/nrepl-plugin/pom.xml This solves the problem, but AFAICT defeats the point of OSGi since now there is no isolation. Phil Colin Yates colin.ya...@gmail.com writes: Do you have any references to OSGi and Clojure? On 2 April 2015 at 15:11, Alex Miller a...@puredanger.com wrote: It's possible we could make use of Java's module system if it ever actually gets released in Java 9. While I followed it pretty extensively when they first started discussing it (7 or 8 years ago!) I have not been keeping up on it lately. Some people have used OSGi with Clojure but I don't gather that it's a picnic. Designing a good module system, especially one that takes into account Java's classloader architecture, is a challenging task. Personally, I think it's probably useful to think about your namespace layout, so I'm not really looking to get rid of the thinking part. :) On Thursday, April 2, 2015 at 6:05:25 AM UTC-5, Lars Andersen wrote: I'd love a module system solving the following problems: 1. Dependency isolation 2. Being able to export vars without having to think about namespace layout in the project 1. Is a serious problem where transitive dependencies on the classpath put consumers in jar hell and force library and tooling authors to either inline code, re-invent the wheel, attempt to run their code in isolated classloaders or turn to source rewriting. 2. Is a nice to have which is solved today by in potemkin's import-vars, but I think this makes sense to include if modules are added to the language. We might get some of this for free whenever project jigsaw gets released, but considering it was due in 2007, originally, I'm hoping this can be solved without the help of Oracle. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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. -- Phillip Lord, Phone: +44 (0) 191 208 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: clojure, not the go to for data science
Please stop. The amount of misinformation you are spreading about Emacs on this mailing list is deeply irresponsible and belies a very clear lack of understanding about how this software works. All of your concerns about internationalization (supported), accessibility to text readers (emacspeak), resource limits (full system utilization), and compatibility with modern hardware, operating systems, and window managers (GTK interface) are unfounded. As it has been noted numerous times already by others, this thread is about Clojure and data science, not about your dislike of the Emacs user interface. Some people (such as myself) prefer a text-mode interface driven by keybindings over a mouse-driven graphical interface. That is an aesthetic and productivity-based choice. Please respect your fellow programmers and go write some software rather than continuing this diatribe. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: clojure, not the go to for data science
Dear lord... May I please echo the imploration that folks take the editor flame war else where. And while I'm at it, Vim FTW... On the note of DATA SCIENCE... I agree that Clojure has some catching up to do, both in tooling and awareness/perception. But it also has some major strengths in this area. Companies like the Climate Corp and Prismatic are certainly using Clojure for data analysis and ML to good effect, and I think they might have a lot to say about it's strengths. As for Incanter, I would definitely recommend upgrading, primarily because 2.0 (I believe) will be using core.matrix for it's matrix arithmetic and datasets. This certainly is a major refactor, but one that brings it in better pairing with what's going on in the rest of the Clojure community. I think part of why Incanter hasn't seen much pumping or visible change lately is because folks have been scrambling to get this new release ready, which I commend. Chris On Wednesday, April 1, 2015 at 6:21:20 AM UTC-7, Joseph Guhlin wrote: I haven't tested 1.9 or 2.0 yet, but I'm working with an existing project that depends in incanter and I don't think there is a return on investment for updating it at this time (only using a few features). If I was starting now, I would go with 1.9 for my data analysis. --Joseph On Tuesday, March 31, 2015 at 7:36:11 AM UTC-5, Erebus Mons wrote: Joseph Guhlin wrote: Incanter gets your pretty far, especially when combined with Gorilla REPL, but all the tools and features aren't quite there yet, but progress is being made. Incanter is undergoing major change with the migration to core.matrix, and a break in the API. Has anybody of you tested incanter 1.9? Are there plans for the release date of the stable 2.0? And how different is incanter 2.x from incanter 1.5x? In other words, if you were tempted to start data analysis in clojure now, what would you do: a) take incanter 1.9 b) take incanter 1.5.6 c) wait a few more weeks/months for the release of incanter 2.0? Best, EM -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: Any chance of a module system being added to the language?
Dependency isolation without isolated class loaders or source rewriting would be interesting, but how would you propose to achieve dependency isolation without using either of those techniques? Or perhaps a solution where the module system did the source level rewriting for you 'under the hood' would be acceptable? Andy On Thu, Apr 2, 2015 at 4:05 AM, Lars Andersen ex...@expez.com wrote: I'd love a module system solving the following problems: 1. Dependency isolation 2. Being able to export vars without having to think about namespace layout in the project 1. Is a serious problem where transitive dependencies on the classpath put consumers in jar hell and force library and tooling authors to either inline code, re-invent the wheel, attempt to run their code in isolated classloaders or turn to source rewriting. 2. Is a nice to have which is solved today by in potemkin's import-vars, but I think this makes sense to include if modules are added to the language. We might get some of this for free whenever project jigsaw gets released, but considering it was due in 2007, originally, I'm hoping this can be solved without the help of Oracle. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: Debugging in CIDER
From a look at how it works, is it fair to say that this is mostly designed for debugging a function at a time You can instrument as many functions as you want with C-u C-M-x, and debugger will seamlessly jump between them as they're getting executed. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: Any chance of a module system being added to the language?
It's possible we could make use of Java's module system if it ever actually gets released in Java 9. While I followed it pretty extensively when they first started discussing it (7 or 8 years ago!) I have not been keeping up on it lately. Some people have used OSGi with Clojure but I don't gather that it's a picnic. Designing a good module system, especially one that takes into account Java's classloader architecture, is a challenging task. Personally, I think it's probably useful to think about your namespace layout, so I'm not really looking to get rid of the thinking part. :) On Thursday, April 2, 2015 at 6:05:25 AM UTC-5, Lars Andersen wrote: I'd love a module system solving the following problems: 1. Dependency isolation 2. Being able to export vars without having to think about namespace layout in the project 1. Is a serious problem where transitive dependencies on the classpath put consumers in jar hell and force library and tooling authors to either inline code, re-invent the wheel, attempt to run their code in isolated classloaders or turn to source rewriting. 2. Is a nice to have which is solved today by in potemkin's import-vars, but I think this makes sense to include if modules are added to the language. We might get some of this for free whenever project jigsaw gets released, but considering it was due in 2007, originally, I'm hoping this can be solved without the help of Oracle. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: Transducers: sequence versus eduction
It may be worth noting that while the return value of range is wrapped in lazy-seq and thus isn't itself a clojure.lang.IChunkedSeq, what you get when you realize it is indeed chunked: (contains? (ancestors (class (seq (range 128 clojure.lang.IChunkedSeq) true It doesn't implement c.l.IReduce, but clojure.core.protocols/InternalReduce has an implementation for c.l.IChunkedSeq. At least transduce should be able to take advantage of the InternalReduce implementation (via CollReduce). transduce could be used for short-circuiting search with (reduced …), so it might be a legitimate contender here. Cheers, Michał On 2 April 2015 at 15:38, Tassilo Horn t...@gnu.org wrote: Alex Miller a...@puredanger.com writes: Hi Alex, If you're going to use expanding transformations and not realize all of the results then I think sequences are likely a better choice for you. Ok, I see. However, at least I had expected that in the case where all elements are realized the transducer version should have been faster than the traditional version which also needs to fully realize all intermediate lazy seqs. Why is it still three times slower? I think my main suggestion here is that you are using a non-reducible source (range) throughout these timings, so transducers have no leverage on the input side. CLJ-1515 will make range reducible and should help a lot on this particular example. Well, even if I revamp the (admittedly contrieved) example to have reducible vectors as source and also intermediates (let [v (vec (range 0 1000)) vs (zipmap (range 0 1000) (for [i (range 0 1000)] (vec (range i 1000] (time (dorun (sequence (comp (mapcat (fn [i] (vs i))) (mapcat (fn [i] (vs i v it still takes 18 seconds instead of 21 with lazy seqs produced by range, or just 7 seconds with normal lazy seq functions. In my real scenario, I think there's also no IReduces paths because the mapcat functions either return normal lazy seqs or Java Collections (which are not actually clojure collections). But usually, the transformations are not so freaking expanding as the example above. I benchmarked a bit, and there sometimes using transducers is faster and sometimes it is not. So I've made than configurable (with normal lazy seqs as default) so users can benchmark and then decide, and I don't need to choose for them. :-) Oh, and actually *you* have made that possible by making me aware of (sequence (comp xform*) start-coll) is almost identical to (- start-coll xform*) that is, when my macro computes xforms as if they were meant for transducing, I can also use them traditionally with -. Until now, I've newer used - but before I had implemented the expansion for transducers, I used a for with gensyms for intermediates like: (for [G__1 start-coll G__2 (xform1 G__1) G__3 (xform2 G__2)] G__3) That's pretty much different to generate. But since the xforms for transducers and - are the same, switching between lazy seq fns and transducers is just changing how start-coll and xforms are composed. Awesome! So my conclusion is that you cannot use transducers as a kind of drop-in replacement of traditional sequence manipulation functions. They pay off only when you can make very strong assumptions about the sizes and compututation costs of intermediate collections, and I think you cannot do that in general. Or well, maybe you can when you program an application but you almost certainly cannot when you program a library and thus have no clue about how that's gonna be used by users. Transducers make different trade offs than sequences and there will always be cases where one or the other is a better choice. I really appreciate this thread as highlighting some of the nuances. Yes, thanks a lot for your patience. I appreciate that very much. Transducers break transformations into three parts - source iteration, composed transforms, and output collection. In the case of reducible inputs, multiple transforms, and full realization, transducers can be much faster. If not all of those are in play, then the results are more subtle. One thing I've found in perf testing a lot of stuff is that chunked sequences continually surprise me at how fast they can be. Then maybe I should experiment with chunged seqs. Bye, Tassilo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are
Re: Any chance of a module system being added to the language?
Counterclockwise is an eclipse plugin, and thus an Osgi bundle. There has been some effort to try to fill the gap between Osgi and clojure ( search github for the work of aav on clojure-osgi). I have tried hard to follow these steps of purity by separating things in different eclipse plugins. But overall is was a niche of bugs with no real advantages. So now CCW just use one eclipse plugin, embeds all its dependencies inside the plugin, and let eclipse manage its classpath. Still, this is not an easy solution, because Osgi bundles are started from the Osgi framework and when trying to load new clojure code, one needs to take care that the right classloaders are set in the thread context classloader, some clojure RT dyn vars, etc. Le jeudi 2 avril 2015, Colin Yates colin.ya...@gmail.com a écrit : Do you have any references to OSGi and Clojure? On 2 April 2015 at 15:11, Alex Miller a...@puredanger.com javascript:; wrote: It's possible we could make use of Java's module system if it ever actually gets released in Java 9. While I followed it pretty extensively when they first started discussing it (7 or 8 years ago!) I have not been keeping up on it lately. Some people have used OSGi with Clojure but I don't gather that it's a picnic. Designing a good module system, especially one that takes into account Java's classloader architecture, is a challenging task. Personally, I think it's probably useful to think about your namespace layout, so I'm not really looking to get rid of the thinking part. :) On Thursday, April 2, 2015 at 6:05:25 AM UTC-5, Lars Andersen wrote: I'd love a module system solving the following problems: 1. Dependency isolation 2. Being able to export vars without having to think about namespace layout in the project 1. Is a serious problem where transitive dependencies on the classpath put consumers in jar hell and force library and tooling authors to either inline code, re-invent the wheel, attempt to run their code in isolated classloaders or turn to source rewriting. 2. Is a nice to have which is solved today by in potemkin's import-vars, but I think this makes sense to include if modules are added to the language. We might get some of this for free whenever project jigsaw gets released, but considering it was due in 2007, originally, I'm hoping this can be solved without the help of Oracle. -- You 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:; Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com javascript:;. 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 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+unsubscr...@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+unsubscr...@googlegroups.com javascript:;. For more options, visit https://groups.google.com/d/optout. -- Laurent Petit -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: Immutant survey
Here are the results: http://immutant.org/news/2015/04/02/survey-results/ Thanks! Jim On Thursday, March 12, 2015 at 12:11:27 PM UTC-4, jaju wrote: Very curious to know - how's the response been? A happy user, jaju On Fri, Mar 6, 2015 at 8:01 PM, Jim Crossley jcros...@gmail.com javascript: wrote: Hi friends, If you have any opinion about Immutant [1], would you please take a few moments to fill out this short survey? http://goo.gl/forms/syYnYtpM4v We're trying to get a sense of how Immutant is being used. Thanks so much! Jim [1] http://immutant.org -- 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. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: Any chance of a module system being added to the language?
Do you have any references to OSGi and Clojure? On 2 April 2015 at 15:11, Alex Miller a...@puredanger.com wrote: It's possible we could make use of Java's module system if it ever actually gets released in Java 9. While I followed it pretty extensively when they first started discussing it (7 or 8 years ago!) I have not been keeping up on it lately. Some people have used OSGi with Clojure but I don't gather that it's a picnic. Designing a good module system, especially one that takes into account Java's classloader architecture, is a challenging task. Personally, I think it's probably useful to think about your namespace layout, so I'm not really looking to get rid of the thinking part. :) On Thursday, April 2, 2015 at 6:05:25 AM UTC-5, Lars Andersen wrote: I'd love a module system solving the following problems: 1. Dependency isolation 2. Being able to export vars without having to think about namespace layout in the project 1. Is a serious problem where transitive dependencies on the classpath put consumers in jar hell and force library and tooling authors to either inline code, re-invent the wheel, attempt to run their code in isolated classloaders or turn to source rewriting. 2. Is a nice to have which is solved today by in potemkin's import-vars, but I think this makes sense to include if modules are added to the language. We might get some of this for free whenever project jigsaw gets released, but considering it was due in 2007, originally, I'm hoping this can be solved without the help of Oracle. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: clojure, not the go to for data science
Emacs can use the native windowing system on every major platform. It still *looks* like a terminal app, but doesn't have to be one. Pretty much everything you are saying here doesn't apply to Emacs at all, and you would know it's all false if you knew anything about Emacs. On Wednesday, April 1, 2015 at 4:55:08 PM UTC-7, Fluid Dynamics wrote: On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote: The benefit is that Emacs is that its not constantly changing, and it gives you some stability over the years. I like latex, for instance, for the same reason. I can still access a 10 year old document and use it. First of all, there are other posts in this thread complaining about constantly changing stuff breaking things! One such post is by Colin Yates. Second, to the extent that it isn't changing, it is legacy. Which helps to explain the Wordperfect for DOS style of UI, which is dependent on vast numbers of complex key-combinations being memorized by the user, instead of a just-sit-down-and-start-using-it UI like everything originating after, say, 1995 or so has tended to have. Of course, the result is that Wordperfect (and emacs) seemed to require a great deal of specialized training just to accomplish even the most basic tasks, whereas with modern interfaces the way to do such basic tasks (save, open, copy and paste, move around, select, etc.) tends to be obvious and special training can focus exclusively on doing advanced things (scripting, complicated Photoshop filters and tricks, things like those). Legacy also, obviously, tends to present problems in other areas besides UI-boneheadedness: * I18n and l10n * Compatibility, with modern hardware and with modern operating systems, though that can be alleviated by people porting the code * Boneheaded internal limits, along the same general lines as 640K ought to be enough for anybody. It may be unable to use more than a small fraction of what modern hardware can offer it in the way of memory, storage, cores, ... * Accessibility. Interposing a terminal emulator between the app and screen reading software might cause problems, though on the other hand a text mode app may ultimately have advantages in that area too. On the other hand, it may not play well with accessibility tools that rely on standard UI conventions. Anything that responds to some voice command by generating control-V keystrokes to paste, or that relies on the presence of normal menus and/or mouse support is going to blow up spectacularly when used with 1980s-vintage Unix (or MS-DOS) software, or at best will end up controlling the xterm/Command Prompt window instead of the underlying app. * Interoperation with other (non-operating-system) software. On Windows it won't speak OLE, DDE, OCX, or etc., and copying text in it and attempting to paste into something else (web browser, calculator, etc.) is doomed to failure. This is a general problem with pre-window-system software, much like the stuff listed under Accessibility, with no easy solution. Terminal emulators tend to provide some way to copy from their display into the host-native clipboard, but it tends to be clunky (the Windows command prompt appears to require mouse use, with no keyboard shortcuts) and runs into the obvious difficulties as soon as you want to copy more than will fit on one screen. Ironically, really primitive stuff like ls and dir that just dump possibly-paginated noninteractive listings to the term are easier to make big copies from than text-mode, interactive applications like screen-oriented editors, because you can copy from the backscroll buffer of the terminal emulator in the first case. Pre-window-system *graphical* apps are the absolute worst, e.g. later, WYSIWYG word processor versions on MS-DOS, or pre-window-system X applications. No internal support for the host clipboard and, at the same time, nothing the emulator will recognize as text, meaning if you try to native copy and paste you'll end up with a PNG or something. OCR might work on that, if you can find cheap or free OCR software that's any good. Your better bet would be to save the document as some format that can be read by a native windowed app and then open the file in that, then copy, and at that point you might as well edit in the native windowed app and throw out the legacy cruft entirely, since you'll have to deal with the native app anyway, and the cost of switching between them constantly, reloading in the native app so it sees changes, and re-locating the places you want to copy from in the native app will quickly grow to outweigh any advantage the legacy app might somehow have due to some feature it has that you haven't found in any native app. Put more simply, there are giant costs to not playing well with others, and these are inevitably incurred by all applications developed prior
Re: Immutant survey
Thanks for the summary! I just want to publicly say thanks for Immutant and the hard work you, Toby, and others put into it. It's a fantastic set of tools and libraries and deserves more recognition than it receives. Cheers, Paul -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: clojure, not the go to for data science
Clojure is an Amazing tool for data science. If people are slow to realize this, that is their disadvantage. The premise that Clojure hasn't developed as a go to for data science simply doesn't ring true to me at all. There are numerous examples of Clojure use for data science, there are books about it, there are youtube videos about it, there are practitioners, there is Incanter, there are Transducers, there are Notebooks (Gorilla is awesome), there are Java libraries, there are wrapper Clojure libraries, there are a lot of useful tools. Clojure is my go to for data science and I often use it either directly, or to manage runs using fast tools (like vw), or to prepare SQL-izations of data etc... (Btw, your SQL often runs as easily in Postgres/Redshift/Hive/Spark with minimal changes if any if you need to scale etc... If you treat your SQL the way you treat HTML, let your customs functions write it, you get a lot of analytic power that is not tied to any particular database). There is Clojurescript for visualization... There is so much that I am certain I am forgetting to mention some of it. Also, Big +1 for emacs use (cider is awesome! I rarely want to touch a mouse... ) Thanks for an amazing, innovative Emacs and Clojure commuity!! -Avram The sky is the limit. On Sunday, March 29, 2015 at 2:55:34 AM UTC-7, Sayth Renshaw wrote: Hi I last learned clojure in 1.2. Just curious why Clojure hasn't developed as a go to for data science? It never seems to get a mention R,Python and now Julia get the attention. By design it would appear that Clojure would be a good fit. Is it a lack of libraries, ease of install, no good default environment (R Rstudio, IPython ) where as you would need to use emacs with clojure, or is there just a better default use of Clojure? Sayth -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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] leaflet-gorilla 0.1.2 released with GeoJSON support
This is lovely. Am now inspired to get around to learning PostGIS over the easter break! Jony On Wednesday, 1 April 2015 23:19:31 UTC+1, John Wiseman wrote: I've add GeoJSON support to leaflet-gorilla, which makes it easy to use with PostGIS. Example worksheet online (the PostGIS example is at the bottom): http://viewer.gorilla-repl.org/view.html?source=githubuser=wisemanrepo=leaflet-gorillapath=example-worksheet.cljw Code: https://github.com/wiseman/leaflet-gorilla I've also attached a screenshot showing a GeoJSON example. John [image: Inline image 1] -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: Debugging in CIDER
Kudos to Bozhidar and all CIDER contributors! I am hyped for CIDER 0.9 On Sunday, 29 March 2015 00:46:33 UTC+7, Bozhidar Batsov wrote: Hey everyone, Just wanted to let you know that the most requested feature for CIDER (a debugger, in case you're wondering) has just landed in the master branch ( https://github.com/clojure-emacs/cider/pull/1019#issuecomment-87240470). The new CIDER debugger is inspired by edebug (Emacs's own debugger) and based on https://github.com/razum2um/clj-debugger It's not super fancy and there's clearly room for improvement in both clj-debugger and CIDER itself, but it's a pretty good first step. Please, take the new debugger out for a spin and let us know what do you think about it. You might also report any problems you've encountered. :-) If all is well, CIDER 0.9 will probably be released in a week or so. P.S. Thanks, Artur (https://github.com/Malabarba), for all the hard work on the debugger! You've once again showed the power of the OSS! There's nothing we can't build together! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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] leaflet-gorilla 0.1.2 released with GeoJSON support
FYI I only first used PostGIS a few days ago, so it's not hard to at least get started with the basics. John On Thu, Apr 2, 2015 at 9:39 AM, Jony Hudson jonyepsi...@gmail.com wrote: This is lovely. Am now inspired to get around to learning PostGIS over the easter break! Jony On Wednesday, 1 April 2015 23:19:31 UTC+1, John Wiseman wrote: I've add GeoJSON support to leaflet-gorilla, which makes it easy to use with PostGIS. Example worksheet online (the PostGIS example is at the bottom): http://viewer.gorilla-repl.org/view.html?source=github; user=wisemanrepo=leaflet-gorillapath=example-worksheet.cljw Code: https://github.com/wiseman/leaflet-gorilla I've also attached a screenshot showing a GeoJSON example. John [image: Inline image 1] -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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] Clojure 1.7.0-alpha6 released
Yup. Fixed. On Thursday, April 2, 2015 at 1:24:46 PM UTC-5, Leon Grapenthin wrote: http://dev.clojure.org/display/design/Reader+Conditionals First use-case Platform-specific require/import: Shouldn't the reader conditional example be: (ns cemerick.pprng #?(:cljs (:require math.seedrandom [cljs.core :as lang])) #?@(:clj [ (:require [clojure.core :as lang]) (:import java.util.Random)]) (:refer-clojure :exclude (double float int long boolean))) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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-alpha6 released
http://dev.clojure.org/display/design/Reader+Conditionals First use-case Platform-specific require/import: Shouldn't the reader conditional example be: (ns cemerick.pprng #?(:cljs (:require math.seedrandom [cljs.core :as lang])) #?@(:clj [ (:require [clojure.core :as lang]) (:import java.util.Random)]) (:refer-clojure :exclude (double float int long boolean))) On Tuesday, March 31, 2015 at 6:51:13 PM UTC+2, Alex Miller wrote: Clojure 1.7.0-alpha6 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/ - Leiningen: [org.clojure/clojure 1.7.0-alpha6] Regression fixes from previous alphas (and one from 1.6): 1) CLJ-1544 was rolled back and will be investigated for a future release. 2) CLJ-1637 fixed regression with vec on MapEntry 3) CLJ-1663 fixed regression in classloader (affected Cursive) 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) method 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for literal nil arg 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that prevented update Some highlights new in alpha6: ## Transducer-related changes: The LazyTransformer introduced to create lazy transforming sequences has been replaced with a TransformingIterator. This was done to simplify the code around transformations and to make certain use cases around eduction more efficient. ## Faster reduce, iterator, and sequence paths A lot of work has been done across a set of tickets to improve the ability of collections to provide more efficient reduce or iterator performance, and also to make common sequence generators create faster sequence and reduce paths. You should see significant performance in many reduce-related paths (this includes reduce, transduce, into, and anything else built on reduce). Many of those changes also have beneficial sequence performance, so you may see some benefits even in code that does not use transducers. * Most uses of SeqIterator have now been replaced with iterators that directly walk the underlying source for improved efficiency. This includes maps, sets, records, etc. * repeat - now returns a faster sequence with a fast reduce path * cycle - now returns a faster sequence with a fast reduce path * iterate - now returns a faster sequence with a fast reduce path * range - (did not quite make it in, but coming soon...) * keys - iterates directly over the keys of a map, without seq or MapEntry allocation * vals - iterates directly over the vals of a map, without seq or MapEntry allocation * iterator-seq - now creates a chunked sequence when previously it was unchunked * vec and set - were not changed in this release but were set up in a previous alpha to take advantage of the reduce and iterator changes above ## Reader conditionals Reader Conditionals is a new capability to support portable code that can run on multiple Clojure platforms with only small changes. In particular, this feature aims to support the increasingly common case of libraries targeting both Clojure and ClojureScript. Code intended to be common across multiple platforms should use a new supported file extension: .cljc. When requested to load a namespace, the platform-specific file extension (.clj, .cljs) will be checked prior to .cljc. A new reader form can be used to specify reader conditional code in cljc files (and *only* cljc files). Each platform defines a feature identifying the platform (:clj, :cljs, :cljr). The reader conditional specifies code that is read conditionally based on the feature/ Form #? takes a list of alternating feature and expression. These are checked like cond and the selected expression is read and returned. Other branches are unread. If no branch is selected, the reader reads nothing (not nil, but literally as if reading ). An optional :default branch can be used as a fallthrough. Reader conditional with 2 features and a default: #?(:clj Double/NaN :cljsjs/NaN :default nil) There is also a reader conditional splicing form. The evaluated expression should be sequential and will be spliced into the surrounded code, similar to unqoute-splicing. For example: [1 2 #?@(:clj [3 4] :cljs [5 6])] This form would read as [1 2 3 4] on Clojure, [1 2 5 6] on ClojureScript, and [1 2] on any other platform. Additionally, the reader can now be invoked with options for the features to use and how to interpret reader conditionals. By default, reader conditionals are not allowed, but that can be turned on, or a preserve mode can be used to preserve all branches (most likely useful for tooling or source transforms). In the preserve mode, the reader conditional itself and any tagged literals within the unselected branches are returned as tagged literal data. For more information, see:
Re: Debugging in CIDER
Great, thanks Artur, very interesting. Very nice work! On 2 April 2015 at 21:02, Artur Malabarba arturmalaba...@gmail.com wrote: From a look at how it works, is it fair to say that this is mostly designed for debugging a function at a time You can instrument as many functions as you want with C-u C-M-x, and debugger will seamlessly jump between them as they're getting executed. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from 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: clojure, not the go to for data science
For python notebooks there is an ein plugin which integrates notebooks in emacs. Giving features of both. Doesn't address Rstudio ease but it may allow greater features for gorilla for relatively smaller effort. On Fri, 3 Apr 2015 8:54 AM Jony Hudson wrote: I think the credit here has to go to RStudio for doing such a good job of making an easy to install complete development environment. I'd say just comparing base Clojure to base R, it's a wash. Install java and either download the Clojure jar, or the leiningen script, and you're good to go. Similar effort with R, just install the R distribution. Either way you don't get much more than a REPL prompt. It is possible to get a working, fully-featured Clojure development environment going without *much* more difficulty than RStudio. In fact, I did precisely cover install and setup in two easy videos :-) See http://gorilla-repl.org/videos.html , bottom of the page. I would still say that RStudio deserves kudos here though, as they've made it really easy to get going. And I think there is value in this, as my experience with getting inexperienced programmers started is that they easily get stuck on the little set up details. I'd like to make Gorilla REPL easier to get started with, but haven't figured out how to do that in a way that's compatible with the amount of time I have to work on it! Jony On Thursday, 2 April 2015 22:14:08 UTC+1, Sayth Renshaw wrote: You appear to have vastly misinterpreted my intention regards Emacs. My mention of Emacs (I use emacs with prelude) was not based on my usage but as a perception of those who might be attracted to Clojure For Purely Data Science And wishes to get installed and moving quickly. R offers to get you installed in 2 quick point and click installs and gives you the language and R studio . What would that person think when looking at Clojure? If they saw emacs would they know about prelude, how to configure it with so many configuration options? If someone out organisation was running a data science course would they choose R because they can cover install and setup in 2 easy videos compared to current Clojure options which may be less clear. Sometimes often times onboarding people to a new language is about as much as ease of install or at least making a default set of optiins clear. Could the default set abs best options be made easier to new comers? Sayth Emacs can use the native windowing system on every major platform. It still *looks* like a terminal app, but doesn't have to be one. Pretty much everything you are saying here doesn't apply to Emacs at all, and you would know it's all false if you knew anything about Emacs. On Wednesday, April 1, 2015 at 4:55:08 PM UTC-7, Fluid Dynamics wrote: On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote: The benefit is that Emacs is that its not constantly changing, and it gives you some stability over the years. I like latex, for instance, for the same reason. I can still access a 10 year old document and use it. First of all, there are other posts in this thread complaining about constantly changing stuff breaking things! One such post is by Colin Yates. Second, to the extent that it isn't changing, it is legacy. Which helps to explain the Wordperfect for DOS style of UI, which is dependent on vast numbers of complex key-combinations being memorized by the user, instead of a just-sit-down-and-start-using-it UI like everything originating after, say, 1995 or so has tended to have. Of course, the result is that Wordperfect (and emacs) seemed to require a great deal of specialized training just to accomplish even the most basic tasks, whereas with modern interfaces the way to do such basic tasks (save, open, copy and paste, move around, select, etc.) tends to be obvious and special training can focus exclusively on doing advanced things (scripting, complicated Photoshop filters and tricks, things like those). Legacy also, obviously, tends to present problems in other areas besides UI-boneheadedness: * I18n and l10n * Compatibility, with modern hardware and with modern operating systems, though that can be alleviated by people porting the code * Boneheaded internal limits, along the same general lines as 640K ought to be enough for anybody. It may be unable to use more than a small fraction of what modern hardware can offer it in the way of memory, storage, cores, ... * Accessibility. Interposing a terminal emulator between the app and screen reading software might cause problems, though on the other hand a text mode app may ultimately have advantages in that area too. On the other hand, it may not play well with accessibility tools that rely on standard UI conventions. Anything that responds to some voice command by generating control-V keystrokes to paste, or that relies on the presence of normal menus and/or mouse support is going to blow up spectacularly when used with 1980s-vintage Unix (or MS-DOS) software,
