RE: [ANN] Clojure 1.9.0-RC1

[Sean Corfield]

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 annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Alex 
Miller 
Sent: Tuesday, November 7, 2017 6:58:24 AM
To: Clojure
Subject: [ANN] Clojure 1.9.0-RC1

Clojure 1.9.0-RC1 is now available.

Try it via

- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-RC1
- Leiningen: [org.clojure/clojure "1.9.0-RC1"]

1.9.0-RC1 is the same as 1.9.0-beta4.

We would appreciate anything you can do to try out this release. We do not plan 
to make any further changes prior to 1.9.0 release unless regressions are found.

--
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: [core.spec] Stricter map validations?

[Didier]

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 
always validate.

(s/def ::spec (s/keys :req [:other/spec]))

If :other/spec is not registered, ::spec still will succeed at being 
registered. And then, assuming :other/spec is defined as:

(s/def :other/spec int?)

I wouldn't matter, since:

(s/valid? ::spec {:other/spec "123"})

Will return true.

But if you register :other/spec, it would return false.

Normally, this has not been an issue for me, but now that I share my specs 
more, I've got specs in different namespace using one another, and I've 
already made this mistakes a few time, causing validation I thought was 
there to protect me, to actually be missing.

So I made my own keys macro:

(defmacro known-keys
  [& {:keys [req req-un opt opt-un gen] :as args}]
  (letfn [(known-spec? [k] (boolean (s/get-spec k)))]
(doseq [e (concat req req-un opt opt-un)]
  (when (not (known-spec? e))
(throw (ex-info (str e " is not a currently registered spec.") 
args)
  `(s/keys ~@(interleave (keys args) (vals args

Which first checks that all keys are currently registered, and if so, it 
delegates back to s/keys. Otherwise it throws an exception at macro 
expansion time.

I think this would also solve OPs problem, since it would throw if typos 
are made also.

On Saturday, 14 October 2017 04:45:47 UTC-7, stuart@gmail.com wrote:
>
> Hi Leon,
>
> I think it would be a mistake to introduce temporal coupling to prevent 
> typos. Here is an alternative that lets you identify "missing" keys specs at
> the time and place of your choosing, and then handle them as you deem 
> appropriate, without imposing those decisions on other users of spec:
>
> https://gist.github.com/stuarthalloway/f4c4297d344651c99827769e1c3d34e9
>
> Regards,
> Stu
>
>
>
>
> On Tue, Oct 10, 2017 at 12:33 PM, Leon Grapenthin  > wrote:
>
>> In terms of code loading, acyclic dependencies turned out to be a great 
>> design choice in Clojure - why its benefits shouldn't apply to or be 
>> justified for spec loading is totally unclear to me.
>>
>> To make my point more clear let me recap. I am simply asking for s/keys 
>> to throw if provided specs aren't registered. Because my colleagues and I 
>> myself made costly mistakes that would have been prevented. The most common 
>> scenario is a typo like the one I have illustrated above.
>>
>> I have asked what benefits justify current behavior?
>>
>> The only justification comes from Sean saying that it helps him 
>> prototyping. While I agree I also observe that this is simultaneously the 
>> trapdoor leading to such silently passing specs. And why prototyping needs 
>> should not be a primary concern in how s/keys behaves.
>>
>> I have tried to make a case for current behavior: It allows to say a key 
>> is there, without saying anything about its value. I have pointed out (s. 
>> a.) why this IMO has too little utility to justify anything.
>>
>> Regarding Clojure being a dynamic lanugage this doesn't really make a 
>> difference here: There is not much dynamic going on about registration and 
>> spec in general. Registration etc. is evaluated at compile time.  Note that 
>> s/def, s/keys etc. are all macros whose expansion is evaluated at compile 
>> time.
>>
>> On Monday, October 9, 2017 at 7:20:42 PM UTC+2, Beau Fabry wrote:
>>>
>>> > The argument that existence of specs provided to s/keys can only be 
>>> checked at runtime is false.
>>>
>>> > The argument that that recursive specs are impossible if existence of 
>>> specs provided to s/keys was checked at compile time is also false. 
>>>
>>> Could you explain to us why this is false? Clojure is a dynamic 
>>> language, as such I don't see how you could define a time when all specs 
>>> need to be present. How would I enter this spec at the repl if spec 
>>> definition was required at s/keys invocation time?
>>>
>>  
>>
>>>
>>> On Friday, October 6, 2017 at 4:32:41 PM UTC-7, Leon Grapenthin wrote:

 The argument that existence of specs provided to s/keys can only be 
 checked at runtime is false.

 The argument that that recursive specs are impossible if existence of 
 specs provided to s/keys was checked at compile time is also false. 

 The usecase for libraries is not convincing: If the libraries author 
 states "the map has to have a key K" nobody can spec K further since that 
 would be a race condition among consumers (who s/defs K first?). Requiring 
 the libraries author to declare K as any? would at least require him to 
 decide and convey his intent.

 The argument that not checking a value associated with a key is 
 corresponding to a guding design principle of map specs being based on a 
 keyset is not statin

Re: hashmap keys

[Timothy Baldridge]

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
values, and that's pretty fast.

So sure, the initial hash of one million symbols inside a vector may take a
fair amount of time, but I've never seen that in the wild.

Timothy

On Thu, Nov 9, 2017 at 10:08 PM, Jay Porcasi  wrote:

> 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 key? wouldn't hashing it take
> an unacceptable amount of time?
> yet Clojure manages to do just that and i wonder how
> thank you for any bit of clarification
> Jay
>
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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.

hashmap keys

[Jay Porcasi]

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 key? wouldn't hashing it take 
an unacceptable amount of time?
yet Clojure manages to do just that and i wonder how
thank you for any bit of clarification
Jay

-- 
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: difference between first & peek; rest & pop

[Ethan Brooks]

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 sequences..
>
> Thanks!
>
> Best,
>
> Seven Hong
>

-- 
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: Doc strings for complex cases?

[Matching Socks]

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 in your program.  Then your documentation report 
generator can use the metadata you attached.  (You wouldn't generate 
documentation directly from the source code text, of course.)  Since 
metadata is data structures, not just strings, the sky is the limit. 

By the way, there has also been discussion of best or expected use of the 
:arglists metadata.  Sometimes the arities you want to express in 
documentation differ from actual implementation, such as [& xs].  So 
probably you will not want a very rigid correspondence between your 
per-arity docstrings and the arities the compiler is aware of.

-- 
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: Doc strings for complex cases?

[Tim]

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 I don't care for 
because you can't do standard lookups and inline comments just get in the way 
making the code harder to read. I'm not sure how changes could work from a 
lookup perspective, but that's where my pain is. And also, last week, I spent a 
good amount of time revisting some older code trying figure out what was going 
on, but alas I had only put a high level description in for the defmulti. 

Anyways, it's all good. I've been revisiting editors and tooling and I just 
think that's the best use of my time.
Cheers,
Tim 

-- 
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.9.0-RC1

[Alex Miller]

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 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.9.0-RC1

[Rick Moynihan]

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 available.
>
> Try it via
>
> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-RC1
> - Leiningen: [org.clojure/clojure "1.9.0-RC1"]
>
> 1.9.0-RC1 is the same as 1.9.0-beta4.
>
> We would appreciate anything you can do to try out this release. We do not
> plan to make any further changes prior to 1.9.0 release unless regressions
> are found.
>
> --
> 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: Doc strings for complex cases?

[Didier]

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 itself? How would 
that work?

On Thursday, 9 November 2017 13:06:20 UTC-8, John Newman wrote:
>
> 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 list.
>
> On Nov 9, 2017 3:53 PM, "Mikhail Gusarov"  > wrote:
>
>> 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 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.

Re: Doc strings for complex cases?

[John Newman]

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 list.

On Nov 9, 2017 3:53 PM, "Mikhail Gusarov"  wrote:

> 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 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: Doc strings for complex cases?

[Mikhail Gusarov]

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 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: Doc strings for complex cases?

[Tim]

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 team 
implemented it then I'd be good because I know it would be maintained, but it 
doesn't seem like this is the case. So if it requires some custom work then I 
think I'd much rather do it at the tooling level as a plug-in to an editor. Ie, 
pull doc strings out all together and have them linked to and stored 
elsewhere... Maybe just store a db id in the doc string and go from there. I'll 
need to mull it over ;)

Thanks,
tim

-- 
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.data.xml with newline / return in attribute values

[Jochen]

>
> It's 'attribute value normalisation' - see 
> https://www.w3.org/TR/REC-xml/#AVNormalize 
> 


Thanks for the link, this indeed looks official :-).

Ciao

…Jochen

Am Donnerstag, 9. November 2017 12:32:06 UTC+1 schrieb Peter Hull:
>
> 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.w3.org/TR/REC-xml/#AVNormalize
> (I must admit the more times I read that section, the less I understand 
> it...)
>
> Anyway, if you use 
 entities instead of \n literals, does that do the 
> round trip properly?
>
>  
>

-- 
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.data.xml with newline / return in attribute values

[Jochen]

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 replace the &# in the 
output string with &#, which works, but of course does not scale to large 
xml files and might have side effects.
I hope there must be an official way to configure the parser or something. 
I cannot do something about the attribute content as it comes from outside.

Ciao

…Jochen


Am Donnerstag, 9. November 2017 12:32:06 UTC+1 schrieb Peter Hull:
>
> 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.w3.org/TR/REC-xml/#AVNormalize
> (I must admit the more times I read that section, the less I understand 
> it...)
>
> Anyway, if you use 
 entities instead of \n literals, does that do the 
> round trip properly?
>
>  
>

Am Donnerstag, 9. November 2017 12:32:06 UTC+1 schrieb Peter Hull:
>
> 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.w3.org/TR/REC-xml/#AVNormalize
> (I must admit the more times I read that section, the less I understand 
> it...)
>
> Anyway, if you use 
 entities instead of \n literals, does that do the 
> round trip properly?
>
>  
>

-- 
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.data.xml with newline / return in attribute values

[Peter Hull]

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.w3.org/TR/REC-xml/#AVNormalize
(I must admit the more times I read that section, the less I understand 
it...)

Anyway, if you use 
 entities instead of \n literals, does that do the 
round trip properly?

 

-- 
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.data.xml with newline / return in attribute values

[Jochen]

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\nquux"}))
 (xml/parse-str)))
;; => #xml/element{:tag :foo, :attrs {:bar "Baz quux"}}

Ciao

…Jochen


Am Donnerstag, 9. November 2017 11:56:18 UTC+1 schrieb Joost:
>
> Hi Jochen
>
> Since newlines and crs are allowed in attribute values, you don't need to 
> escape them. The correctly escaped version and the unescaped version of the 
> XML are exactly equivalent.
>
> Joost.
>
> On Thursday, November 9, 2017 at 9:48:07 AM UTC+1, Jochen wrote:
>>
>> 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 escaped cr/lf (
) in an 
>> attribute value, it is parsed correctly., but when I write it out again the 
>> \r\n appears in the output unescaped, breaking the attribute value on next 
>> read.
>>
>> Here is some real stuff showing the issue:
>>   ;; cr lf are not escaped:
>>   (prn (xml/emit-str (xml/element :foo {:bar "Baz\r\nquux"})))
>>   ;; => "> bar=\"Baz\r\nquux\">"
>>
>>   ;; if we escape manually, the ampersand is escaped:
>>   (prn (xml/emit-str (xml/element :foo {:bar "Baz
quux"})))
>>   ;; => "> bar=\"Baz
quux\">"
>>   
>> ;; we can fix after the fact with some string replacer, but this feels 
>> really hacky:
>>   (prn (-> (xml/emit-str (xml/element :foo {:bar "Baz
quux"}))
>>(str/replace "&#" "&#")))
>>   ;; => "> bar=\"Baz
quux\">"
>>
>>   ;; although it is then reparsed correctly: 
>>   (prn (-> (xml/emit-str (xml/element :foo {:bar "Baz
quux"}))
>>(str/replace "&#" "&#")
>>(xml/parse-str)))
>>  ;;=> #clojure.data.xml.Element{:tag :foo, :attrs {:bar "Baz\r\nquux"}, 
>> :content ()} 
>>
>> Looking into the emit code, it seems like this is a Java XMLStreamWriter 
>> issue?!
>>
>> Any idea how to fix this in a clean way?
>>
>> Ciao
>>
>> …Jochen
>>
>>
>  

-- 
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.

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

[Jochen]

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 escaped cr/lf (
) in an 
attribute value, it is parsed correctly., but when I write it out again the 
\r\n appears in the output unescaped, breaking the attribute value on next 
read.

Here is some real stuff showing the issue:
  ;; cr lf are not escaped:
  (prn (xml/emit-str (xml/element :foo {:bar "Baz\r\nquux"})))
  ;; => ""

  ;; if we escape manually, the ampersand is escaped:
  (prn (xml/emit-str (xml/element :foo {:bar "Baz
quux"})))
  ;; => ""
  
;; we can fix after the fact with some string replacer, but this feels 
really hacky:
  (prn (-> (xml/emit-str (xml/element :foo {:bar "Baz
quux"}))
   (str/replace "&#" "&#")))
  ;; => ""

  ;; although it is then reparsed correctly: 
  (prn (-> (xml/emit-str (xml/element :foo {:bar "Baz
quux"}))
   (str/replace "&#" "&#")
   (xml/parse-str)))
 ;;=> #clojure.data.xml.Element{:tag :foo, :attrs {:bar "Baz\r\nquux"}, 
:content ()} 

Looking into the emit code, it seems like this is a Java XMLStreamWriter 
issue?!

Any idea how to fix this in a clean way?

Ciao

…Jochen

-- 
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.