Hi Brian,
Not crazy at all! Spec errors are maps at the bottom, and IMO these maps
should flow anywhere we are making exceptions. This is already true for
the exceptions coming from spec.test, and we should make it true for the
macroexpand exceptions as well. (I actually prefer reading the map f
Brian,
The tone of your previous post is not constructive. Let's keep the
discussion about ideas, not people.
Thanks,
Stu
On Wed, Aug 24, 2016 at 8:46 PM, Brian Marick
wrote:
>
> On Aug 24, 2016, at 8:39 AM, Stuart Halloway
> wrote:
>
> 3. "Follow the inverted pyramid so people see what is m
I do not think your tone and lack of constructive feedback to Alex's (and
others) thoughtful responses is helping your case.
On Wednesday, August 24, 2016 at 8:46:47 PM UTC-4, Brian Marick wrote:
>
>
> On Aug 24, 2016, at 8:39 AM, Stuart Halloway > wrote:
>
> 3. "Follow the inverted pyramid so
> On Aug 24, 2016, at 7:46 PM, Brian Marick wrote:
> So why not do it in the bottom layer? Is there some deep reason why only an
> unserious programmer would want information in anything other than the
> current clojure.spec order? (We’re talking here about reordering a list.)
An even crazier
> On Aug 24, 2016, at 8:39 AM, Stuart Halloway
> wrote:
>
> 3. "Follow the inverted pyramid so people see what is most important." This
> kind of thing is easily done in a layer above spec, e.g. a custom REPL
> printer for spec macro errors. Worth working on but not critical to getting
> sp
This is almost exactly the intuition behind the standard error reporting
heuristic for grammars involving alternations. It is a heuristic, but it
has to be since on a failure it's impossible to entirely accurately
determine the user's intention. But intuitively, generally the rule that
has managed
Greetings, fellow Clojurians!
I am happy to announce Leiningen 2.7.0! This release contains mostly
bugfixes, but two major new improvements were added. There is now a
PowerShell version of `lein.bat`, and `:managed-dependencies` has been
added to Leiningen.
Both improvements should be considered
Namespaced XML is inherently value-comparable and unambiguous. It would be
shame to give up on that, and disperse the burden throughout every layer of
library and consumer.
Pretty-printing need not be a concern of the XML parsing library. Everyone
seems to be interested nowadays in easing the
Hi Alex, I could track down why explain stops
early. http://dev.clojure.org/jira/browse/CLJ-2013
On Wednesday, August 24, 2016 at 11:33:43 PM UTC+2, Leon Grapenthin wrote:
>
>
> On Tuesday, August 23, 2016 at 3:27:28 AM UTC+2, Alex Miller wrote:
>>
>> predicate: (cat :args (* :clojure.core.specs
On Tuesday, August 23, 2016 at 3:27:28 AM UTC+2, Alex Miller wrote:
>
> 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
Hi Beau,
Yes. Nevermind and everyone should learn to read spec. :-)
That said, such customizations allow people to experiment and flesh out a
bunch different ideas in parallel.
Best,
Stu
On Wed, Aug 24, 2016 at 1:17 PM, Beau Fabry wrote:
> Just specifically on a custom REPL printer, wouldn't
Just specifically on a custom REPL printer, wouldn't that negate the
benefits Alex sees in people becoming accustomed to reading spec error
messages? If every error report from each different environment potentially
looks different? Also, from the position of a community maintainer Brian is
mos
A suggestion for making all errors better would be to give not only the
precise file and line _of the beginning of the top level form containing
the problem_, but a more precise line and column of _the part of the form
that spec is complaining about_. Multi-line forms are the biggest and
hardest t
Brian originally raised 5 points that were concrete & specific, and
therefore potentially actionable. That is usefully-shaped feedback, thanks
Brian! My take on those points, which I will recast in my own words:
1. "Loosen rules about ns form to match what people have actually done."
This is pre
Hi Revanth,
You might want to join and post on the St. Louis Clojure meetup discussion
group too to reach a more targeted audience.
http://www.meetup.com/stl-clojure/
Alex
On Wednesday, August 24, 2016 at 8:21:00 AM UTC-5, Revanth Kumar wrote:
>
> *Application Developer*
>
>
>
> Location: St
*Application Developer*
Location: St Louis, MO
Duration: 6 months
*Description:*
Provides application software development services or technical support
typically in a defined project. Develops program logic for new applications
or analyzes and modifies logic in existing applications.
Hi,
I am pleased to announce the 0.4.0 release of konserve. The major change
is key iteration for the file-store and a fast append-log + reducing
function for all stores.
>From the README:
A simple document store protocol defined with core.async semantics to
allow Clojuresque collection operatio
Sure, at the end of the day I don't really care about thre require/:require
issue, it just seems a little incongruent with previous decisions which
have promoted backwards compatibility. I generally prefer increased
strictness, so I'm fine with the change. I do care about the error
messages, though
I agree Colin, this feels more like the beatings shall continue until
morale improves ;-)
More seriously, I understand the point of the musical instruments analogy
to be a reminder to programmers that learning a language and understanding
it in depth will increase your power and expressivity wi
Hi,
I'm trying to use the transducer framework for some sequence processing
where I have a core reduction function, but depending on options, extra
functionality can be added to the reduction function. I thought that's a
good fit for hand-written transducers.
However, I'm running into a proble
20 matches
Mail list logo
