Re: Parinfer on iOS
On the topic of Parinfer, what's the best Parinfer mode for Emacs right now? On Monday, August 22, 2016 at 3:52:33 PM UTC-7, Wes Morgan wrote: > > If anyone else would like to edit Clojure on iOS with parinfer (or is just > interested in expanding the number of places where Clojure can comfortably > occur), please vote for my feature request on Textastic (an otherwise very > nice iOS text editor with Clojure syntax highlighting): > http://feedback.textasticapp.com/topics/2008-parinfer-support-for-lisps/ > > The author is waiting to see how many votes it gets to decide if it's > worth implementing or not. -- 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: Generate a million file from a template
Thanks Guys! Hitesh you were right about rand-nth. I switched to rand-int, which is much faster. I found a way. It may not be the most optimal way but I can get about 5 files in 2-3 secs. I am using cheshire to parse json and pjson to write it back. (ns jsonworker.core (:require [cheshire.core :refer [parse-stream] ] [pjson.core :refer [read-str write-str get-charset]])) (defn parse-json [file-loc] (parse-stream (clojure.java.io/reader file-loc))) (def json-template (parse-json "resources/test_1918203.json")) (def fol-location "/Users/json/json_output") (defn update-ref [json-string id] (assoc-in json-string ["basicInformation" "myId"] id)) (defn gen-files [folder-loc text id] (spit (str folder-loc "/test_" id ".json") (write-str text))) (defn run-me [x] (dotimes [_ x] (let [iid (rand-int 1e9)] (gen-files fol-location (update-ref json-template iid) iid (defn run-in-parallel "run-in-parallel runs 500 different threads. you can give each thread number of files you want to generate Eg: run-in-parallel 100 will generate 500*100 = 5 files" [y] (dotimes [_ 500] (future (.start (Thread. (run-me y)) On Monday, August 22, 2016 at 3:10:05 PM UTC-4, hitesh wrote: > > This looks like it's doing too much work to simply generate a random > integer. Are you sure you want to build a lazy list of 999,000 integers > and randomly select into it for every invocation? The garbage collector > will be working overtime. > > (defn update-individual [json-string] > (assoc-in json-string ["someInfo" "moreInfo"] > (rand-nth (range 1000 100 > > This should get you a random number in the range without as much effort. > > (+ 1000 (rand-int 999000)) > > > > On Saturday, August 20, 2016 at 1:51:11 PM UTC-4, Abhinav Gogna wrote: >> >> Hello, >> >> I am trying to generate lot of files using futures but it hasn't sped up >> the process that hoped for. Here is the code I am using. Can someone point >> what I am doing wrong? >> >> (ns jsonworker.core >> (:require [cheshire.core :refer :all ])) >> >> >> (defn parse-json >> [file-loc] >> (parse-stream (clojure.java.io/reader file-loc))) >> >> (def json-template (atom (parse-json "resources/individual_1918203.json" >> ))) >> >> (def fol-location "/Users/json/json_output") >> >> (defn update-individual [json-string] >> (assoc-in json-string ["someInfo" "moreInfo"] >> (rand-nth (range 1000 100 >> >> >> (defn gen-files [folder-loc text] >> (spit (str folder-loc "/newfile_" (rand-int 1e7)) text)) >> >> >> (defn run-me [x] >> (future >> (dotimes [_ x] >> (swap! json-template update-individual) >> (gen-files fol-location @json-template >> >> >> Thanks! >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
Sorry, I missed this one in the thread somehow. This happens to be a case
where you have *both* defn and destructuring specs in play, so it has even
greater potential for confusion in generic errors.
On Monday, August 22, 2016 at 11:23:33 AM UTC-5, Leon Grapenthin wrote:
>
> I welcome the strict checking over backwards compatibility for broken
> syntax. E. g. allowing things like symbols in the ns decl would require
> supporting that as a feature in future updates, analyzer code, other hosts
> etc. The Clojure devs should not have to worry things with so little use.
>
> Still the error messages are simply far from good enough and that is what
> appears to me as the main problem OP has. If the compiler had pointed him
> to two fixes he could have done in a minute then he had not complained and
> instead felt more happy with his new compiler.
>
> Here is my story when I loaded a large codebase today with 1.9-alpha11:
>
I'm going to reformat this a little (and formatting is certainly a thing
that could change - since there are user values in here it's easy for the
spacing to not be the best)...
Call to clojure.core/defn did not conform to spec:
You mentioned you knew exactly the location and the above gives you the
form that is failing to match, so you've narrowed it down to a particular
form in a particular file.
In: [1 0]
val: ({:keys [money/major money/minor money/currency], :or #:money{major 0,
minor 0, currency :EUR}})
here's the actual value that is failing - so this does include the part
that's wrong (:or map with non-symbol keys)
fails spec: :clojure.core.specs/arg-list
here we name another spec - you can use this to (doc
:clojure.core.specs/arg-list) to get more info (and so on). There will be
probably be some kind of a way to do this in a "deep" way at some point.
at: [:args :bs :arity-1 :args]
the path through the specs - can be combined with the spec name above and
the spec for defn to give you a lot more info - this is the kind of thing
that a sideband tool in an IDE could do amazing things with.
predicate: (cat :args (* :clojure.core.specs/binding-form) :varargs (? (cat
:amp #{(quote &)} :form :clojure.core.specs/binding-form))),
the predicate that is actually failing in the spec, probably not
particularly helpful given the complexity (and recursiveness) of the
destructuring specs
Extra input
this is the part of cat that I think could be made more explicit - could be
saying here that the value it had (above) was expected to match the next
part of the cat (binding-form). So that could say the equivalent of
"Expected binding-form but had non-matching value ..." and could even find
what parts of that value matched and maybe which didn't (the :or keys) such
that you'd have a more precise description. There is some more stuff Rich
and I have worked on around "hybrid maps" which is the case here with map
destructuring - it's particularly challenging to get a good error out of
that at the moment, but there's more that can be done.
In: [1 0]
val: {:keys [money/major money/minor money/currency], :or #:money{major 0,
minor 0, currency :EUR}}
fails spec: :clojure.core.specs/arg-list
at: [:args :bs :arity-n :bodies :args]
predicate: vector?
This whole block is another (non-applicable) alternative that spec tried
out (the multi-arity case). We know that's not what we were trying to do,
but it's reported anyways. This is where fan-out kicks in and you can get a
lot of noise that's not applicable. I think there's probably enough
information to either be better about saying which case we thought you were
matching or to hide some of them, etc.
:clojure.spec/args (format-money [{:keys
[money/major money/minor money/currency], :or #:money{major 0,
minor 0, currency :EUR}}] (str major "," (if (zero? minor) "-"
minor) " €"))
And this is just reporting the actual passed args to the macro - I think
this is confusing because it doesn't look like the call (because it's
missing the macro name). As I said prior, I think this particular part of
macro error reporting can do better as it knows more about what's going on
- this should really be tied back up to the macro name at the top.
>
> I know where the problem is immediately because I looked at above error
> and quickly jumped to the code that didn't work. Then I guessed it right
> because I know what has been changed from Alex Release notes and because I
> had recently inquired on this board about :or destructoring and probably
> because I am a long time Clojure user. The problem is that :or in map
> destructuring with namespaced keywords was not officially supported before
> 1.9 (but sadly worked exactly opposite to how it is supported now)
>
> Compare that the more common story of someone who has not followed every
> newspiece lately and just wants to upgrade from 1.8 to 1.9 - How could he
> tell whats wrong from above error message? Following above error message by
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
> > The big syntax macro cases like ns or let are way past the "average" spec. > ... I don't think it's fair to judge the general performance of spec's > errors on just those use cases. It might be true that these macros are larger than usual, but they're also the cases that everyone will encounter all the time, particularly new users trying to figure out the language syntax. On 23 August 2016 at 12:55, Alex Miller wrote: > > On Monday, August 22, 2016 at 7:43:53 PM UTC-5, Colin Fleming wrote: >> >> I agree that the ability to get a machine-readable parse failure is very >> important for tooling. However I feel very strongly that the error messages >> that are printed by default on macro validation failures should be easily >> understandable, and the current ones are not. If we completely punt to >> tooling for this, firstly users will receive different (and different >> quality) error messages depending on the tool they're using, and anyone >> using plain vanilla Clojure will not get good errors at all. >> > > I largely agree.. > > -- > 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] data.avl 0.0.14 – BUGFIX to splits, faster map/set reductions
Nice work! Esp on the reduce stuff - great to see that. Any reason you didn't go the IReduce path in Clojure too instead of CollReduce? Generally, I'd say that's preferred when you control the data structure. On Monday, August 22, 2016 at 7:43:51 PM UTC-5, Michał Marczyk wrote: > > Hi, > > I am pleased to announce the 0.0.14 release of data.avl, a Clojure > Contrib library providing highly performant drop-in replacements for > Clojure(Script)'s built-in sorted maps and sets that support O(log n) > nth, rank-of, first-class submaps/subsets (like subseq, but preserving > collection type; fully independent from the original for GC purposes) > and splits by key and index. > > [org.clojure/data.avl "0.0.14"] > > > org.clojure > data.avl > 0.0.14 > > > org.clojure:data.avl:0.0.14 > > Changes in this release: > > 1. http://dev.clojure.org/jira/browse/DAVL-8 > > Fixed a bug in split-key that caused incorrect rank and size > information to be stored in some collections resulting from splits > using a key absent from the input collection. See the ticket for a > more detailed post mortem and links to fixing commits. > > Many thanks to Darrick Wiebe for the report and test.check > properties that exposed broken split-key return values! > > 2. http://dev.clojure.org/jira/browse/DAVL-7 > > data.avl maps and sets now implement CollReduce (in Clojure) / > IReduce (in ClojureScript), leading to significantly improved > reduce performance on data.avl inputs. See end of this email for > some Criterium benchmarks. > > Many thanks to Francis Avila for providing the patch! > > 3. Seqs over data.avl collections can now be = to j.u.Lists. > > 4. data.avl collections now have their own print-dup implementations > that correctly round-trip in Clojure. > > 5. Public Vars in the clojure.data.avl namespace now carry :added > metadata. > > Cheers, > Michał > > > Reduce benchmarks: > == > > Before patch: > - > > user> (let [m1 (apply sorted-map (range 1)) > m2 (apply avl/sorted-map (range 1))] > (assert (= (reduce (fn [out kv] (+ out (key kv) (val kv))) > 0 > m1) >(reduce (fn [out kv] (+ out (key kv) (val kv))) > 0 > m2))) > (c/quick-bench > (reduce (fn [out kv] (+ out (key kv) (val kv))) > 0 > m1)) > (c/quick-bench > (reduce (fn [out kv] (+ out (key kv) (val kv))) > 0 > m2))) > Evaluation count : 120 in 6 samples of 20 calls. > Execution time mean : 663.862017 µs > Execution time std-deviation : 9.483652 µs >Execution time lower quantile : 654.277800 µs ( 2.5%) >Execution time upper quantile : 677.885431 µs (97.5%) >Overhead used : 21.423458 ns > Evaluation count : 468 in 6 samples of 78 calls. > Execution time mean : 1.295972 ms > Execution time std-deviation : 74.233890 µs >Execution time lower quantile : 1.255853 ms ( 2.5%) >Execution time upper quantile : 1.420871 ms (97.5%) >Overhead used : 21.423458 ns > > Found 1 outliers in 6 samples (16.6667 %) > low-severe 1 (16.6667 %) > Variance from outliers : 14.4619 % Variance is moderately inflated by > outliers > nil > > > After patch: > > > ;;; Clojure 1.9-alpha10 > > user> (let [m1 (apply sorted-map (range 1)) > m2 (apply avl/sorted-map (range 1))] > (assert (= (reduce (fn [out kv] (+ out (key kv) (val kv))) > 0 > m1) >(reduce (fn [out kv] (+ out (key kv) (val kv))) > 0 > m2))) > (c/quick-bench > (reduce (fn [out kv] (+ out (key kv) (val kv))) > 0 > m1)) > (c/quick-bench > (reduce (fn [out kv] (+ out (key kv) (val kv))) > 0 > m2))) > Evaluation count : 882 in 6 samples of 147 calls. > Execution time mean : 687.923681 µs > Execution time std-deviation : 17.527428 µs >Execution time lower quantile : 669.270395 µs ( 2.5%) >Execution time upper quantile : 710.828484 µs (97.5%) >Overhead used : 2.633678 ns > Evaluation count : 2940 in 6 samples of 490 calls. > Execution time mean : 207.386184 µs > Execution time std-deviation : 7.420049 µs >Execution time lower quantile : 202.829682 µs ( 2.5%) >Execution time upper quantile : 219.880774 µs (97.5%) >Overhead used : 2.633678 ns > > Found 1 outliers in 6 samples (16.6667 %) > low-severe 1 (16.6667 %) > Variance from outliers : 13.8889 % Variance is moderately inflated by > outliers > nil > > ;;; Clojure 1.5.1 > > user> (let [m1 (apply sorted-map (range 1)) > m2 (apply avl/sorted-map (range 1))] >
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
On Monday, August 22, 2016 at 7:43:53 PM UTC-5, Colin Fleming wrote: > > I agree that the ability to get a machine-readable parse failure is very > important for tooling. However I feel very strongly that the error messages > that are printed by default on macro validation failures should be easily > understandable, and the current ones are not. If we completely punt to > tooling for this, firstly users will receive different (and different > quality) error messages depending on the tool they're using, and anyone > using plain vanilla Clojure will not get good errors at all. > I largely agree.. -- 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: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
On Monday, August 22, 2016 at 6:45:16 PM UTC-5, Oliver George wrote: > > > I'm interested to see any discussion regarding this point. No doubt > translating spec data into more friendly formats has been discussed. > > Getting the data right is clojure's problem. That's the concrete > foundation and building blocks required for tooling. Seems like Rich has > done spectacularly there. > > Potentially it's up to tooling to do more with that data. I'd love to > hear Bruce (figwheel), Collin's (cursive) and Bozhidar (cider) opinions > about that. > Bruce has done some stuff with custom explain error reporting around cljs config (I think?) that was interesting. And I know of others that have built things too. I think those are cool and there are likely to be good places where they're useful, particularly in graphical editor environments where there are opportunities to do special stuff. But the intention is that the default messages should be useful without plugging something else in. -- 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: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
I've already mentioned most of this above, but I'll try again. In short, I'd say yes (that's why we are still in alphas), but in adherence with the general goals we have of capturing and returning comprehensive data about the error and building those error messages generically. - Getting the error data (specifically the explain-data output) to be both sufficient and generically useful is the first priority. I think at this point that's pretty close and unlikely to change significantly. This is the key data that can be used to drive everything else. form/describe are also tools leveraged by explain-data and there are a bunch of (known) problems still in those areas that will be cleaned up. - The explain error message strings are currently pretty good on simpler specs. The big syntax macro cases like ns or let are way past the "average" spec. They are difficult in several dimensions - fan-out, recursion, large input forms, etc. All of those make creating generic error messages a lot harder so I don't think it's fair to judge the general performance of spec's errors on just those use cases. There are some general known problem areas where there are things that can be done. I talked about some of those in relation to s/cat in prior post, but there are others as well. - It's unlikely that we will add any kind of "custom error strings" - the focus will be on automatic message generation. - There are issues orthogonal to spec around compiler error reporting and stack trace display that can and should be improved. - You've complained in other channels about the "learning to read" error messages part and I think you've taken it entirely the wrong way or maybe I just disagree. There are benefits from reporting errors in a generic, consistent way. That way may mean acquiring familiarity with something new, just like learning any programming language. I'm not disagreeing that the messages we're looking at are harder to understand than a hand-written custom error message for a particular specific situation, but we have bigger goals of automatically producing good errors for a large class of specs. Keep in mind that while we're focusing here on one or two specific problems, these specs also are detecting a large number of other errors and generically producing error messages for all of them, while simultaneously being available to conform/destructure the input in ways that can potentially improve the implementations too. All of this post is of course just my thoughts from someone in the room but not making the final decisions, so everything here is subject to being over-ruled tomorrow. :) On Monday, August 22, 2016 at 5:11:27 PM UTC-5, Brian Marick wrote: > > > On Aug 22, 2016, at 11:23 AM, Leon Grapenthin > wrote: > > Still the error messages are simply far from good enough and that is what > appears to me as the main problem OP has. > > > This is important. Will the new, stricter error messages be improved > before 1.9 is finalized? > > > -- 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] data.avl 0.0.14 – BUGFIX to splits, faster map/set reductions
Hi, I am pleased to announce the 0.0.14 release of data.avl, a Clojure Contrib library providing highly performant drop-in replacements for Clojure(Script)'s built-in sorted maps and sets that support O(log n) nth, rank-of, first-class submaps/subsets (like subseq, but preserving collection type; fully independent from the original for GC purposes) and splits by key and index. [org.clojure/data.avl "0.0.14"] org.clojure data.avl 0.0.14 org.clojure:data.avl:0.0.14 Changes in this release: 1. http://dev.clojure.org/jira/browse/DAVL-8 Fixed a bug in split-key that caused incorrect rank and size information to be stored in some collections resulting from splits using a key absent from the input collection. See the ticket for a more detailed post mortem and links to fixing commits. Many thanks to Darrick Wiebe for the report and test.check properties that exposed broken split-key return values! 2. http://dev.clojure.org/jira/browse/DAVL-7 data.avl maps and sets now implement CollReduce (in Clojure) / IReduce (in ClojureScript), leading to significantly improved reduce performance on data.avl inputs. See end of this email for some Criterium benchmarks. Many thanks to Francis Avila for providing the patch! 3. Seqs over data.avl collections can now be = to j.u.Lists. 4. data.avl collections now have their own print-dup implementations that correctly round-trip in Clojure. 5. Public Vars in the clojure.data.avl namespace now carry :added metadata. Cheers, Michał Reduce benchmarks: == Before patch: - user> (let [m1 (apply sorted-map (range 1)) m2 (apply avl/sorted-map (range 1))] (assert (= (reduce (fn [out kv] (+ out (key kv) (val kv))) 0 m1) (reduce (fn [out kv] (+ out (key kv) (val kv))) 0 m2))) (c/quick-bench (reduce (fn [out kv] (+ out (key kv) (val kv))) 0 m1)) (c/quick-bench (reduce (fn [out kv] (+ out (key kv) (val kv))) 0 m2))) Evaluation count : 120 in 6 samples of 20 calls. Execution time mean : 663.862017 µs Execution time std-deviation : 9.483652 µs Execution time lower quantile : 654.277800 µs ( 2.5%) Execution time upper quantile : 677.885431 µs (97.5%) Overhead used : 21.423458 ns Evaluation count : 468 in 6 samples of 78 calls. Execution time mean : 1.295972 ms Execution time std-deviation : 74.233890 µs Execution time lower quantile : 1.255853 ms ( 2.5%) Execution time upper quantile : 1.420871 ms (97.5%) Overhead used : 21.423458 ns Found 1 outliers in 6 samples (16.6667 %) low-severe 1 (16.6667 %) Variance from outliers : 14.4619 % Variance is moderately inflated by outliers nil After patch: ;;; Clojure 1.9-alpha10 user> (let [m1 (apply sorted-map (range 1)) m2 (apply avl/sorted-map (range 1))] (assert (= (reduce (fn [out kv] (+ out (key kv) (val kv))) 0 m1) (reduce (fn [out kv] (+ out (key kv) (val kv))) 0 m2))) (c/quick-bench (reduce (fn [out kv] (+ out (key kv) (val kv))) 0 m1)) (c/quick-bench (reduce (fn [out kv] (+ out (key kv) (val kv))) 0 m2))) Evaluation count : 882 in 6 samples of 147 calls. Execution time mean : 687.923681 µs Execution time std-deviation : 17.527428 µs Execution time lower quantile : 669.270395 µs ( 2.5%) Execution time upper quantile : 710.828484 µs (97.5%) Overhead used : 2.633678 ns Evaluation count : 2940 in 6 samples of 490 calls. Execution time mean : 207.386184 µs Execution time std-deviation : 7.420049 µs Execution time lower quantile : 202.829682 µs ( 2.5%) Execution time upper quantile : 219.880774 µs (97.5%) Overhead used : 2.633678 ns Found 1 outliers in 6 samples (16.6667 %) low-severe 1 (16.6667 %) Variance from outliers : 13.8889 % Variance is moderately inflated by outliers nil ;;; Clojure 1.5.1 user> (let [m1 (apply sorted-map (range 1)) m2 (apply avl/sorted-map (range 1))] (assert (= (reduce (fn [out kv] (+ out (key kv) (val kv))) 0 m1) (reduce (fn [out kv] (+ out (key kv) (val kv))) 0 m2))) (c/quick-bench (reduce (fn [out kv] (+ out (key kv) (val kv))) 0 m1)) (c/quick-bench (reduce (fn [out kv] (+ out (key kv) (val kv))) 0 m2))) Evaluation count : 990 in 6 samples of 165 calls. Execution time me
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
I agree that the ability to get a machine-readable parse failure is very important for tooling. However I feel very strongly that the error messages that are printed by default on macro validation failures should be easily understandable, and the current ones are not. If we completely punt to tooling for this, firstly users will receive different (and different quality) error messages depending on the tool they're using, and anyone using plain vanilla Clojure will not get good errors at all. On 23 August 2016 at 11:45, Oliver George wrote: > > I'm interested to see any discussion regarding this point. No doubt > translating spec data into more friendly formats has been discussed. > > Getting the data right is clojure's problem. That's the concrete > foundation and building blocks required for tooling. Seems like Rich has > done spectacularly there. > > Potentially it's up to tooling to do more with that data. I'd love to > hear Bruce (figwheel), Collin's (cursive) and Bozhidar (cider) opinions > about that. > > > On Tuesday, 23 August 2016 08:11:27 UTC+10, Brian Marick wrote: >> >> >> On Aug 22, 2016, at 11:23 AM, Leon Grapenthin >> wrote: >> >> Still the error messages are simply far from good enough and that is what >> appears to me as the main problem OP has. >> >> >> This is important. Will the new, stricter error messages be improved >> before 1.9 is finalized? >> >> >> -- > 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: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
I'm interested to see any discussion regarding this point. No doubt translating spec data into more friendly formats has been discussed. Getting the data right is clojure's problem. That's the concrete foundation and building blocks required for tooling. Seems like Rich has done spectacularly there. Potentially it's up to tooling to do more with that data. I'd love to hear Bruce (figwheel), Collin's (cursive) and Bozhidar (cider) opinions about that. On Tuesday, 23 August 2016 08:11:27 UTC+10, Brian Marick wrote: > > > On Aug 22, 2016, at 11:23 AM, Leon Grapenthin > wrote: > > Still the error messages are simply far from good enough and that is what > appears to me as the main problem OP has. > > > This is important. Will the new, stricter error messages be improved > before 1.9 is finalized? > > > -- 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.
Parinfer on iOS
If anyone else would like to edit Clojure on iOS with parinfer (or is just interested in expanding the number of places where Clojure can comfortably occur), please vote for my feature request on Textastic (an otherwise very nice iOS text editor with Clojure syntax highlighting): http://feedback.textasticapp.com/topics/2008-parinfer-support-for-lisps/ The author is waiting to see how many votes it gets to decide if it's worth implementing or not. -- 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: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
> On Aug 22, 2016, at 11:23 AM, Leon Grapenthin > wrote: > > Still the error messages are simply far from good enough and that is what > appears to me as the main problem OP has. This is important. Will the new, stricter error messages be improved before 1.9 is finalized? -- 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: Parsing namespaced XML with clojure.data.xml
I've been thinking this over. I'm starting feel that you are right in that the arbitrary, global mapping could cause more problems, than it would solve. Even if we could get by with a maintained registry, it would still be a burden to maintain and to use. Also, there is the open question of code expecting qnames, when suddenly, somebody declares a new xmlns mapping. There is the possibility to canonicalize by cramming the xmlns uri into a readable kw-ns and that would still neatly reuse clojure's ns-alias facility. What I don't like about the approach is, that it would make even pretty-printed xml parse-trees quite unreadable. While :xmlns.dav/multistatus vs :xmlns.REFWOgo=/multistatus might not look as horrifying, consider :xmlns.aHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbAo=/p for an xhtml paragraph. Maybe it's time to give up on universal value equality of parsed xml and instead make the keyword - mapping a la carte, with a parser / emitter flag. Technically, universal value equality is already challenged by the qname / keyword dichotomy and given that we want to retain using ::alias/keywords there is a decision to be made on whether to make qname the canonical representation and embrace the multitude of keyword mappings or whether to eliminate qnames and take the readability hit for canonicalizing the keyword representation. Do you see any alternative? -- 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: Generate a million file from a template
This looks like it's doing too much work to simply generate a random integer. Are you sure you want to build a lazy list of 999,000 integers and randomly select into it for every invocation? The garbage collector will be working overtime. (defn update-individual [json-string] (assoc-in json-string ["someInfo" "moreInfo"] (rand-nth (range 1000 100 This should get you a random number in the range without as much effort. (+ 1000 (rand-int 999000)) On Saturday, August 20, 2016 at 1:51:11 PM UTC-4, Abhinav Gogna wrote: > > Hello, > > I am trying to generate lot of files using futures but it hasn't sped up > the process that hoped for. Here is the code I am using. Can someone point > what I am doing wrong? > > (ns jsonworker.core > (:require [cheshire.core :refer :all ])) > > > (defn parse-json > [file-loc] > (parse-stream (clojure.java.io/reader file-loc))) > > (def json-template (atom (parse-json "resources/individual_1918203.json" > ))) > > (def fol-location "/Users/json/json_output") > > (defn update-individual [json-string] > (assoc-in json-string ["someInfo" "moreInfo"] > (rand-nth (range 1000 100 > > > (defn gen-files [folder-loc text] > (spit (str folder-loc "/newfile_" (rand-int 1e7)) text)) > > > (defn run-me [x] > (future > (dotimes [_ x] > (swap! json-template update-individual) > (gen-files fol-location @json-template > > > Thanks! > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
I welcome the strict checking over backwards compatibility for broken
syntax. E. g. allowing things like symbols in the ns decl would require
supporting that as a feature in future updates, analyzer code, other hosts
etc. The Clojure devs should not have to worry things with so little use.
Still the error messages are simply far from good enough and that is what
appears to me as the main problem OP has. If the compiler had pointed him
to two fixes he could have done in a minute then he had not complained and
instead felt more happy with his new compiler.
Here is my story when I loaded a large codebase today with 1.9-alpha11:
Call to clojure.core/defn did not conform to spec: In: [1 0] val:
({:keys [money/major money/minor money/currency], :or #:money{major
0, minor 0, currency :EUR}}) fails spec:
:clojure.core.specs/arg-list at: [:args :bs :arity-1 :args]
predicate: (cat :args (* :clojure.core.specs/binding-form) :varargs
(? (cat :amp #{(quote &)} :form
:clojure.core.specs/binding-form))), Extra input In: [1 0] val:
{:keys [money/major money/minor money/currency], :or #:money{major
0, minor 0, currency :EUR}} fails spec:
:clojure.core.specs/arg-list at: [:args :bs :arity-n :bodies :args]
predicate: vector? :clojure.spec/args (format-money [{:keys
[money/major money/minor money/currency], :or #:money{major 0,
minor 0, currency :EUR}}] (str major "," (if (zero? minor) "-"
minor) " €"))
I know where the problem is immediately because I looked at above error
and quickly jumped to the code that didn't work. Then I guessed it right
because I know what has been changed from Alex Release notes and because I
had recently inquired on this board about :or destructoring and probably
because I am a long time Clojure user. The problem is that :or in map
destructuring with namespaced keywords was not officially supported before
1.9 (but sadly worked exactly opposite to how it is supported now)
Compare that the more common story of someone who has not followed every
newspiece lately and just wants to upgrade from 1.8 to 1.9 - How could he
tell whats wrong from above error message? Following above error message by
looking up specs and following index paths like [1 0] is a manual process
that costs and feels like debugging a difficultly hidden bug. The
time/utility distance to a hand written macro assert like "Keys in :or
destructoring must be unqualified symbols" currently does not justify the
use of specs for such things. It's by far worse than the NPE Stacktraces
popping up from nowhere that one learns to value and utilize after a month
or so in Clojure.
It seems that improving the error messages we can calculate from specs data
is something that more people should think about and improve for 1.9. I'd
be willing to invest time if needed / input is welcome. Alternatively a way
to integrate custom error messages into specs directly could also be
helpful.
(But I still don't really see how above spec tells me that I shouldn't use
qualified symbols in :or destructoring - do you?)
On Monday, August 22, 2016 at 5:08:57 PM UTC+2, Alex Miller wrote:
>
> I've added library related fixes related to core specs to an info page at:
>
> http://dev.clojure.org/display/design/Errors+found+with+core+specs
>
>
> On Sunday, August 21, 2016 at 8:24:20 PM UTC-5, Alex Miller wrote:
>>
>> On Sunday, August 21, 2016 at 5:28:57 PM UTC-5, lvh wrote:
>>>
>>> FYI, while I disagree with your conclusion (I think we should go fix
>>> libraries instead), I ran into the same issue just now for roughly the same
>>> reason, except the thing that pulled in an old version of core.unify was
>>> core.typed, which pulls in 0.5.3 through core.contracts.
>>>
>>
>> BTW, core.contracts was also updated to 0.0.6 last week to use the latest
>> core.unify.
>>
>>
--
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: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
I've added library related fixes related to core specs to an info page at: http://dev.clojure.org/display/design/Errors+found+with+core+specs On Sunday, August 21, 2016 at 8:24:20 PM UTC-5, Alex Miller wrote: > > On Sunday, August 21, 2016 at 5:28:57 PM UTC-5, lvh wrote: >> >> FYI, while I disagree with your conclusion (I think we should go fix >> libraries instead), I ran into the same issue just now for roughly the same >> reason, except the thing that pulled in an old version of core.unify was >> core.typed, which pulls in 0.5.3 through core.contracts. >> > > BTW, core.contracts was also updated to 0.0.6 last week to use the latest > core.unify. > > -- 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] Shrubbery 0.4.0, a stubbing, spying, and mocking library for Clojure protocols
Clojure protocols are a great way to encapsulate operations with side
effects, but suffer from a lack of general test tooling. Shrubbery provides
a small set of basic building blocks for working with them.
New in this release:
– A throws function, which returns an object suitable for use with the
stub function
that throws the named exception when invoked, as so:
(defprotocol SomeProtocol
(explode [t]))
(let [astub (shrubbery/stub SomeProtocol
{:explode (shrubbery/throws RuntimeException "bang")})]
(explode astub)) ;; throws RuntimeException "bang"
What Shrubbery provides:
* stub, which accepts a variable list of protocols and a optional hashmap
of simple value implementations and returns an object that reifies all
given protocols;
* spy, which accepts an object with at least one protocol implementation
and returns a new implementation that tracks the number of times each of
its members were called;
* mock, which wraps a stub in a spy, allowing callers to supply basic
function implementations and assert against those calls; and
* calls/received?, which in conjunction with the Matcher protocol provide
a way to query spies and assert against their state.
Shrubbery is test-framework-agnostic, avoids altering runtime state to the
degree possible, and uses no macros. It supports Clojure versions 1.5-1.8;
I haven't yet tested with 1.9. It should work nicely with automated
refactoring operations like rename-function.
https://github.com/bguthrie/shrubbery
[com.gearswithingears/shrubbery "0.4.0"]
Cheers,
Brian
--
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: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
That emacs joke gets my week started with some abdominal pain 😂😂 I support strictness 😬 Luc P. -- 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.
