Update notes for 2017-02-20

This commit is contained in:
Alan Orth 2017-02-20 18:40:25 +02:00
parent 841ffc952c
commit c89ffca331
Signed by: alanorth
GPG Key ID: 0FB860CC9C45B1B9
5 changed files with 70 additions and 1 deletions

View File

@ -175,3 +175,16 @@ dspace=# update metadatavalue set text_value = regexp_replace(text_value, 'http:
- Fix label of CCAFS subjects in Atmire Listings and Reports module
- Help Sisay with SQL commands
- Help Paola from CCAFS with the Atmire Listings and Reports module
- Testing the `fix-metadata-values.py` script on macOS and it seems like we don't need to use `.encode('utf-8')` anymore when printing strings to the screen
- It seems this might have only been a temporary problem, as both Python 3.5.2 and 3.6.0 are able to print the problematic string "Entwicklung & Ländlicher Raum" without the `encode()` call, but print it as a bytes when it *is* used:
```
$ python
Python 3.6.0 (default, Dec 25 2016, 17:30:53)
>>> print('Entwicklung & Ländlicher Raum')
Entwicklung & Ländlicher Raum
>>> print('Entwicklung & Ländlicher Raum'.encode())
b'Entwicklung & L\xc3\xa4ndlicher Raum'
```
- So for now I will remove the encode call from the script (though it was never used on the versions on the Linux hosts), leading me to believe it really *was* a temporary problem, perhaps due to macOS or the Python build I was using.

View File

@ -92,7 +92,7 @@ Looks like we’ll be using cg.identifier.ccafsprojectpii as the field name
"headline": "February, 2017",
"url": "https://alanorth.github.io/cgspace-notes/2017-02/",
"wordCount": "1211",
"wordCount": "1347",
"datePublished": "2017-02-07T07:04:52-08:00",
@ -371,6 +371,20 @@ dspace=# update metadatavalue set text_value = 'https://dx.doi.org/10.15446/agro
<li>Fix label of CCAFS subjects in Atmire Listings and Reports module</li>
<li>Help Sisay with SQL commands</li>
<li>Help Paola from CCAFS with the Atmire Listings and Reports module</li>
<li>Testing the <code>fix-metadata-values.py</code> script on macOS and it seems like we don&rsquo;t need to use <code>.encode('utf-8')</code> anymore when printing strings to the screen</li>
<li>It seems this might have only been a temporary problem, as both Python 3.5.2 and 3.6.0 are able to print the problematic string &ldquo;Entwicklung &amp; Ländlicher Raum&rdquo; without the <code>encode()</code> call, but print it as a bytes when it <em>is</em> used:</li>
</ul>
<pre><code>$ python
Python 3.6.0 (default, Dec 25 2016, 17:30:53)
&gt;&gt;&gt; print('Entwicklung &amp; Ländlicher Raum')
Entwicklung &amp; Ländlicher Raum
&gt;&gt;&gt; print('Entwicklung &amp; Ländlicher Raum'.encode())
b'Entwicklung &amp; L\xc3\xa4ndlicher Raum'
</code></pre>
<ul>
<li>So for now I will remove the encode call from the script (though it was never used on the versions on the Linux hosts), leading me to believe it really <em>was</em> a temporary problem, perhaps due to macOS or the Python build I was using.</li>
</ul>

View File

