as.yaml() causing crash in some cases

[sckott]

We are getting an error with using as.yaml() in some cases. In the rfigshare package (https://github.com/ropensci/rfigshare), here's the issue for this bug ropensci-archive/rfigshare#88

To reproduce this you can do

install.packages("rfigshare")
library("rfigshare")
fs_search(query="Boettiger")

Some html character strings are causing this problem, e.g., this string

string <- "<p>The membrane surface is depicted in the presence of one, two, or three bonds with a rigid substrate (xy- and z- coordinates are not to scale); <i>\xc3<sub>s</sub></i>\n=\n1000 pN/nm, <i>l<sub>g</sub></i>\n=\n45 nm, <i>\xc3<sub>g</sub></i>\n=\n0.01 pN/nm. The inlays are the corresponding xy- contour maps of the z- membrane displacements. Note that larger areas of the membrane are brought in closer proximity to the ECM substrate when more bonds are placed in close proximity to each other.</p>"

throws an error

as.yaml(string)

Error in as.yaml(string)  : 
  Emitter error: expected SCALAR, SEQUENCE-START, MAPPING-START, or ALIAS

Here's another string that causes the same error

<p>The plots in (A) are temporal snapshots of the xy- positions of inactive integrins (red circles), active unbound integrins (light blue squares), and bound integrins (dark blue dots) obtained during simulation of integrin dynamics on a rigid ECM substrate with best-estimate parameters (<a href=\"http://www.ploscompbiol.org/article/info:doi/10.1371/journal.pcbi.1000604#pcbi-1000604-t001\" target=\"_blank\">Table 1</a>). The corresponding equilibrium z-direction membrane deformations are depicted in (B). Simulated area: 3 \xb5m\xd73 \xb5m.</p>"

Should we process our html somehow to avoid this? Or should something be done in yaml?

[viking]

That is definitely a bug. I'll check it out.

[sckott]

great, thanks

[ofurkusi]

This seems to be related to the bug described by @reinholdsson in #4

[sckott]

thanks, but still doesn't work, whether using unicode=TRUE or unicode=FALSE

[ofurkusi]

When you define the string, R converts \xc3 to the UTF-8 character Ã. When you run as.yaml on the string, it fails because of this non ASCII character just as in #4.

You may, possibly, circumvent this by escaping the backslash, and if that is not enough, hack it by adding a non visible space ‌ inbetween, e.g. \\‌xc3.

In the latter string \xb5 is converted to µ and \xd7 to ×.

You can verify this by printing the strings, or by typing

"\xc3\xb5\xd7"

[spgarbet]

Moved into ticket #113