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 comfortabl
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 [chesh
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 st
>
> 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 encount
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
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 eas
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
> foundati
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 er
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;
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
tooli
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 spectacular
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://feedbac
> 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 receive
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 ex
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
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.
Stil
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 dis
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
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
19 matches
Mail list logo