@ -219,6 +219,20 @@ dspace=# update metadatavalue set text_value = &#39;https://dx.doi.org/10.15446/
&lt;li&gt;Fix label of CCAFS subjects in Atmire Listings and Reports module&lt;/li&gt;
&lt;li&gt;Help Sisay with SQL commands&lt;/li&gt;
&lt;li&gt;Help Paola from CCAFS with the Atmire Listings and Reports module&lt;/li&gt;
&lt;li&gt;Testing the &lt;code&gt;fix-metadata-values.py&lt;/code&gt; script on macOS and it seems like we don&amp;rsquo;t need to use &lt;code&gt;.encode(&#39;utf-8&#39;)&lt;/code&gt; anymore when printing strings to the screen&lt;/li&gt;
&lt;li&gt;It seems this might have only been a temporary problem, as both Python 3.5.2 and 3.6.0 are able to print the problematic string &amp;ldquo;Entwicklung &amp;amp; Ländlicher Raum&amp;rdquo; without the &lt;code&gt;encode()&lt;/code&gt; call, but print it as a bytes when it &lt;em&gt;is&lt;/em&gt; used:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;$ python
Python 3.6.0 (default, Dec 25 2016, 17:30:53)
&amp;gt;&amp;gt;&amp;gt; print(&#39;Entwicklung &amp;amp; Ländlicher Raum&#39;)
Entwicklung &amp;amp; Ländlicher Raum
&amp;gt;&amp;gt;&amp;gt; print(&#39;Entwicklung &amp;amp; Ländlicher Raum&#39;.encode())
b&#39;Entwicklung &amp;amp; L\xc3\xa4ndlicher Raum&#39;
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;So for now I will remove the encode call from the script (though it was never used on the versions on the Linux hosts), leading me to believe it really &lt;em&gt;was&lt;/em&gt; a temporary problem, perhaps due to macOS or the Python build I was using.&lt;/li&gt;
&lt;/ul&gt;</description>
</item>

View File

@ -219,6 +219,20 @@ dspace=# update metadatavalue set text_value = &#39;https://dx.doi.org/10.15446/
&lt;li&gt;Fix label of CCAFS subjects in Atmire Listings and Reports module&lt;/li&gt;
&lt;li&gt;Help Sisay with SQL commands&lt;/li&gt;
&lt;li&gt;Help Paola from CCAFS with the Atmire Listings and Reports module&lt;/li&gt;
&lt;li&gt;Testing the &lt;code&gt;fix-metadata-values.py&lt;/code&gt; script on macOS and it seems like we don&amp;rsquo;t need to use &lt;code&gt;.encode(&#39;utf-8&#39;)&lt;/code&gt; anymore when printing strings to the screen&lt;/li&gt;
&lt;li&gt;It seems this might have only been a temporary problem, as both Python 3.5.2 and 3.6.0 are able to print the problematic string &amp;ldquo;Entwicklung &amp;amp; Ländlicher Raum&amp;rdquo; without the &lt;code&gt;encode()&lt;/code&gt; call, but print it as a bytes when it &lt;em&gt;is&lt;/em&gt; used:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;$ python
Python 3.6.0 (default, Dec 25 2016, 17:30:53)
&amp;gt;&amp;gt;&amp;gt; print(&#39;Entwicklung &amp;amp; Ländlicher Raum&#39;)
Entwicklung &amp;amp; Ländlicher Raum
&amp;gt;&amp;gt;&amp;gt; print(&#39;Entwicklung &amp;amp; Ländlicher Raum&#39;.encode())
b&#39;Entwicklung &amp;amp; L\xc3\xa4ndlicher Raum&#39;
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;So for now I will remove the encode call from the script (though it was never used on the versions on the Linux hosts), leading me to believe it really &lt;em&gt;was&lt;/em&gt; a temporary problem, perhaps due to macOS or the Python build I was using.&lt;/li&gt;
&lt;/ul&gt;</description>
</item>

View File

@ -218,6 +218,20 @@ dspace=# update metadatavalue set text_value = &#39;https://dx.doi.org/10.15446/
&lt;li&gt;Fix label of CCAFS subjects in Atmire Listings and Reports module&lt;/li&gt;
&lt;li&gt;Help Sisay with SQL commands&lt;/li&gt;
&lt;li&gt;Help Paola from CCAFS with the Atmire Listings and Reports module&lt;/li&gt;
&lt;li&gt;Testing the &lt;code&gt;fix-metadata-values.py&lt;/code&gt; script on macOS and it seems like we don&amp;rsquo;t need to use &lt;code&gt;.encode(&#39;utf-8&#39;)&lt;/code&gt; anymore when printing strings to the screen&lt;/li&gt;
&lt;li&gt;It seems this might have only been a temporary problem, as both Python 3.5.2 and 3.6.0 are able to print the problematic string &amp;ldquo;Entwicklung &amp;amp; Ländlicher Raum&amp;rdquo; without the &lt;code&gt;encode()&lt;/code&gt; call, but print it as a bytes when it &lt;em&gt;is&lt;/em&gt; used:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;$ python
Python 3.6.0 (default, Dec 25 2016, 17:30:53)
&amp;gt;&amp;gt;&amp;gt; print(&#39;Entwicklung &amp;amp; Ländlicher Raum&#39;)
Entwicklung &amp;amp; Ländlicher Raum
&amp;gt;&amp;gt;&amp;gt; print(&#39;Entwicklung &amp;amp; Ländlicher Raum&#39;.encode())
b&#39;Entwicklung &amp;amp; L\xc3\xa4ndlicher Raum&#39;
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;So for now I will remove the encode call from the script (though it was never used on the versions on the Linux hosts), leading me to believe it really &lt;em&gt;was&lt;/em&gt; a temporary problem, perhaps due to macOS or the Python build I was using.&lt;/li&gt;
&lt;/ul&gt;</description>
</item>