RE: [ANN] Clojure 1.9.0-RC1

We have three processes running RC1 in production as of today. Looks good so far. We’ve had everything else up and running on Beta 4 in production since Monday, also looking good. Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoyi

Re: [core.spec] Stricter map validations?

I just stumbled upon another potential mistake here. When you have specs split across namespaces. Its possible for a map spec in one namespace to have one of its key's use a spec from another namespace. If you forget to require that other namespace though, you won't know, and your map will alwa

Re: hashmap keys

Most Clojure collections cache their hashcode, so that improves things quite bit. Also, very large collections are rarely used as *keys* in other maps. Most of the time key collections are one or two values. This means that what we're really talking about is combining the hash values of a few value

hashmap keys

i would love to know in a bit more detail how Clojure manages to allow arbitrary data structures as keys for its immutable hashmaps hashing an atomic value as a string or number is fast and i see how that would work when atomic values are used as keys but how about using a big nested vector as a

Re: difference between first & peek; rest & pop

Also, pop throws an exception on the empty list whereas rest returns (). On Thursday, May 30, 2013 at 12:43:14 AM UTC-4, Seven Hong wrote: > > Hi all, > > Could some one explain what's the difference between first and peek, rest > and pop? For me it looks like they behave exactly same on sequence

Re: Doc strings for complex cases?

You can also put a docstring in a ns form to give context. I don't think you need anything done to Clojure itself. Or more specifically, you need not be limited by whatever Clojure has done with docstrings. Nor will you need to modify defn. You can attach any metadata you like, to the vars i

Re: Doc strings for complex cases?

I think I have about two cases where multiple arity doc-strings would useful and for that I could just go without, but defmethods are more of a problem for me. I find defmethods can have greater contextual differences to the point I have been placing comments inline (;commented out lines) which

Re: [ANN] Clojure 1.9.0-RC1

Thanks, that’s good to hear. -- 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 th

Re: [ANN] Clojure 1.9.0-RC1

One more data point. I haven't uncovered any regressions yet on beta4 & have upgraded a few libraries and apps; though none are in production yet I've been working with it more or less daily since the beta4 release. R. On 7 November 2017 at 14:58, Alex Miller wrote: > Clojure 1.9.0-RC1 is now

Re: Doc strings for complex cases?

What's the point of doc strings per arity? Wouldn't (doc fn) just concatenate them all back into one anyways? Or would you extend it to take an arity argument? I think it seems to make sense to add them like that, but usability wise, when would you be looking at the doc of a single arity by its

Re: Doc strings for complex cases?

Way back when - when Rich was fielding suggestions for how to do doc strings - I made the offhand comment that every arity could have it's own doc string. He didn't like the idea back then. Doubtful he will now. I'm glad he went the route he did. I believe the discussion took place on this mail l

Re: Doc strings for complex cases?

Hello. > Should any breaking changes occur in Clojure core, Why should they? Regards, Mikhail. -- 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 modera

Re: Doc strings for complex cases?

Thanks for the suggestion(s), but I don't like the idea of writing custom code to implement better doc strings. Should any breaking changes occur in Clojure core, then I too could be forced to make changes and deal with broken code everywhere. If there was more community interest and the Clojure

Re: clojure.data.xml with newline / return in attribute values

> > It's 'attribute value normalisation' - see > https://www.w3.org/TR/REC-xml/#AVNormalize > Thanks for the link, this indeed looks official :-). Ciao …

Re: clojure.data.xml with newline / return in attribute values

Hi Peter… Anyway, if you use entities instead of \n literals, does that do the > round trip properly? that is actually my second example block above, here the ampersand is faithfully escaped, rendering the encoded value unusable. ;; => "" My hacky remedy in the third example was to replac

Re: clojure.data.xml with newline / return in attribute values

On Thursday, 9 November 2017 11:21:36 UTC, Jochen wrote: > > hmmm, that is unfortunately not the reality. In fact any newlines/returns > in attributes are collapsed to a single space (saw mentioned somewhere that > this is officially so). > It's 'attribute value normalisation' - see https://www

Re: clojure.data.xml with newline / return in attribute values

Hi Joost… hmmm, that is unfortunately not the reality. In fact any newlines/returns in attributes are collapsed to a single space (saw mentioned somewhere that this is officially so). This is also what happens here with clojure.data.xml: (prn (-> (xml/emit-str (xml/element :foo {:bar "Baz\r\nqu

clojure.data.xml with newline / return in attribute values

Hi… an unexpected problem that I currently face is about newline and return characters in xml attribute values. I first found it in good old clojure.xml and thought to fix it with Clojure.data.xml (0.0.8 and 0.2.0-alpha3 tried), but it did not help. When I read in some external xml with esca