[Valid Atom 1.0] This is a valid Atom 1.0 feed.


This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.


  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <feed xmlns="">
  3.    <title>The Perl Foundation</title>
  4.    <link rel="alternate" type="text/html" href="" />
  5.    <link rel="self" type="application/atom+xml" href="" />
  6.    <id>,2010-03-22://18</id>
  7.    <updated>2017-04-27T01:44:36Z</updated>
  9.    <generator uri="">Movable Type Pro 6.2.2</generator>
  11. <entry>
  12.    <title>March 2017 Grant Votes</title>
  13.    <link rel="alternate" type="text/html" href="" />
  14.    <id>,2017://18.3868</id>
  16.    <published>2017-04-27T00:04:17Z</published>
  17.    <updated>2017-04-27T01:44:36Z</updated>
  19.    <summary></summary>
  20.    <author>
  21.        <name>Coke</name>
  23.    </author>
  25.        <category term="Grants" scheme="" />
  28.    <content type="html" xml:lang="en-us" xml:base="">
  30.        <![CDATA[<p>The Grants Committee has concluded the voting of the March 2017 round.</p>
  32. <p>There were two proposals in this round:</p>
  34. <h1>Improving the Robustness of Unicode Support…</h1>
  36. <p><a href="">Improving the Robustness of Unicode Support in Rakudo on MoarVM (7,500 USD)</a></p>
  38. <p>Voting results: 6 Yes votes, and 2 abstentions with a score of 21 (5+5+5+4+1+1+0+0)</p>
  40. <p>This grant is approved, and will be funded.</p>
  42. <p>Sam's previous contributions in this area make her likely to succeed in making marked improvements to the
  43. (already good!) Unicode support in Rakudo Perl 6 on MoarVM.</p>
  45. <h1>RPerl User Documentation, Part 3</h1>
  47. <p><a href="">RPerl User Documentation, Part 3 (2,400 USD)</a></p>
  49. <p>Voting results: 8 No votes.</p>
  51. <p>This grant is not approved.</p>
  53. <p>Concerns were raised about the efficacy of previous grants to increase RPerl's userbase and outreach,
  54. as well as concerns about interactions with other members of the Perl community.</p>
  56. <h1>Next Round </h1>
  58. <p>Our next round will be in May.
  59. You can <a href="" title="submit proposals">submit proposals</a> now.
  60. If you want to help funding, please visit <a href="" title="our donations page">our donations page</a>
  61. We appreciate all the donors which made the grant
  62. program possible. Also see the <a href="" title="press releases">press releases</a> for
  63. the recent major donations.</p>
  64. ]]>
  65.    </content>
  66. </entry>
  68. <entry>
  69.    <title> Perl 6 IO Grant: April 2017 Report</title>
  70.    <link rel="alternate" type="text/html" href="" />
  71.    <id>,2017://18.3867</id>
  73.    <published>2017-04-26T01:56:42Z</published>
  74.    <updated>2017-04-26T01:59:07Z</updated>
  76.    <summary></summary>
  77.    <author>
  78.        <name>Coke</name>
  80.    </author>
  82.        <category term="Grants" scheme="" />
  85.    <content type="html" xml:lang="en-us" xml:base="">
  87.        <![CDATA[<p><em>Zoffix Znet provided this report on April 19, 2017</em></p>
  89. <h1>Perl 6 IO TPF Grant: Monthly Report (April, 2017)</h1>
  91. <p>This document is the April, 2017 progress report for <a href="">TPF Standardization,
  92. Test Coverage, and Documentation of Perl 6 I/O Routines
  93. grant</a></p>
  95. <h2>Timing</h2>
  97. <p>As proposed to and approved by the Grant Manager, I've extended the due date
  98. for this grant by 1 extra month, in exchange for doing some extra optimization
  99. work on IO routines at no extra cost. The new completion date is May 22nd;
  100. right after the next Rakudo compiler release.</p>
  102. <h2>Communications</h2>
  104. <p>I've created and published three notices as part of this grant, informing the
  105. users on what is changing and how to best upgrade their code, where needed:</p>
  107. <ul>
  108. <li><a href="">Upgrade Information for Changes Due to IO Grant Work</a></li>
  109. <li><a href="">PART 2: Upgrade Information for Changes Due to IO Grant Work</a></li>
  110. <li><a href="">PART 3: Information on Changes Due to IO Grant Work</a></li>
  111. </ul>
  113. <h2>IO Action Plan Progress</h2>
  115. <p>Most of the <a href="">IO Action Plan</a> has been implemented and got shipped in Rakudo's 2017.04.2 release. The remaining items are:</p>
  117. <ul>
  118. <li>Implement better way to signal closed handle status (was omited from release due to original suggestion to do this not being ideal; likely better to do this on the VM end)</li>
  119. <li>Implement IO::CatHandle as a generalized IO::ArgFiles (was omited from release because it was decided to make it mostly-usable wherever IO::Handle can be used, and IO::ArgFiles is far from that, having only a handful of methods implemented)</li>
  120. <li>Optimization of the way we perform <code>stat</code> calls for multiple file tests (entirely internal that requires no changes to users' code)</li>
  121. </ul>
  123. <h2>Documentation and Coverage Progress</h2>
  125. <p>In my spreadsheet with all the IO routines and their candidates, the totals
  126. show that 40% have been documented and tested. Some of the remaining 60% may
  127. already have tests/docs added when implementing IO Action Plan or ealier and
  128. merely need checking and verification.</p>
  130. <h2>Optimizations</h2>
  132. <p>Some of the optimizations I promised to deliver in exchange for grant deadline
  133. extension were already done on IO::Spec::Unix and IO::Path
  134. routines and have made it into the 2017.04.2 release. Most of the optimizations
  135. that will be done in the upcoming month will be done in IO::Spec::Win32 and
  136. will largely affect Windows users.</p>
  138. <h4>IO Optimizations in 2017.04.2 Done by Other Core Members:</h4>
  140. <ul>
  141. <li>Elizabeth Mattijsen made .slurp 2x faster <a href="">rakudo/b4d80c0</a></li>
  142. <li>Samantha McVey made nqp::index—which is used in path operations—2x faster <a href="">rakudo/f1fc879</a></li>
  143. <li>IO::Pipe.lines was made 3.2x faster by relying on work done by Elizabeth Mattijsen <a href="">rakudo/0c62815</a></li>
  144. </ul>
  146. <h2>Tickets Resolved</h2>
  148. <p>The following tickets have been resolved as part of the grant:</p>
  150. <ul>
  151. <li><a href="">RT#130460 Can we relax indir's test on the target directory?</a>: Resolved by making indir's default test to be only <code>:d</code></li>
  152. <li><a href="">RT#130900: nul in pathname</a>: Resolved by checking the path for nul and throwing when found</li>
  153. <li><a href="">RT#127407: [RFC] (1) add method IO::Path.stemname; (2) expand method</a>: RFC rejected, but the described functionality is now available via the .extension method that was made much more powerful as part of IO Action Plan</li>
  154. </ul>
  156. <p>Possibly more tickets were addressed by the IO Action Plan implementation, but
  157. they still need further review.</p>
  159. <h2>Bugs Fixed</h2>
  161. <ul>
  162. <li>Fixed a bug in <code>IO::Path.resolve</code> with combiners tucked on the path
  163. separator. Fix in
  164. <a href="">rakudo/9d8e391f3b</a>;
  165. tests in
  166. <a href="">roast/92217f75ce</a>. The bug was identified by Timo Paulssen while testing secure implementation of IO::Path.child</li>
  167. </ul>
  169. <h4>IO Bug Fixes in 2017.04.2 Done by Other Core Members:</h4>
  171. <ul>
  172. <li>Timo Paulssen fixed a bug with IO::Path types not being accepted by
  173. <code>is native</code> NativeCall trait <a href="">rakudo/99840804</a></li>
  174. <li>Elizabeth Mattijsen fixed an issue in assignment to dynamics. This made it possible to <code>temp</code> <code>$*TMPDIR</code> variable <a href="">rakudo/1b9d53</a></li>
  175. <li>Jonathan Worthington fixed a crash when slurping large files in binary mode with &amp;slurp or IO::Path.slurp <a href="">rakudo/d0924f1a2</a></li>
  176. <li>Jonathan Worthington fixed a bug with binary slurp reading zero bytes when another thread is causing a lot of GC <a href="">rakudo/756877e</a></li>
  177. </ul>
  179. <h2>Commits</h2>
  181. <p>So far, I've commited 192 IO grant commits to rakudo/roast/doc repos.</p>
  183. <h3>Rakudo</h3>
  185. <p>69 IO grant commits:</p>
  187. <ul>
  188. <li><a href=""><code>c6fd736</code></a> <code>Make about 63x faster</code></li>
  189. <li><a href=""><code>7112a08</code></a> <code>Add :D on invocant for file tests</code></li>
  190. <li><a href=""><code>8bacad8</code></a> <code>Implement IO::Path.sibling</code></li>
  191. <li><a href=""><code>a98b285</code></a> <code>Remove IO::Path.child-secure</code></li>
  192. <li><a href=""><code>0b5a41b</code></a> <code>Rename IO::Path.concat-with to .add</code></li>
  193. <li><a href=""><code>9d8e391</code></a> <code>Fix IO::Path.resolve with combiners; timotimo++</code></li>
  194. <li><a href=""><code>1887114</code></a> <code>Implement IO::Path.child-secure</code></li>
  195. <li><a href=""><code>b8458d3</code></a> <code>Reword method child for cleaner code</code></li>
  196. <li><a href=""><code>51e4629</code></a> <code>Amend rules for last part in IO::Path.resolve</code></li>
  197. <li><a href=""><code>9a2446c</code></a> <code>Move Bool return value to signature</code></li>
  198. <li><a href=""><code>214198b</code></a> <code>Implement proper args for IO::Handle.lock</code></li>
  199. <li><a href=""><code>c95c4a7</code></a> <code>Make IO::Path/IO::Special do IO role</code></li>
  200. <li><a href=""><code>fd503f8</code></a> <code>grant] Remove role IO and its .umask method"</code></li>
  201. <li><a href=""><code>0e36bb2</code></a> <code>Make IO::Spec::Win32!canon-cat 2.3x faster</code></li>
  202. <li><a href=""><code>40217ed</code></a> <code>Swap .child to .concat-with in all the guts</code></li>
  203. <li><a href=""><code>490ffd1</code></a> <code>Do not use self.Str in IO::Path errors</code></li>
  204. <li><a href=""><code>1f689a9</code></a> <code>Fix up IO::Handle.Str</code></li>
  205. <li><a href=""><code>c01ebea</code></a> <code>Make IO::Path.mkdir return invocant on success</code></li>
  206. <li><a href=""><code>d46e8df</code></a> <code>Add IO::Pipe .path and .IO methods</code></li>
  207. <li><a href=""><code>6ee71c2</code></a> <code>Coerce mode in IO::Path.mkdir to Int</code></li>
  208. <li><a href=""><code>0d9ecae</code></a> <code>Remove multi-dir &amp;mkdir</code></li>
  209. <li><a href=""><code>ff97083</code></a> <code>Straighten up rename, move, and copy</code></li>
  210. <li><a href=""><code>7f73f92</code></a> <code>Make private</code></li>
  211. <li><a href=""><code>da1dea2</code></a> <code>Fix &amp;symlink and &amp;link</code></li>
  212. <li><a href=""><code>8c09c84</code></a> <code>Fix symlink and link routines</code></li>
  213. <li><a href=""><code>90da80f</code></a> <code>Rework read methods in IO::Path/IO::Handle</code></li>
  214. <li><a href=""><code>c13480c</code></a> <code>IO::Path.slurp: make 12%-35% faster; propagate Failures</code></li>
  215. <li><a href=""><code>f1b4af7</code></a> <code>Implement IO::Handle.slurp</code></li>
  216. <li><a href=""><code>184d499</code></a> <code>Make IO::Handle.Supply respect handle's mode</code></li>
  217. <li><a href=""><code>b6838ee</code></a> <code>Remove .f check in .z</code></li>
  218. <li><a href=""><code>6a8d63d</code></a> <code>Implement :completely param in IO::Path.resolve</code></li>
  219. <li><a href=""><code>e681498</code></a> <code>Make IO::Path throw when path contains NUL byte</code></li>
  220. <li><a href=""><code>b4358af</code></a> <code>Delete code for IO::Spec::Win32.catfile</code></li>
  221. <li><a href=""><code>0a442ce</code></a> <code>Remove type constraint in IO::Spec::Cygwin.canonpath</code></li>
  222. <li><a href=""><code>0c8bef5</code></a> <code>Implement :parent in IO::Spec::Cygwin.canonpath</code></li>
  223. <li><a href=""><code>a0b82ed</code></a> <code>Make IO::Path::* actually instantiate a subclass</code></li>
  224. <li><a href=""><code>67f06b2</code></a> <code>Run S32-io/io-special.t test file</code></li>
  225. <li><a href=""><code>954e69e</code></a> <code>Fix return value of IO::Special methods</code></li>
  226. <li><a href=""><code>a432b3d</code></a> <code>Remove IO::Path.abspath (part 2)</code></li>
  227. <li><a href=""><code>94a6909</code></a> <code>Clean up IO::Spec::Unix.abs2rel a bit</code></li>
  228. <li><a href=""><code>966a7e3</code></a> <code>Implement IO::Path.concat-with</code></li>
  229. <li><a href=""><code>50aea2b</code></a> <code>Restore IO::Handle.IO</code></li>
  230. <li><a href=""><code>15a25da</code></a> <code>Fix ambiguity in empty extension vs no extension</code></li>
  231. <li><a href=""><code>b1e7a01</code></a> <code>Implement IO::Path.extension 2.0</code></li>
  232. <li><a href=""><code>b62d1a7</code></a> <code>Give $*TMPDIR a container</code></li>
  233. <li><a href=""><code>099512b</code></a> <code>Clean up and improve all spurt routines</code></li>
  234. <li><a href=""><code>cb27bce</code></a> <code>Clean up &amp;open and</code></li>
  235. <li><a href=""><code>4c31903</code></a> <code>Add S32-io/chdir-process.t to list of test files to run</code></li>
  236. <li><a href=""><code>5464b82</code></a> <code>Improve &amp;*chdir</code></li>
  237. <li><a href=""><code>2483d68</code></a> <code>Fix regression in &amp;chdir's failure mode</code></li>
  238. <li><a href=""><code>ca1acb7</code></a> <code>Fix race in &amp;indir(IO::Path …)</code></li>
  239. <li><a href=""><code>a0ef2ed</code></a> <code>Improve &amp;chdir, &amp;indir, and IO::Path.chdir</code></li>
  240. <li><a href=""><code>aa62cd5</code></a> <code>Remove &amp;tmpdir and &amp;homedir</code></li>
  241. <li><a href=""><code>a5800a1</code></a> <code>Implement IO::Handle.spurt</code></li>
  242. <li><a href=""><code>36ad92a</code></a> <code>Remove 15 methods from IO::Handle</code></li>
  243. <li><a href=""><code>87987c2</code></a> <code>Remove role IO and its .umask method</code></li>
  244. <li><a href=""><code>9d8d7b2</code></a> <code>Log all changes to plan made during review period</code></li>
  245. <li><a href=""><code>0c7e4a0</code></a> <code>Do not capture args in .IO method</code></li>
  246. <li><a href=""><code>c360ac2</code></a> <code>Fix smartmatch of Cool ~~ IO::Path</code></li>
  247. <li><a href=""><code>fa9aa47</code></a> <code>Make R::I::SET_LINE_ENDING_ON_HANDLE 4.1x Faster</code></li>
  248. <li><a href=""><code>0111f10</code></a> <code>Make IO::Spec::Unix.catdir 3.9x Faster</code></li>
  249. <li><a href=""><code>4fdebc9</code></a> <code>Make IO::Spec::Unix.split 36x Faster</code></li>
  250. <li><a href=""><code>dcf1bb2</code></a> <code>Make IO::Spec::Unix.rel2abs 35% faster</code></li>
  251. <li><a href=""><code>55abc6d</code></a> <code>Improve IO::Path.child perf on *nix</code></li>
  252. <li><a href=""><code>4032953</code></a> <code>Make 75% faster</code></li>
  253. <li><a href=""><code>a01d679</code></a> <code>Remove IO::Path.pipe</code></li>
  254. <li><a href=""><code>212cc8a</code></a> <code>Remove IO::Path.Bridge</code></li>
  255. <li><a href=""><code>76f7187</code></a> <code>Do not cache IO::Path.e results</code></li>
  256. <li><a href=""><code>dd4dfb1</code></a> <code>Fix crash in IO::Special .WHICH/.Str</code></li>
  257. </ul>
  259. <h3>Perl 6 Specification</h3>
  261. <p>47 IO grant commits:</p>
  263. <ul>
  264. <li><a href=""><code>3b36d4d</code></a> <code>Test IO::Path.sibling</code></li>
  265. <li><a href=""><code>7a063b5</code></a> <code>Fudge .child-secure tests</code></li>
  266. <li><a href=""><code>39677c4</code></a> <code>IO::Path.concat-with got renamed to .add</code></li>
  267. <li><a href=""><code>92217f7</code></a> <code>Test IO::Path.child-secure with combiners</code></li>
  268. <li><a href=""><code>f3c5dae</code></a> <code>Test IO::Path.child-secure</code></li>
  269. <li><a href=""><code>a716962</code></a> <code>Amend rules for last part in IO::Path.resolve</code></li>
  270. <li><a href=""><code>4194755</code></a> <code>Test IO::Handle.lock/.unlock</code></li>
  271. <li><a href=""><code>64ff572</code></a> <code>Cover IO::Path/IO::Pipe's .Str/.path/.IO</code></li>
  272. <li><a href=""><code>637500d</code></a> <code>Spec IO::Pipe.path/.IO returns IO::Path type object</code></li>
  273. <li><a href=""><code>8fa49e1</code></a> <code>Test link routines</code></li>
  274. <li><a href=""><code>416b746</code></a> <code>Test symlink routines</code></li>
  275. <li><a href=""><code>d4353b6</code></a> <code>Rewrite .l on broken symlinks test</code></li>
  276. <li><a href=""><code>7e4a2ae</code></a> <code>Swap .slurp-rest to .slurp</code></li>
  277. <li><a href=""><code>a4c53b0</code></a> <code>Use bin IO::Handle to test its .Supply</code></li>
  278. <li><a href=""><code>feecaf0</code></a> <code>Expand file tests</code></li>
  279. <li><a href=""><code>a809f0f</code></a> <code>Expand IO::Path.resolve tests</code></li>
  280. <li><a href=""><code>ee7f05b</code></a> <code>Move is-path sub to top so it can be reused</code></li>
  281. <li><a href=""><code>b16fbd3</code></a> <code>Add tests to check nul byte is rejected</code></li>
  282. <li><a href=""><code>8f73ad8</code></a> <code>Change \0 roundtrip test to \t roundtrip test</code></li>
  283. <li><a href=""><code>7c7fbb4</code></a> <code>Cover :parent arg in IO::Spec::Cygwin.canonpath</code></li>
  284. <li><a href=""><code>896033a</code></a> <code>Cover IO::Spec::QNX.canonpath</code></li>
  285. <li><a href=""><code>c3c51ed</code></a> <code>Cover IO::Spec::Win32.basename</code></li>
  286. <li><a href=""><code>d8707e7</code></a> <code>Cover IO::Spec::Unix.basename</code></li>
  287. <li><a href=""><code>bd8d167</code></a> <code>Test IO::Path::* instantiate a subclass</code></li>
  288. <li><a href=""><code>43ec543</code></a> <code>Cover methods of IO::Special</code></li>
  289. <li><a href=""><code>e5dc376</code></a> <code>Expand IO::Path.accessed tests</code></li>
  290. <li><a href=""><code>0e47f25</code></a> <code>Test IO::Path.concat-with</code></li>
  291. <li><a href=""><code>305f206</code></a> <code>Test empty-string extensions in IO::Path.extension</code></li>
  292. <li><a href=""><code>2f09f18</code></a> <code>Fix incorrect test</code></li>
  293. <li><a href=""><code>b23e53e</code></a> <code>Test IO::Path.extension</code></li>
  294. <li><a href=""><code>1d4e881</code></a> <code>Test $*TMPDIR can be temped</code></li>
  295. <li><a href=""><code>79ff022</code></a> <code>Expand &amp;spurt and IO::Path.spurt tests</code></li>
  296. <li><a href=""><code>ba3e7be</code></a> <code>Merge S32-io/path.t and S32-io/io-path.t</code></li>
  297. <li><a href=""><code>3c4e81b</code></a> <code>Test IO::Path.Str works as advertised</code></li>
  298. <li><a href=""><code>86c5f9c</code></a> <code>Delete qp{} tests</code></li>
  299. <li><a href=""><code>430ab89</code></a> <code>Test &amp;*chdir</code></li>
  300. <li><a href=""><code>86f79ce</code></a> <code>Expand &amp;chdir tests</code></li>
  301. <li><a href=""><code>73a5448</code></a> <code>Remove two fudged &amp;chdir tests</code></li>
  302. <li><a href=""><code>04333b3</code></a> <code>Test &amp;indir fails with non-existent paths by default</code></li>
  303. <li><a href=""><code>bd46836</code></a> <code>Amend &amp;indir race tests</code></li>
  304. <li><a href=""><code>f48198f</code></a> <code>Test &amp;indir</code></li>
  305. <li><a href=""><code>5a7a365</code></a> <code>Expand IO::Spec::*.tmpdir tests</code></li>
  306. <li><a href=""><code>14b6844</code></a> <code>Use Numeric instead of IO role in dispatch test</code></li>
  307. <li><a href=""><code>8d6ca7a</code></a> <code>Cover IO::Path.ACCEPTS</code></li>
  308. <li><a href=""><code>091931a</code></a> <code>Expand &amp;open tests</code></li>
  309. <li><a href=""><code>465795c</code></a> <code>Test IO::Path.lines(*) does not crash</code></li>
  310. <li><a href=""><code>63370fe</code></a> <code>Test IO::Special .WHICH/.Str do not crash</code></li>
  311. </ul>
  313. <h3>Documentation</h3>
  315. <p>76 IO grant commits:</p>
  317. <ul>
  318. <li><a href=""><code>61cb776</code></a> <code>Document IO::Path.sibling</code></li>
  319. <li><a href=""><code>b9c9117</code></a> <code>Toss IO::Path.child-secure</code></li>
  320. <li><a href=""><code>6ca67e4</code></a> <code>Start sketching out Definitive IO Guide™</code></li>
  321. <li><a href=""><code>81a5806</code></a> <code>Amend IO::Path.resolve: :completely</code></li>
  322. <li><a href=""><code>c5524ef</code></a> <code>Rename IO::Path.concat-with to .add</code></li>
  323. <li><a href=""><code>3145979</code></a> <code>Document IO::Path.child-secure</code></li>
  324. <li><a href=""><code>160c6a2</code></a> <code>Document IO::Handle.lock/.unlock</code></li>
  325. <li><a href=""><code>53f2b99</code></a> <code>Document role IO's new purpose</code></li>
  326. <li><a href=""><code>2aaf12a</code></a> <code>Document IO::Handle.Str</code></li>
  327. <li><a href=""><code>bd4fa68</code></a> <code>Document IO::Handle/IO::Pipe.IO</code></li>
  328. <li><a href=""><code>fd8a5ed</code></a> <code>Document IO::Pipe.path</code></li>
  329. <li><a href=""><code>8d95371</code></a> <code>Expand IO::Handle/IO::Pipe.path docs</code></li>
  330. <li><a href=""><code>60b9227</code></a> <code>Change return value for mkdir</code></li>
  331. <li><a href=""><code>47b0526</code></a> <code>Explicitly spell out caveats of IO::Path.Str</code></li>
  332. <li><a href=""><code>923ea05</code></a> <code>Straighten up mkdir docs</code></li>
  333. <li><a href=""><code>aeeec94</code></a> <code>Straighten up copy, move, rename</code></li>
  334. <li><a href=""><code>fff866f</code></a> <code>Fix docs for symlink/link routines</code></li>
  335. <li><a href=""><code>f83f78c</code></a> <code>Use idiomatic Perl 6 in example</code></li>
  336. <li><a href=""><code>e60da5c</code></a> <code>List utf-* alias examples too since they're common</code></li>
  337. <li><a href=""><code>0f49bb5</code></a> <code>List Rakudo-supported encodings in open()</code></li>
  338. <li><a href=""><code>017acd4</code></a> <code>Improve docs for IO::Path.slurp</code></li>
  339. <li><a href=""><code>56b50fe</code></a> <code>Document IO::Handle.slurp</code></li>
  340. <li><a href=""><code>2aa3c9f</code></a> <code>Document new behaviour of IO::Handle.Supply</code></li>
  341. <li><a href=""><code>a30fae6</code></a> <code>Avoid potential confusion with use of word "object"</code></li>
  342. <li><a href=""><code>372545c</code></a> <code>Straighten up file test docs</code></li>
  343. <li><a href=""><code>1527d32</code></a> <code>Document :completely arg to IO::Path.resolve</code></li>
  344. <li><a href=""><code>4090446</code></a> <code>Improve chmod docs</code></li>
  345. <li><a href=""><code>d436f3c</code></a> <code>Document IO::Spec::* don't do any validation</code></li>
  346. <li><a href=""><code>69b2082</code></a> <code>Document IO::Path.chdir</code></li>
  347. <li><a href=""><code>b9de84f</code></a> <code>Remove DateTime tutorial from IO::Path docs</code></li>
  348. <li><a href=""><code>45e84ad</code></a> <code>Move IO::Path.path to attributes</code></li>
  349. <li><a href=""><code>0ca2295</code></a> <code>Reword/expand IO::Path intro prose</code></li>
  350. <li><a href=""><code>dbdc995</code></a> <code>Document IO::Spec::*.catpath</code></li>
  351. <li><a href=""><code>50e5565</code></a> <code>Document IO::Spec::*.catdir and .catfile</code></li>
  352. <li><a href=""><code>28b6283</code></a> <code>Document IO::Spec::*.canonpath</code></li>
  353. <li><a href=""><code>a1cb80b</code></a> <code>Document IO::Spec::Win32.basename</code></li>
  354. <li><a href=""><code>5c1d3b6</code></a> <code>Document IO::Spec::Unix.basename</code></li>
  355. <li><a href=""><code>9102b51</code></a> <code>Fix up IO::Path.basename</code></li>
  356. <li><a href=""><code>e9b6809</code></a> <code>Document IO::Path::* subclasses</code></li>
  357. <li><a href=""><code>a43ecb9</code></a> <code>Document IO::Path's $.SPEC and $.CWD</code></li>
  358. <li><a href=""><code>7afd9c4</code></a> <code>Remove unrelated related classes</code></li>
  359. <li><a href=""><code>6bd0f98</code></a> <code>Dissuade readers from using IO::Spec*</code></li>
  360. <li><a href=""><code>184342c</code></a> <code>Document IO::Special.what</code></li>
  361. <li><a href=""><code>56256d0</code></a> <code>Minor formatting improvements in IO::Special</code></li>
  362. <li><a href=""><code>1cd7de0</code></a> <code>Fix up type graph</code></li>
  363. <li><a href=""><code>b3a9324</code></a> <code>Expand/fix up IO::Path.accessed</code></li>
  364. <li><a href=""><code>1973010</code></a> <code>Document IO::Path.ACCEPTS</code></li>
  365. <li><a href=""><code>cc62dd2</code></a> <code>Kill IO::Path.abspath</code></li>
  366. <li><a href=""><code>1f75ddc</code></a> <code>Document IO::Spec*.abs2rel</code></li>
  367. <li><a href=""><code>24a6ea9</code></a> <code>Toss all of the TODO methods in IO::Spec*</code></li>
  368. <li><a href=""><code>65cc372</code></a> <code>Document IO::Path.concat-with</code></li>
  369. <li><a href=""><code>b9e692e</code></a> <code>Document new IO::Path.extension</code></li>
  370. <li><a href=""><code>d5abceb</code></a> <code>Write docs for all spurt routines</code></li>
  371. <li><a href=""><code>b8fba97</code></a> <code>Point out my $*CWD = chdir … is an error</code></li>
  372. <li><a href=""><code>b78d4fd</code></a> <code>Include type names in links to methods</code></li>
  373. <li><a href=""><code>bdd18f1</code></a> <code>Fix desc of IO::Path.Str</code></li>
  374. <li><a href=""><code>a53015a</code></a> <code>Clarify value of IO::Path.path</code></li>
  375. <li><a href=""><code>5aa614f</code></a> <code>Improve suggestion for Perl 5's opendir</code></li>
  376. <li><a href=""><code>bf377c7</code></a> <code>Document &amp;indir</code></li>
  377. <li><a href=""><code>e5225be</code></a> <code>Fix URL to &amp;*chdir</code></li>
  378. <li><a href=""><code>e1a299c</code></a> <code>Reword "defined as" for &amp;*chdir</code></li>
  379. <li><a href=""><code>3fdc6dc</code></a> <code>Document &amp;*chdir</code></li>
  380. <li><a href=""><code>1d0e433</code></a> <code>Document &amp;chdir</code></li>
  381. <li><a href=""><code>d050d4b</code></a> <code>Remove IO::Path.chdir prose</code></li>
  382. <li><a href=""><code>839a6b3</code></a> <code>Expand docs for $*HOME and $*TMPDIR</code></li>
  383. <li><a href=""><code>db36655</code></a> <code>Remove tip to use $*SPEC to detect OS</code></li>
  384. <li><a href=""><code>0511e07</code></a> <code>Document IO::Spec::*.tmpdir</code></li>
  385. <li><a href=""><code>cc6539b</code></a> <code>Remove 8 methods from IO::Handle</code></li>
  386. <li><a href=""><code>335a98d</code></a> <code>Remove mention of role IO</code></li>
  387. <li><a href=""><code>cc496eb</code></a> <code>Remove mention of IO.umask</code></li>
  388. <li><a href=""><code>3cf943d</code></a> <code>Expand IO::Path.relative</code></li>
  389. <li><a href=""><code>ccae74a</code></a> <code>Fix incorrect information for IO::Path.absolute</code></li>
  390. <li><a href=""><code>d02ae7d</code></a> <code>Remove and .rwx</code></li>
  391. <li><a href=""><code>69d32da</code></a> <code>Remove IO::Handle.z</code></li>
  392. <li><a href=""><code>110efb4</code></a> <code>No need for .ends-with</code></li>
  393. <li><a href=""><code>fd7a41b</code></a> <code>Improve code example</code></li>
  394. </ul>
  395. ]]>
  396.    </content>
  397. </entry>
  399. <entry>
  400.    <title>Perl 6 Performance and Reliability Engineering: Grant Report</title>
  401.    <link rel="alternate" type="text/html" href="" />
  402.    <id>,2017://18.3866</id>
  404.    <published>2017-04-22T00:00:00Z</published>
  405.    <updated>2017-04-22T04:50:36Z</updated>
  407.    <summary>This is a grant report by Jonathan Worthington on his grant under Perl 6 Core Development Fund. We thank the TPF sponsors to make this grant possible. I have completed the second 200 hours of my Perl 6 performance and reliability engineering grant, funded by the Perl 6 core development fund. This report summarizes the work done during those 200 hours. In accordance with community feedback, the vast majority of effort has been put into reliability rather than performance. Concurrency...</summary>
  408.    <author>
  409.        <name>Makoto Nozaki</name>
  410.        <uri></uri>
  411.    </author>
  413.        <category term="Grants" scheme="" />
  416.    <content type="html" xml:lang="en-us" xml:base="">
  417.        <![CDATA[<p><em>This is a grant report by Jonathan Worthington on his grant under Perl 6 Core Development Fund. We thank the TPF sponsors to make this grant possible.</em></p>
  419. <p>I have completed the second 200 hours of my <a href="">Perl 6 performance and reliability
  420. engineering</a>
  421. grant, funded by the <a href="">Perl 6 core development fund</a>.
  422. This report summarizes the work done during those 200 hours. In accordance with
  423. community feedback, the vast majority of effort has been put into reliability
  424. rather than performance.</p>
  426. <h2>Concurrency robustness</h2>
  428. <p>The main area of focus in this grant period has been making Perl 6's concurrency
  429. support more robust. While work remains to be done, the improvement over the
  430. last several months has been noticeable. It is also an important area for me to
  431. focus on, given the small number of people in the community with the skills,
  432. time, and patience (or, perhaps, stubbornness) to track down and resolve these
  433. problems. Here is a summary of the issues resolved.</p>
  434. ]]>
  435.        <![CDATA[<ul>
  436. <li>Fixed a bug affecting use of <code>callwith</code> in multiple threads</li>
  437. <li>Fixed RT #128809 (closure-related bug involving <code>s///</code> construct, which showed
  438. up in concurrent scenarios)</li>
  439. <li>Fixed RT #129213 (synchronous socket <code>accept</code> could block GC in other threads,
  440. thus blocking program progess)</li>
  441. <li>Determined RT #128694 fixed, added test (<code>zip-latest</code> on two intervals would hang)</li>
  442. <li>Eliminated use of in-place rope flattening, which violated the immutability
  443. of strings and could thus cause various crashes (especially in hash access);
  444. this resolved many failures, amongst them the one reported in RT #129781, and
  445. also made hash lookups using rope strings keys more efficient as a bonus</li>
  446. <li>Fixed warnings due to over-sharing of <code>$/</code> between threads when using grammars
  447. in parallel (mostly fixed RT #128833)</li>
  448. <li>Fixed a <code>Lock.protect</code> bug when we unwound the stack due to control exceptions
  449. (discovered independently of, but also resolved, RT #126774)</li>
  450. <li>Fixed RT #129949 (GC crash resulting from missing rooting of sent value in
  451. concurrent blocking queue)</li>
  452. <li>Fixed RT #129834 (sporadic behavior when concurrently creating <code>Proc::Async</code>
  453. objects and obtaining handles)</li>
  454. <li>Audited and fixed vulnerable cases of the <code>once</code> construct</li>
  455. <li>Fixed RT #129994 (long-lived native call on one thread could block GC in other
  456. threads)</li>
  457. <li>Fixed RT #125782 (uninformative error reporting when a <code>Promise</code> is broken)</li>
  458. <li>Examined RT #127960; concluded it is fixed, but added it as a stress test
  459. since it's a bit distinct from the other test for the same underlying bug</li>
  460. <li>Fixed a bug where method caches could be revealed to other threads before
  461. they were fully deserialized, causing falsely missed lookups</li>
  462. <li>Fixed a data race inside of the NativeCall setup code</li>
  463. <li>Fixed RT #130064 (trying to rethrow an exception that was never thrown before
  464. leaked an internal error; this showed up in Promise.break("foo"))</li>
  465. <li>Fixed scoping/cloning problem with <code>LAST</code>/<code>NEXT</code>/<code>QUIT</code> phasers in <code>supply</code>,
  466. <code>react</code>, <code>whenever</code>, and <code>for</code> constructs</li>
  467. <li>Fixed a bug with <code>QUIT</code> phasers mishandling exceptions thrown synchronously
  468. with the <code>.tap</code></li>
  469. <li>Switched to using <code>Supplier::Preserving</code> on the taps of stdout/stderr in
  470. <code>Proc::Async</code>, to avoid various innocent-looking usage patterns losing output</li>
  471. <li>Fixed RT #128991 (messages could seep out of a <code>supply</code> block even after it was
  472. considered done)</li>
  473. <li>Fixed a GC corruption bug involving <code>Proc::Async</code> that caused occasional crashes</li>
  474. <li>Tracked down and fixed two data races in the <code>supply</code>/<code>whenever</code> implementation
  475. and in <code>Supply.interval</code></li>
  476. <li>Fixed RT #130168 (<code>Supply.interval(...)</code> with very small interval would only
  477. ever emit 1 value)</li>
  478. <li>Fixed interaction of native callbacks, GC blocking, and embedding, which
  479. afflicted <code>Inline::Perl6</code></li>
  480. <li>Fixed use-after-free that could occur as part of inlining fixups when in a
  481. multi-threaded program</li>
  482. <li>Fixed precompilation of the <code>OO::Monitors</code> module</li>
  483. <li>Fixed RT #130266 (premature frees of handles in various async socket error
  484. handling cases)</li>
  485. <li>Fixed SEGVs when GC stressing was applied to S15-nfg/many-threads.t and
  486. S17-supply/syntax.t</li>
  487. <li>Fixed incorrect reporting of some errors on threads, which could show up as
  488. if they were compile-time errors</li>
  489. <li>Fixed thread safety issue in the <code>&gt;&gt;.foo</code> implementation</li>
  490. <li>Fixed a miscompilation of <code>||=</code>, <code>&amp;&amp;=</code>, and <code>//=</code>, making them a good bit more
  491. efficient along the way</li>
  492. <li>Add various bits of missing concurrency control in precompilation management,
  493. thus fixing parallel use of precompilation (this will help towards faster
  494. <code>p6doc</code> builds)</li>
  495. </ul>
  497. <h2>String decoding improvements in asynchronous I/O</h2>
  499. <p>Previously, decoding of bytes to strings for both <code>IO::Socket::Async</code> and
  500. <code>Proc::Async</code> was done at the VM level. This created a number of fragilities
  501. with regard to decoding errors. Due to time constraints, different encodings
  502. besides UTF-8 had not been implemented for these classes either, leaving users
  503. of them to do decoding manually if they needed anything else.</p>
  505. <p>To rectify these issues, I first made the VM-backed decoders directly available
  506. to userland. These will, in the future, be exposed as a Perl 6-level API, and
  507. we'll support user-space encodings. For now, it meant I could move the code that
  508. orchestrates the decoding of strings in async I/O into Perl 6 space, fixing the robustness issues. This
  509. also means that string decoding for different spawned processes and socket
  510. connections can be done in the thread pool, rather than using the
  511. event-processing thread. Along the way, I added support for different encodings.</p>
  513. <p>Finally, there were some issues around the way async sockets and processes
  514. worked with regard to NFG. I resolved these issues and made sure there was
  515. test coverage of the various edge cases.</p>
  517. <h2>Non-blocking await and react support</h2>
  519. <p>I did the initial round of work to provide support for non-blocking <code>await</code> and
  520. <code>react</code>. At present, these constructs will block a real OS thread, even if used
  521. on a thread in the thread pool. The changes, available via. <code>use v6.d.PREVIEW</code>,
  522. mean that thread-pool threads will be returned to the thread pool to do other
  523. work, and the code following the <code>await</code> and <code>react</code> will be scheduled once the
  524. result is available or processing is complete. This is implemented using
  525. continuations (much like <code>gather</code>/<code>take</code>, except in this case the continuation
  526. may be resumed on a different OS thread). The result is that Perl 6 programs
  527. will be able to have hundreds or thousands of outstanding <code>react</code>s and <code>await</code>s,
  528. with just a handful of real OS-threads required to process them.</p>
  530. <p>This is just the initial implementation; further work will be required to make
  531. this feature ready to be the default in Perl 6.d.</p>
  533. <h2>Memory leak fixes and memory use improvements</h2>
  535. <p>The highlight of the memory management improvements was a simplification to
  536. the lifetime management of register working sets in MoarVM. This resulted from
  537. the elimination of a couple of speculative features that were not yet being
  538. utilized by Rakudo, and in one case never would have been anyway. Coupled with
  539. a range of cleanups and some code streamlining, the result was a 10% reduction
  540. in peak memory use for CORE.setting compilation, and 20% off the compilation
  541. runtime. I also:</p>
  543. <ul>
  544. <li>Fixed a bug that caused bogus multi-dispatch cache misses for calls with many
  545. named arguments, leading to the cache growing indefinitely with duplicate
  546. entries</li>
  547. <li>Fixed a regex interpolation memory leak; it boiled down to unclaimed entries
  548. left behind in the serialization context weakhash</li>
  549. <li>Fixed leaks of asynchronous task handles</li>
  550. <li>Fixed a leak in decode stream cleanup</li>
  551. <li>Improved memory allocation measurement in I/O, meaning that full GC collection
  552. decisions are made more accurately in I/O-heavy programs</li>
  553. <li>Fixed a memory leak involving <code>Proc::Async</code></li>
  554. <li>Fixed a memory leak when a synchronous socket failed to connect</li>
  555. <li>Tracked down and resolved the last remaining leaks that showed up in
  556. <code>perl6-valgrind-m -e ''</code>, meaning it is now clean. (Previously, some cleanup
  557. was missed at VM shutdown)</li>
  558. </ul>
  560. <h2>Unicode-related work</h2>
  562. <p>I did a number of Unicode improvements, as well as discussing with and reviewing
  563. Pull Requests from a new contributor who is now doing a bunch of Unicode
  564. work for Perl 6. My own contributions code wise were:</p>
  566. <ul>
  567. <li>Initial support for Unicode 9 (updating the character database, basic NFG
  568. tweaks)</li>
  569. <li>A rewrite of the UTF8-C8 encoding to eliminate various bugs (some falling
  570. under RT #128184), including a buffer overrun and not properly round-tripping
  571. valid but non-NFC input</li>
  572. </ul>
  574. <h2>Other assorted bugs</h2>
  576. <p>I also took care of a range of other bugs, which don't fit into any of the
  577. previously mentioned areas of work.</p>
  579. <ul>
  580. <li>Fixed RT #128703 (1 R, 2 R, 3 lost values)</li>
  581. <li>Fixed RT #129088 (lack of backtaces for <code>sprintf</code> and friends)</li>
  582. <li>Fixed RT #129249 (mis-compilation of <code>/$&lt;cat&gt;=@(...)/</code>)</li>
  583. <li>Fixed RT #129306 (erorr reporting bug involving sub-signatures)</li>
  584. <li>Partially fixed and tested RT #129278 (native attributive parameter binding broken)
  585. and noted on the RT the less common cases that remain to be fixed</li>
  586. <li>Fixed RT #129430 (sigilless parameters were declared too late to use in where
  587. clauses)</li>
  588. <li>Fixed RT #129827 (sub { 42.return }() ended up being code-gen'd without a return
  589. handler)</li>
  590. <li>Fixed RT #129772 (poor error reporting when you tried to invoke a native
  591. parameter; it blew up code-gen and gave no location info)</li>
  592. <li>Tracked down and fixed a pre-comp management bug on Windows due to a file not being
  593. closed and then trying to rename over it</li>
  594. <li>Fixed RT #129968 (error-reporting crash in the case of redeclaration errors in
  595. nested packages)</li>
  596. <li>Fixed a bug with augmenting nested classes</li>
  597. <li>Fixed RT #129921 (internal warning when producing exception for <code>my $!a</code>)</li>
  598. <li>Hunted down a bug in the JIT-compilation of the <code>nqp::exception()</code> op and fixed it</li>
  599. <li>Fixed RT #130107 (accidentally treated <code>nread == 0</code> as an error in a couple of
  600. places in MoarVM)</li>
  601. <li>Fixed RT #130081 (did not backtrack into a regex <code>TOP</code> in a grammar to try and
  602. make it match until the end of the string)</li>
  603. <li>Fixed RT #130294 (SEGV that occasionally occurred during some cases of deep recursion)</li>
  604. <li>Fixed RT #128516 (SEGV when composing meta-object held in an attribute)</li>
  605. <li>Fixed RT #130465 (ignoremark not applied with backslashed literals)</li>
  606. <li>Fixed RT #130208 (putting multi-line Pod documentation on a role would pun it)</li>
  607. <li>Fixed RT #130615 (code-gen of <code>$a++</code> in sink context for native <code>$a</code> was a lot
  608. slower than in non-sink context)</li>
  609. <li>Fixed RT #130637 (two grammar constructs produced malformed NFAs, which gave
  610. wrong results or could even SEGV in MoarVM; MoarVM was made to validate NFAs
  611. more strongly, which shook out the second issue besides the reported one)</li>
  612. <li>Investigated RT #129291 (SEGV involving processes with output of one fed into
  613. input of the other); applied likely fix</li>
  614. <li>Investigated and fixed an issue with <code>$/</code> setting, arising from changes to
  615. the implementation of <code>match</code></li>
  616. <li>Fixed a bug that occasionally caused spectest crashes; was an interaction
  617. between dynamic lexical caching, inlining, deoptimization, and garbage
  618. collection</li>
  619. <li>Fixed a rare crash related to assignment when the type constraint was a
  620. refinement type</li>
  621. <li>Fixed MoarVM #120 and #426, in which a failed debug annotation lookup led to
  622. boxing a NULL string</li>
  623. <li>Fixed a couple of places where dynamic optimization could accidentally
  624. trigger garbage collection; the optimizer assumes this can never happen</li>
  625. <li>Fixed RT #123989 and RT #125135 (callsame et al could sometimes have the
  626. dispatcher stolen by the wrong target invokee)</li>
  627. </ul>
  629. <h2>Other tasks</h2>
  631. <p>On top of this, some time was spent reviewing pull requests to Rakudo, NQP,
  632. and MoarVM, providing feedback, and merging them when appropriate. I also
  633. commented on a range of RT tickets besides those I fixed myself. Various other
  634. small cleanups and additions resulted from this work, ranging from typo fixes
  635. in comments up to improvements to GC debugging macros added while finding bugs.</p>
  636. ]]>
  637.    </content>
  638. </entry>
  640. <entry>
  641.    <title>Final Grant Report : Migrating - April 2017</title>
  642.    <link rel="alternate" type="text/html" href="" />
  643.    <id>,2017://18.3865</id>
  645.    <published>2017-04-21T22:41:56Z</published>
  646.    <updated>2017-04-21T22:47:56Z</updated>
  648.    <summary>Work on the grant, started in November 2015, has stalled. With no progress reports from the grantee since November 2016, and after a number of attempts on all sides to jumpstart the work, the Grants Committee has voted to cancel the grant, as provided in the rules of operation. Many on the Committee and in the community would like to see a successful update of With that in mind, the Grants Committee encourages interested parties to consider applying...</summary>
  649.    <author>
  650.        <name>Mark A Jensen</name>
  652.    </author>
  654.        <category term="Grants" scheme="" />
  656.    <category term="grants" label="grants" scheme="" />
  658.    <content type="html" xml:lang="en-us" xml:base="">
  659.        <![CDATA[<p>Work on
  660. <a href="">the grant</a>,
  661. started in November 2015, has stalled. With no progress reports from the grantee since
  662. <a href="">November 2016</a>,
  663. and after a number of attempts on all sides to jumpstart the work,
  664. the Grants Committee has voted to cancel the grant, as provided in the
  665. <a href="">rules of operation</a>.</p>
  667. <p>Many on the Committee and in the community would like to see a
  668. successful update of With that in mind, the Grants
  669. Committee encourages interested parties to consider applying for
  670. improvement grants in upcoming rounds. The next round of decisions will happen in May.
  671. See <a href="">How to write a proposal</a>
  672. for tips, and feel free to reach out to the committee via
  673. tpf-grants-secretary at</p>
  675. <p>MAJ</p>
  676. ]]>
  678.    </content>
  679. </entry>
  681. <entry>
  682.    <title>Grant Extension Request: Maintaining the Perl 5</title>
  683.    <link rel="alternate" type="text/html" href="" />
  684.    <id>,2017://18.3864</id>
  686.    <published>2017-04-20T23:00:00Z</published>
  687.    <updated>2017-04-21T02:54:38Z</updated>
  689.    <summary>Tony Cook has requested an extension of $20,000 for his Maintaining the Perl 5 grant. This will allow him to dedicate another 400 hours to this work. During this grant he sent regular reports to the p5p mailing list as well as providing monthly summary reports that have been published on this site, the most recent of which are linked below: January 2017 December 2016 November 2016 October 2016 Before we make a decision on this extension, we would like...</summary>
  690.    <author>
  691.        <name>Makoto Nozaki</name>
  692.        <uri></uri>
  693.    </author>
  695.        <category term="Grants" scheme="" />
  698.    <content type="html" xml:lang="en-us" xml:base="">
  699.        <![CDATA[<p><strong>Tony Cook</strong> has requested an extension of $20,000 for his <strong>Maintaining the Perl 5</strong> grant. This will allow him to dedicate another 400 hours to this work. During this grant he sent regular reports to the p5p mailing list as well as providing monthly summary reports that have been published on this site, the most recent of which are linked below:</p>
  701. <ul>
  702. <li><a href="">January 2017</a></li>
  703. <li><a href="">December 2016</a></li>
  704. <li><a href="">November 2016</a></li>
  705. <li><a href="">October 2016</a></li>
  706. </ul>
  708. <p>Before we make a decision on this extension, we would like to have a period of community consultation. Please leave feedback in the comments field below or if you prefer, send email with your comments to makoto at We request that all the feedback should be sent by April 25th.</p>
  710. <p>If successful this extension will be funded from the <a href="">Perl 5 Core Maintenance Fund</a>.</p>
  712. <p>Note: The request was received in February and TPF's internal process took time to post this. Apologies.</p>
  713. ]]>
  715.    </content>
  716. </entry>
  718. <entry>
  719.    <title>Maintaining the Perl 5 Core: March 2017 report</title>
  720.    <link rel="alternate" type="text/html" href="" />
  721.    <id>,2017://18.3863</id>
  723.    <published>2017-04-06T23:00:00Z</published>
  724.    <updated>2017-04-06T03:39:54Z</updated>
  726.    <summary>This is a monthly report by Dave Mitchell on his grant under Perl 5 Core Maintenance Fund. We thank the TPF sponsors to make this grant possible. The main things I did last month were: * working on fuzzer-related tickets in the security queue; * working on tickets in the 5.26 blocker queue; * investigating the possibility of storing short strings directly in the head of an SV, eliminating the need for an SV body or malloced string buffer. The...</summary>
  727.    <author>
  728.        <name>Makoto Nozaki</name>
  729.        <uri></uri>
  730.    </author>
  732.        <category term="Grants" scheme="" />
  735.    <content type="html" xml:lang="en-us" xml:base="">
  736.        <![CDATA[<p>This is a monthly report by Dave Mitchell on his grant under <a href="">Perl 5 Core Maintenance Fund</a>. We thank the TPF sponsors to make this grant possible.</p>
  738. <pre>
  739. The main things I did last month were:
  741. * working on fuzzer-related tickets in the security queue;
  743. * working on tickets in the 5.26 blocker queue;
  745. * investigating the possibility of storing short strings directly in the
  746. head of an SV, eliminating the need for an SV body or malloced string
  747. buffer. The short conclusion was that it probably wont work robustly.
  749. * reducing the size of my p5p mailbox, which had grown to 14,000 emails
  750. over the years. It's now down to a few hundred. This was achieved firstly
  751. by simply deleting any threads more than 3 years old, then
  752. reading/processing/deleting any threads/tickets newer than that.
  754. SUMMARY:
  755.      0:30 "do ''" warnings
  756.      2:53 RT ##131083 Bleadperl breaks App-PDF-Link-0.18
  757.      0:15 RT #130841 AddressSanitizer: heap-buffer-overflow
  758.      2:38 RT #130841 heap-buffer-overflow in Perl_newSVpvn_flags
  759.      1:18 RT #130861 AddressSanitizer: heap-use-after-free in Perl_pp_rv2sv
  760.     11:52 RT #130915 AddressSanitizer: heap-buffer-overflow in Perl_do_vecget
  761.      2:39 RT #130916 heap-buffer-overflow in S_ckwarn_common
  762.      0:33 RT #130918 heap-buffer-overflow in Perl_pad_free
  763.      2:42 RT #130921 BBC re-engine-GNU-0.021
  764.      1:18 RT #130934 heap-use-after-free in Perl_yyparse
  765.      0:44 RT #130981 Confusing B::Deparse output with unless/elsif
  766.      0:44 RT #131033 t/op/range.t fails
  767.      1:53 RT #32714 Objects destroyed in the wrong order during global destruction
  768.      1:30 fix build warnings and smoke failures
  769.     17:31 investigate short-string PVs
  770.     31:12 process p5p mailbox
  771.      1:04 revert @INC changes
  772.      4:57 review blocker tickets
  773.      6:01 review security tickets
  774.    ------
  775.     92:14 TOTAL (HH::MM)
  777. 180.7 weeks
  778. 2549.0 total hours
  779.  14.1 average hours per week
  781. There are 251 hours left on the grant
  782. </pre>
  783. ]]>
  785.    </content>
  786. </entry>
  788. <entry>
  789.    <title>Grant Proposal: RPerl User Documentation Part 3</title>
  790.    <link rel="alternate" type="text/html" href="" />
  791.    <id>,2017://18.3862</id>
  793.    <published>2017-04-04T01:19:40Z</published>
  794.    <updated>2017-04-08T16:26:53Z</updated>
  796.    <summary></summary>
  797.    <author>
  798.        <name>Coke</name>
  800.    </author>
  803.    <content type="html" xml:lang="en-us" xml:base="">
  805.        <![CDATA[<p>The Grants Committee has received the following grant proposal for the March round. Before the Committee members vote, we would like to solicit feedback from the Perl community on the proposal.</p>
  807. <p>Review the proposal below and please comment here by April 12th, 2017. The Committee members will start the voting process following that and the conclusion will be announced approximately in one week.</p>
  809. <h1>RPerl User Documentation, Part 3</h1>
  811. <ul>
  812. <li><p>Name:</p>
  814. <p>Will Braswell</p></li>
  815. <li><p>Amount Requested:</p>
  817. <p>USD 2,400</p></li>
  818. </ul>
  820. <h2>Synopsis</h2>
  822. <p>RPerl v2.4 has been released, and now includes auto-parallelization along
  823. with a raft of other new features, as expected.
  824. Approximately 150 pages of new documentation have been published as part
  825. of the RPerl User Docs grant part 2, comprising chapters 2, 3, and 4.
  826. Yet, several more chapters remain to be written before the book is done.
  827. This grant proposal is to continue work on the Learning RPerl textbook.</p>
  829. <h2>Benefits to the Perl Community</h2>
  831. <p>The number one request and obvious need at this time is still quality RPerl
  832. user documentation, to help new RPerl users learn how to write fast software.
  833. Learning RPerl is the canonical guide to RPerl and must be completed to enjoy
  834. the maximum benefit to the Perl programming community.</p>
  836. <h2>Deliverables</h2>
  838. <p>Deliverables for this grant proposal are:</p>
  840. <p>1.  Write Learning RPerl Chapter 5</p>
  842. <p>2.  Write Learning RPerl Chapter 6</p>
  844. <h2>Project Details</h2>
  846. <p>I've already written all of the code for the solutions to exercises from
  847. chapters 1 through 6 of Learning Perl:</p>
  849. <p><a href="">Learning RPerl Github</a></p>
  851. <p>I've already got a partial copy of Learning RPerl on the website:</p>
  853. <p><a href="">Learning RPerl Website</a></p>
  855. <h2>Inch-stones</h2>
  857. <h3>Chapter 5 Data I/O</h3>
  859. <p>1a.  STDIN</p>
  861. <p>1b.  STDOUT &amp; STDERR</p>
  863. <p>1c.  <code>printf</code> Operator</p>
  865. <p>1d.  <code>die</code> &amp; <code>croak</code> Operators</p>
  867. <p>1e.  Filehandles &amp; <code>filehandleref</code> Data Type</p>
  869. <h3>Chapter 6 Hash Values &amp; Variables</h3>
  871. <p>2a.  Hashes vs Arrays</p>
  873. <p>2b.  1-D Hash Data Types</p>
  875. <p>2c.  How To Access Hash Elements</p>
  877. <p>2d.  <code>keys</code> Operator</p>
  879. <p>2e.  2-D Array Data Types &amp; Nested Arrays</p>
  881. <p>2f.  Converting From Array To String</p>
  883. <p>2g.  Hashes &amp; The <code>foreach</code> Loop</p>
  885. <h2>Project Schedule</h2>
  887. <p>I will begin work immediately upon granting.</p>
  889. <p>I expect work to take approximately 60 to 90 days.</p>
  891. <h2>Completeness Criteria</h2>
  893. <p>I will release a new version of RPerl to CPAN with the new documentation.</p>
  895. <p>I will release a new version of the RPerl website with the new documentation.</p>
  897. <h2>Bio</h2>
  899. <p>I am the creator and lead developer of RPerl.</p>
  901. <p>I've been working on RPerl for over 4 years.</p>
  903. <p>I've successfully completed work on 2 TPF grants.</p>
  905. <p>I would like to start work on the 3rd grant now.</p>
  906. ]]>
  907.    </content>
  908. </entry>
  910. <entry>
  911.    <title>Grant Proposal: Improving the Robustness of Unicode Support in Rakudo on MoarVM</title>
  912.    <link rel="alternate" type="text/html" href="" />
  913.    <id>,2017://18.3860</id>
  915.    <published>2017-04-04T01:00:30Z</published>
  916.    <updated>2017-04-04T01:33:35Z</updated>
  918.    <summary></summary>
  919.    <author>
  920.        <name>Coke</name>
  922.    </author>
  925.    <content type="html" xml:lang="en-us" xml:base="">
  927.        <![CDATA[<p>The Grants Committee has received the following grant proposal for the March round.
  928. Before the Committee members vote, we would like to solicit feedback from the Perl community on the proposal.</p>
  930. <p>Review the proposal below and please comment here by April 12th, 2017.
  931. The Committee members will start the voting process following that
  932. and the conclusion will be announced approximately in one week.</p>
  934. <h1>Improving the Robustness of Unicode Support in Rakudo on MoarVM</h1>
  936. <ul>
  937. <li><p>Name:</p>
  939. <p>Samantha McVey (samcv)</p></li>
  940. <li><p>Amount Requested:</p>
  942. <p>7,500 USD</p></li>
  943. </ul>
  945. <h2>Synopsis</h2>
  947. <p>Implement Unicode Collation Algorithm, improve speed and spec conformance of the
  948. text normalizer. Improve test coverage for Unicode specs and document our
  949. compliance or lack of compliance with the Unicode spec.</p>
  951. <h2>Benefits to the Perl Community</h2>
  953. <p>As Perl 6 starts to take off, it is increasingly important to provide robust
  954. Unicode support. Perl 6 already provides some of the best Unicode support on
  955. many levels compared to other programming languages. The goal of this project
  956. is to make Perl 6's Unicode support production ready.</p>
  958. <h2>Deliverables and Inch Stones</h2>
  960. <ul>
  961. <li>General
  962. <ul>
  963. <li>Any deficits of our Unicode coverage will be documented in the course of work on this
  964. project. This is very important
  965. due to the vastness of the Unicode standard. Deficits will have tests
  966. written, unless such a thing would not be possible to test or input is needed
  967. from the rest of the Perl 6 team. In any of these cases, they will be
  968. documented in my reports for future and current developers of Perl 6 to reference.</li>
  969. <li>Tests will be written to cover all of the relevant Unicode 9.0 test files, as
  970. well as making current ones more robust when checking the breaking of graphemes.</li>
  971. </ul></li>
  972. <li>Unicode Names
  973. <ul>
  974. <li>Hangul Syllables and other Unicode names shall be programmatically determined
  975. when generating the Unicode database.</li>
  976. </ul></li>
  977. <li>Unicode Collation Algorithm
  978. <ul>
  979. <li>Fully implement the Unicode Collation Algorithm at least for language
  980. nonspecific sorting.</li>
  981. <li>Assess needs in supporting language and country specific collation, and write
  982. a report of these needs.</li>
  983. </ul></li>
  984. <li>Text Normalization
  985. <ul>
  986. <li>Improve the performance of the text normalizer and also allow the normalizer
  987. to save state across multiple characters to properly support Grapheme Breaking
  988. for all of Unicode 9.0 and beyond.</li>
  989. </ul></li>
  990. <li>Unicode Database Generation
  991. <ul>
  992. <li>The script used to generate the Unicode database shall be made deterministic,
  993. and produce the same output file on every run.
  994. At the current time about half of the file changes even if no changes are made to the
  995. script. This is an issue that will be solved.</li>
  996. <li>In addition to the above, the original script assumed that property values for
  997. Unicode characters were unique. This causes issues when there is a conflict between
  998. these. The rewritten script shall resolve this problem.</li>
  999. <li>Rewrite the Perl 5 script used to generate the Unicode database in Perl 6.
  1000. This is also part of the previous item, since a rewrite is needed, it should be
  1001. done in Perl 6 to help make it more maintainable.</li>
  1002. <li>Implement all relevant remaining Unicode properties from Unicode 9.0. This
  1003. includes the properties needed to support the deliverables listed above.</li>
  1004. <li>Try to reduce the memory footprint of the Unicode database. Currently
  1005. the unicode.o binary file created is 4.1MB. I hope to cut that in half.</li>
  1006. </ul></li>
  1007. </ul>
  1009. <h2>Project Details</h2>
  1011. <p>I have already started working on the rewrite of the Unicode database generation
  1012. which is in <a href="">this public repository</a>.</p>
  1014. <p>Some background into this. The original Unicode database generation script we
  1015. currently use was added in 2012 and much of the script has not changed much since.
  1016. Although this current script is somewhat adequate, as I have been working on
  1017. Unicode support these past months it became clear that the script was not easily
  1018. maintainable and had some issues which would have required an extensive
  1019. rewrite of much of the script. It became clear that a full rewrite was prudent.</p>
  1021. <p>I have done lots of fielding and preliminary work as well as the knowledge I have
  1022. gained by working with the current script we use and the MoarVM internals. </p>
  1024. <h3>Plan</h3>
  1026. <h4>Month 1: Get database generation finalized</h4>
  1028. <ul>
  1029. <li>Implement testing for resolving codepoints to bitfield rows, to ensure
  1030. all codepoints resolve to the correct rows</li>
  1031. <li>Integrate testing of database values into the current Unicode database rewrite
  1032. (this will not be in roast, but will be done to ensure correctness during
  1033. development)</li>
  1034. <li>Work with timotimo on C implementation on indexed decoding of base40 compressed
  1035. Unicode Names (some work already done in <a href="">UCD repo</a></li>
  1036. <li>Implement programmatic generation of codepoint names for Hangul Syllables</li>
  1037. <li>Implement remaining properties and data in the rewrite and achieve pairity with
  1038. our current script</li>
  1039. </ul>
  1041. <h4>Month 2: Finish the Unicode Collation Algorithm and integrate with MoarVM, add test coverage to roast</h4>
  1043. <ul>
  1044. <li>Assess needs for language/country specific sorting for Unicode Collation Algorithm (UCA)</li>
  1045. <li>Implement weights of codepoint sequences (only single codepoint is implemented currently)</li>
  1046. <li>Implement decomposition of codepoints if no Collation weights are found</li>
  1047. <li>Integrate the rewrite with MoarVM codebase, as well as rewrite all sections
  1048. of MoarVM</li>
  1049. <li>Make needed changes in MoarVM so Property Values are not assumed unique.</li>
  1050. <li>Integrate with MoarVM codebase</li>
  1051. <li>Merge into MoarVM repository</li>
  1052. </ul>
  1054. <h2>Project Schedule</h2>
  1056. <p>I can begin work as soon as the grant is approved.</p>
  1058. <h2>Completeness Criteria</h2>
  1060. <p>Tests will be commited to roast, and the rewritten database and Unicode Collation
  1061. Algorithm implementation will be merged into MoarVM.</p>
  1063. <h2>Bio</h2>
  1065. <p>Although I am a fairly recent addition to the Perl 6 core developers, in a short
  1066. few months I have been very busy. I have two Perl 6 modules, IRC::TextColor
  1067. and URL::Find and I am the lead developer of the Perl 6 syntax highlighter
  1068. for Atom/Github as well as for I converted the site from
  1069. using the old Pygments highlighter to the new highlighter.</p>
  1071. <p>My contributions to Perl 6 have been focused on Unicode support in Perl 6,
  1072. making changes throughout Rakudo, NQP and MoarVM to achieve this. All of the
  1073. work I have already done on improving Unicode support in Perl 6 shows I am
  1074. capable of completing this project and am the best person for this grant.
  1075. In addition, I have already started work on rewriting the Unicode Database
  1076. generation and shrinking the size of the data needed to be loaded on startup.</p>
  1078. <h3>Incomplete list of Unicode work I have done in the last few months</h3>
  1080. <h4>Tests:</h4>
  1082. <ul>
  1083. <li>Fixed several errata in roast related to our Unicode support, which had often
  1084. been present for a long time.</li>
  1085. <li>Added a test based on GraphemeBreakTest.txt from Unicode and many others
  1086. to Unicode 9.0</li>
  1087. <li>Updated other tests for Unicode 9.0 and reworked others for compliance.</li>
  1088. </ul>
  1090. <h4>MoarVM:</h4>
  1092. <ul>
  1093. <li>Implemented a simplistic implementation of the Unicode Collation Algorithm.</li>
  1094. <li>Added <code>coll</code> operator, <code>.collate</code> method and the <code>$*COLLATION</code> variable
  1095. to Rakudo. For more information see the
  1096. <a href="">documentation</a> I have added on it.</li>
  1097. <li>Added support for named codepoint sequences, which includes the Named Sequences,
  1098. Emoji Sequences and Emoji ZWJ Sequences. <code>"\c[woman gesturing OK]"</code></li>
  1099. <li>Implemented
  1100. <a href="">Unicode Name Aliases</a> in
  1101. getting codepoints by name and <a href="">documentation</a></li>
  1102. <li>Implemented the 'Extend' Grapheme_Cluster_Break property which was new in Unicode 9.0.
  1103. We previously had no support for this property. This caused errors in grapheme
  1104. breakup and incorrect character count and segmentation.</li>
  1105. <li>Implemented many other Grapheme_Cluster_Break fixes and added support for
  1106. most Emoji sequences. This fixes most Emoji made up of multiple codepoints,
  1107. fixing character counts and text segmentation for these extended grapheme clusters.</li>
  1108. <li>Improved the speed of radix 50% for non-ASCII decimal digits
  1109. (converts strings to their numeric representation/values)</li>
  1110. <li>Improved the speed of text normalization, making slurping a Unicode heavy text
  1111. file 14% faster</li>
  1112. <li>Improved the speed m:i/ / regex matching between 1.8x and 3.3x (depending on not finding a match / finding a match at the beginning).</li>
  1113. <li>Added a multitude of properties to our Unicode database.</li>
  1114. </ul>
  1116. <h4>Rakudo:</h4>
  1118. <ul>
  1119. <li>Added support for a large number Unicode properties, handling Bool/Str/Int
  1120. return types for <code>uniprop</code></li>
  1121. <li>Implemented <code>uniprops</code> method in Rakudo</li>
  1122. </ul>
  1123. ]]>
  1124.    </content>
  1125. </entry>
  1127. <entry>
  1128.    <title>Perl 6 IO Grant: March 2017 Report</title>
  1129.    <link rel="alternate" type="text/html" href="" />
  1130.    <id>,2017://18.3859</id>
  1132.    <published>2017-04-04T00:51:03Z</published>
  1133.    <updated>2017-04-04T00:54:58Z</updated>
  1135.    <summary>Zoffix Znet provided this report on March 28, 2017 Perl 6 IO TPF Grant: Monthly Report (March, 2017) This document is the March, 2017 progress report for TPF Standardization, Test Coverage, and Documentation of Perl 6 I/O Routines grant Timing My delivery of the Action Plan was one week later than I originally expected to deliver it. The delay let me assess some of the big-picture consistency issues, which led to proposal to remove 15 methods from IO::Handle and to...</summary>
  1136.    <author>
  1137.        <name>Coke</name>
  1139.    </author>
  1141.        <category term="Grants" scheme="" />
  1144.    <content type="html" xml:lang="en-us" xml:base="">
  1145.        <![CDATA[<p><em>Zoffix Znet provided this report on March 28, 2017</em></p>
  1147. <h1>Perl 6 IO TPF Grant: Monthly Report (March, 2017)</h1>
  1149. <p>This document is the March, 2017 progress report for <a href="">TPF Standardization,
  1150. Test Coverage, and Documentation of Perl 6 I/O Routines
  1151. grant</a></p>
  1153. <h2>Timing</h2>
  1155. <p>My delivery of the Action Plan was one week later than I originally
  1156. expected to deliver it. The delay let me assess some of the big-picture
  1157. consistency issues, which led to proposal to remove 15 methods from IO::Handle
  1158. and to iron out naming and argument format for several other routines.</p>
  1160. <p>I still hope to complete all the code modifications prior to end of weekend of
  1161. April 15, so all of these can be included in the next Rakudo Star release. And
  1162. a week after, I plan to complete the grant.</p>
  1164. <p>Note: to minimize user impact, some of the changes may be included only in
  1165. 6.d language, which will be available in 2017.04 release only if the user uses
  1166. <code>use v6.d.PREVIEW</code> pragma.</p>
  1168. <h2>IO Action Plan</h2>
  1170. <p>I finished the IO Action Plan, <a href="">placed it into <code>/doc</code> of rakudo's repository</a>, and made it available to other core devs for
  1171. review for a week (period ends on April 1st). The Action Plan is 16 pages long and
  1172. contains 26 sections detailing proposed changes.</p>
  1174. <p>Overall, I proposed many more smaller changes than I originally expected and
  1175. fewer larger, breaking changes than I originally expected. This has to do
  1176. with a much better understanding of how rakudo's IO routines are "meant to" be
  1177. used, so I think the improvement of the documentation under this grant will
  1178. be much greater than I originally anticipated.</p>
  1180. <p>A lot of this has to do with lack of explanatory documentation for how to
  1181. manipulate and traverse paths. This had the effect that users were using the
  1182. <code>$*SPEC</code> object (157 instances of its use in the ecosystem!) and its routines
  1183. for that goal, which is rather awkward.
  1184. This concept is prevalent enough that I even wrote <a href=""><code>SPEC::Func</code></a> module in the
  1185. past, due to user demand, and certain books whose draft copies I read used
  1186. the <code>$*SPEC</code> as well.</p>
  1188. <p>In reality, <code>$*SPEC</code> is an internal-ish thing and unless you're writing your
  1189. own IO abstractions, you never need to use it directly. The changes and
  1190. additions to the <code>IO::Path</code> methods done under this grant will make traversing
  1191. paths even more pleasant, and the new tutorial documentation I plan to write
  1192. under this grant will fully describe the Right Way™ to do it all.</p>
  1194. <p>In fact, removal of <code>$*SPEC</code> in future language versions is currently under
  1195. consideration...</p>
  1197. <h2>Removal of <code>$*SPEC</code></h2>
  1199. <p>lizmat++ pointed out that we can gain significant performance improvements by
  1200. removing <code>$*SPEC</code> infrastructure and moving it into module-space. For example,
  1201. a benchmark of slurping a 10-line file shows that removal of all the
  1202. path processing code makes benched program run more than 14x faster. When
  1203. benching <code>IO::Path</code> creation, dynamic var lookup alone takes up 14.73% of
  1204. the execution time.</p>
  1206. <p>The initial plan was to try and make IO routines handle all OSes in a unified
  1207. way (e.g. using <code>/</code> on Windows), however it was found this would create
  1208. several ambiguities and would be buggy, even if fast.</p>
  1210. <p>However, I think there are still a lot of improvements that can be gained
  1211. by making <code>$*SPEC</code> infrastructure internal. So we'd still have the
  1212. <code>IO::Spec</code>-type modules but they'll have a private API we can optimize freely,
  1213. and we'll get rid of the dynamic lookups, consolidate what code we can into
  1214. <code>IO::Path</code>, while keeping the functionality that differs between OSes in the
  1215. <code>::Spec</code> modules.</p>
  1217. <p>Since this all sounds like guestimation and there's a significant-ish use of
  1218. <code>$*SPEC</code> in the ecosystem, the plan now is to implement it all in a module
  1219. first and see whether it works well and offers any significant performance
  1220. improvements. If it does, I believe it should be possible to swap <code>IO::Path</code>
  1221. to use the fast version in <code>6.d</code> language, while still leaving <code>$*SPEC</code> dynvar
  1222. and its modules in core, as deprecated, for removal in <code>6.e</code>.</p>
  1224. <p>This won't be done under this grant, and while trying not to over-promise, I
  1225. hope to release this module some time in May-June. So keep an eye out for it; I
  1226. already picked out a name: <a href=""><code>FastIO</code></a></p>
  1228. <h2>newio Branch</h2>
  1230. <p>As per original goals of the grant, I reviewed the code in Rakudo's 2014–2015
  1231. <code>newio</code> branch, to look for any salvagable ideas. I did not have any masterplan
  1232. design documents to go with it and I tried a few commits but did not find one
  1233. that didn't have merge conflicts and compiled (it kept complaining about
  1234. ModuleLoader), so my understanding of it comes solely from reading the source
  1235. code, and may be off from what the original author intended it to be.</p>
  1237. <p>The major difference between <code>newio</code> and Rakudo's current IO structure is
  1238. type hierarchy and removal of <code>$*SPEC</code>. <code>newio</code> provides <code>IO::Pathy</code> and
  1239. <code>PIO</code> roles which are done by <code>IO::File</code>, <code>IO::Dir</code>, <code>IO::Local</code>, <code>IO::Dup</code>,
  1240. <code>IO::Pipe</code>, and <code>IO::Huh</code> classes that represent various IO objects. The current
  1241. Rakudo's system has fewer abstractions: <code>IO::Path</code> represents a path to an IO
  1242. object and <code>IO::Handle</code> provides read/write access to it, with <code>IO::Pipe</code>
  1243. handling pipes, and no special objects for directories (their contents are
  1244. obtained via <code>IO::Path.dir</code> method and their attributes are modified via
  1245. <code>IO::Path</code> methods).</p>
  1247. <p>Since 6.d language is <em>additive</em> to 6.c language, completely revamping the
  1248. type hierarchy may be challenging and messy. I'm also not entirely sold on what
  1249. appears to be one of the core design ideas in <code>newio</code>: most of the
  1250. abstractions are of IO objects as <em>they were at the object instantiation time</em>. An <code>IO::Pathy</code> object represents an IO item <em>that exists</em>, despite there being
  1251. no guarantees that it actually does. Thus, <code>IO::File</code>'s <code>.f</code> and <code>.e</code> methods
  1252. always return <code>True</code>, while its <code>.d</code> method always returns <code>False</code>. This
  1253. undoubtedly gives a performance enhancement, however, if
  1254. <code>$ rm foo</code> were executed after <code>IO::File</code> object's creation, the <code>.e</code> method
  1255. would no longer return correct data and if then <code>$ mkdir foo</code> were
  1256. executed, both <code>.f</code> and <code>.d</code> methods would be returning incorrect data.</p>
  1258. <p>Until recently, Rakudo cached the result of <code>.e</code> call and <a href="">that produced
  1259. unexpected by user behaviour</a>. I think the
  1260. issue will be greatly exacerbated if this sort of caching is extended to entire
  1261. objects and many of their methods.</p>
  1263. <p>However, I do think the removal of <code>$*SPEC</code> is a good idea. And as described in
  1264. previous section I will try to make a <code>FastIO</code> module, using ideas from <code>newio</code>
  1265. branch, for possible inclusion in future language versions.</p>
  1267. <h2>Experimental MoarVM Coverage Reporter</h2>
  1269. <p>As was mentioned in my grant proposal, the coverage reporter was busted by
  1270. the upgrade of information returned by <code>.file</code> and <code>.line</code> methods on core
  1271. routines.
  1272. MasterDuke++ made several commits fixing numerous issues to the coverage
  1273. parser and last night I identified the final piece of the breakage. The
  1274. annotations and hit reports all use the new <code>SETTING::src/core/blah</code> file
  1275. format. The setting file has <code>SETTING::src/core/blah</code> markers inside of it.
  1276. The parser however, still thinks it's being fed the old <code>gen/moar/CORE.setting</code>
  1277. filenames, so once I teach it to calculate proper offsets
  1278. into the setting file, we'll have coverage reports on <a href=""></a> back up and running and I'll be able to use them
  1279. to judge IO routine test coverage required for this grant.</p>
  1281. <h2>Performance Improvements</h2>
  1283. <p>Although not planned by the original grant, I was able to make the following
  1284. performance enhancements to IO routines. So hey! Bonus deliverables \o/:</p>
  1286. <ul>
  1287. <li><a href="">rakudo/fa9aa47</a> Make <code>R::I::SET_LINE_ENDING_ON_HANDLE</code> <strong>4.1x</strong> Faster</li>
  1288. <li><a href="">rakudo/0111f10</a> Make IO::Spec::Unix.catdir <strong>3.9x</strong> Faster</li>
  1289. <li><a href="">rakudo/4fdebc9</a> Make IO::Spec::Unix.split <strong>36x</strong> Faster
  1290. <ul>
  1291. <li>Affects IO::Path's .parent, .parts, .volume, .dirname, and .basename</li>
  1292. <li>Measurement of first call to .basename shows it's now <strong>6x-10x</strong> faster</li>
  1293. </ul></li>
  1294. <li><a href="">rakudo/dcf1bb2</a> Make IO::Spec::Unix.rel2abs <strong>35%</strong> faster</li>
  1295. <li><a href="">rakudo/55abc6d</a> Improve IO::Path.child perf on <code>*nix</code>:
  1296. <ul>
  1297. <li>make IO::Path.child <strong>2.1x</strong> faster on <code>*nix</code></li>
  1298. <li>make IO::Spec::Unix.join <strong>8.5x</strong> faster</li>
  1299. <li>make IO::Spec::Unix.catpath <strong>9x</strong> faster</li>
  1300. </ul></li>
  1301. <li><a href="">rakudo/4032953</a> Make <strong>75%</strong> faster</li>
  1302. <li><a href="">rakudo/4eef6db</a> Make about <strong>4.4x</strong> faster</li>
  1303. <li><a href="">rakudo/ae5e510</a> Make <strong>7%</strong> faster when creating from Str</li>
  1304. <li><a href="">rakudo/0c6281</a> Make IO::Pipe.lines use IO::Handle.lines for <strong>3.2x</strong> faster performance</li>
  1305. </ul>
  1307. <h2>Performance Improvements Made By Other Core Developers</h2>
  1309. <p>lizmat++ also made these improvements in IO area:</p>
  1311. <ul>
  1312. <li><a href="">rakudo/b4d80c0</a> Make .IO.slurp about <strong>2x</strong> as fast</li>
  1313. <li><a href="">rakudo/9da50e3</a> Introducing IO::Handle.iterator</li>
  1314. <li><a href="">rakudo/9019a5b</a> Streamline IO::Handle.get/getc</li>
  1315. <li><a href="">rakudo/4bc826d</a> Streamline IO::Handle.get</li>
  1316. </ul>
  1318. <p>Along with the commits above, she also made IO::Handle.lines faster and
  1319. eliminated a quirk that required
  1320. custom <code>.lines</code> implementation in IO::Pipe (which is a subclass of IO::Handle).
  1321. Due to that, I was able to remove old IO::Pipe.lines implementation and make it
  1322. use new-and-improved IO::Handle.lines, which made the
  1323. method about 3.2x faster.</p>
  1325. <h2>Bugs</h2>
  1327. <h3>Will (attempt to) fix as part of the grant</h3>
  1329. <ul>
  1330. <li><code>IO::Pipe</code> inherits <code>.t</code> method from from <code>IO::Handle</code> to check if the handle
  1331. is a TTY, however, attempt to call it causes a segfault. MasterDuke++ already
  1332. found the candidate for the offending code
  1333. (<a href="">MoarVM/Issue#561</a>) and this
  1334. should be resolved by the time this grant is completed.</li>
  1335. </ul>
  1337. <h3>Don't think I will be able to fix these as part of the grant</h3>
  1339. <ul>
  1340. <li>Found a strange error generated when <code>IO::Pipe</code>'s buffer is filled up.
  1341. This is too deep in the guts for me to know how to resolve yet, so I filed it as
  1342. <a href="">RT#131026</a></li>
  1343. </ul>
  1345. <h3>Already Fixed</h3>
  1347. <ul>
  1348. <li>Made 7% faster when creating from paths strings and fixed
  1349. failure to detect <a href="">rakudo/ae5e51</a></li>
  1350. <li>Made about 4.4x faster <br />
  1351. <a href="">rakudo/4eef6d</a></li>
  1352. <li>Found that IO::Path had a vestigial .pipe method that delegated to a
  1353. non-existant IO::Handle method. Removed in <a href="">rakudo/a01d67</a></li>
  1354. <li>Fixed IO::Pipe.lines not accepting a Whatever as limit, which is accepted by
  1355. all other .lines. <a href="">rakudo/0c6281</a>
  1356. Tests in <a href="">roast/465795</a> and <a href="">roast/add852</a></li>
  1357. <li>Fixed issues due to caching of <code>IO::Handle.e</code>. Reported as
  1358. <a href="">RT#130889</a>. Fixed in
  1359. <a href="">rakudo/76f718</a>.
  1360. Tests in <a href="">roast/908348</a></li>
  1361. <li>Rejected <a href="">rakudo PR#666</a>
  1362. and resolved <a href="">RT#126262</a> by explaining why the methods return <code>Str</code> objects instead of <code>IO::Path</code> on
  1363. ticket/PR and improving the documentation by
  1364. fixing mistakes (<a href="">doc/ccae74</a>) and expanding (<a href="">doc/3cf943</a>) on what the methods do exactly.</li>
  1365. <li>IO::Path.Bridge was defunct, as it was trying to call .Bridge on Str, which
  1366. does not exist. Resolved the issue by deleting this method in <a href="">rakudo/212cc8</a></li>
  1367. <li>Per demand, made <code>IO::Path.dir</code> a multi, so module-space can augment it with
  1368. other candidates that add more functionality. <a href="">rakudo/fbe7ace</a></li>
  1369. </ul>
  1370. ]]>
  1372.    </content>
  1373. </entry>
  1375. <entry>
  1376.    <title>Call for Grant Proposals (March 2017 Round)</title>
  1377.    <link rel="alternate" type="text/html" href="" />
  1378.    <id>,2017://18.3858</id>
  1380.    <published>2017-03-24T01:10:02Z</published>
  1381.    <updated>2017-04-25T16:58:17Z</updated>
  1383.    <summary></summary>
  1384.    <author>
  1385.        <name>Coke</name>
  1387.    </author>
  1390.    <content type="html" xml:lang="en-us" xml:base="">
  1392.        <![CDATA[<p>The Grants Committee is accepting grant proposals all the time.
  1393. We evaluate them every two months and another evaluation period has come. This month's round is a little later than usual, due to the selection of
  1394. a new GC Secretary (myself). This round will be slightly compressed, and we'll strive to get back on track for the next round.</p>
  1396. <p>If you have an idea for doing some Perl work that will benefit the Perl
  1397. community, consider sending a grant application. <strong>The application deadline
  1398. for this round is 23:59 April 2nd UTC.</strong> We will publish the received applications, get community
  1399. feedback and conclude acceptance by April 12th.</p>
  1401. <p>To apply, please read <a href="">How
  1402. to Write a Proposal</a>. <a href="">Rules of
  1403. Operation</a> and <a href="">Running Grants List</a> will also help you understand how the grant process works. We also got some <a href="">grant ideas</a> from the community. The format is the same as the previous rounds in 2014-2016.</p>
  1405. <p>We will confirm the receipt of application within 24 hours.</p>
  1407. <p>If you have further questions, please contact me at tpf-grants-secretary at</p>
  1408. ]]>
  1409.    </content>
  1410. </entry>
  1412. <entry>
  1413.    <title>New Grant Committee Member &amp; Secretary</title>
  1414.    <link rel="alternate" type="text/html" href="" />
  1415.    <id>,2017://18.3857</id>
  1417.    <published>2017-03-24T00:51:07Z</published>
  1418.    <updated>2017-04-25T16:58:25Z</updated>
  1420.    <summary>Please join me in welcoming John SJ Anderson (genehack) as the newest voting member of The Perl Foundation&apos;s Grants Committee. John has helped organize several recent YAPCs, given talks and training at YAPCs, and maintains several modules on CPAN. Additionally, as Makoto Nozaki is transitioning to the secretary of the TPF Board, he is vacating the position of GC Secretary, and I have been selected to to fill the role. My apologies for the delays in the transition. Look for...</summary>
  1421.    <author>
  1422.        <name>Coke</name>
  1424.    </author>
  1426.        <category term="Grants" scheme="" />
  1429.    <content type="html" xml:lang="en-us" xml:base="">
  1430.        <![CDATA[<p>Please join me in welcoming John SJ Anderson (genehack) as the newest voting member
  1431. of The Perl Foundation's Grants Committee. John has helped organize several recent YAPCs,
  1432. given talks and training at YAPCs, and maintains several modules on CPAN.</p>
  1434. <p>Additionally, as Makoto Nozaki is transitioning to the secretary of the TPF Board,
  1435. he is vacating the position of GC Secretary, and I have been selected to
  1436. to fill the role.</p>
  1438. <p>My apologies for the delays in the transition. Look for a posting shortly about
  1439. the March call for proposals.</p>
  1440. ]]>
  1442.    </content>
  1443. </entry>
  1445. <entry>
  1446.    <title>Perl 6 IO Grant: February 2017 Report</title>
  1447.    <link rel="alternate" type="text/html" href="" />
  1448.    <id>,2017://18.3856</id>
  1450.    <published>2017-03-24T00:20:35Z</published>
  1451.    <updated>2017-04-25T16:58:33Z</updated>
  1453.    <summary></summary>
  1454.    <author>
  1455.        <name>Coke</name>
  1457.    </author>
  1459.        <category term="Grants" scheme="" />
  1461.        <category term="Perl 6 Development" scheme="" />
  1464.    <content type="html" xml:lang="en-us" xml:base="">
  1466.        <![CDATA[<p><i>Zoffix Znet provided this report on February 26, 2017</i></p>
  1468. <hr>
  1469.                            <p>This document is the February, 2017 progress report for <a href="">TPF Standardization,
  1470. Test Coverage, and Documentation of Perl 6 I/O Routines
  1471. grant</a></p>
  1473. <h2>Timing</h2>
  1475. <p>I'm currently running slightly behind the schedule outlined in the grant. I expect to complete the Action Plan and have it ratified by other core members by March 18th, which is the date of the 2017.03 compiler release. Then, I'll implement all of the Action Plan (and complete the grant) by the 2017.04 compiler release on April 15th. This is also the release the next Rakudo Star distribution will be based on, and so the regular end users will receive better IO there and then.</p>
  1477. <p>Some members of the Core Team voiced concerns over implementing any changes that can break users' code, even if the changes do not break 6.c-errata specification
  1478. tests. Once the full set of changes is known, they will be reviewed on a
  1479. case-by-case basis, and some of them may be implemented under 6.d.PREVIEW
  1480. pragma, to be included in 6.d language version, leaving 6.c language versions
  1481. untouched. Note that changes that are decided to be 6.d material may delay
  1482. the completion of this grant due to not fully-fleshed out infrastructure for
  1483. supporting multiple language versions. The April 15th deadline stated above
  1484. applies only to changes to 6.c language and new deadline will be ascertained
  1485. for completion of the 6.d changes.</p>
  1487. <h2>User Communications</h2>
  1489. <p>I wrote and disseminated advanced notice of the changes to be made due to this grant, to prepare the users to expect some code to break (some routines were found to be documented, despite being absent entirely from the <a href="">Specification</a> and not officially part of the language).</p>
  1491. <p>The notice can be seen at: <a href="">
  1492.    </a></p>
  1494. <p>It is possible the Core Team will decide to defer all breaking changes to
  1495. 6.d language version, to be currently implemented under <code class="prettyprint">v6.d.PREVIEW</code> pragma.</p>
  1497. <h2>Bonus Deliverable</h2>
  1499. <p>The bonus deliverable—The Map of Perl 6 Routines—is now usable. The code is available in <a href="">perl6/routine-map</a> repository, and the rendered version is available on <a href=""></a>. Its current state is sufficient
  1500. to serve the intended purpose for this grant, but I'll certainly add improvements to it sometime in the future, such as linking to docs, linking to routines' source code, having an IRC bot looking stuff up in it, etc.</p>
  1502. <p>It'll also be fairy easy to use the Map to detect undocumented routines or ones that are documented under the incorrect type.</p>
  1504. <h2>Identified Issues/Deficiencies with IO Routines</h2>
  1506. <p>These points, issues, and ideas were identified this month and will be included for consideration in the Action Plan.</p>
  1508. <ul>
  1509. <li>Calling practically any method on a closed IO::Handle results in an LTA (Less Than Awesome)
  1510. error message that reads <code class="prettyprint">&lt;something&gt; requires an object with REPR MVMOSHandle</code> where <code class="prettyprint">&lt;something&gt;</code> is
  1511. sometimes the name of the method called by the user and others is some internal method
  1512. invoked indirectly. We need better errors for closed file handles; and not something that would require a
  1513. <code class="prettyprint">is-fh-closed()</code> type of conditional called in all the methods, which would be a hefty
  1514. performance hit.</li>
  1515. <li>Several routines have been identified which in other languages return useful information:
  1516. number of bytes actually written or current file position, whereas in Perl 6 they just
  1517. return a Bool (<code class="prettyprint">.print</code>, <code class="prettyprint">.say</code>, <code class="prettyprint">.write</code>) or a Mu type object (<code class="prettyprint">.seek</code>). Inconsistently,
  1518. <code class="prettyprint">.printf</code> does appear to return the number of bytes written. It should be possible
  1519. to make other routines similarly useful, although I suspect some of it may have to
  1520. wait until 6.d language release.</li>
  1521. <li>The <code class="prettyprint">.seek</code> routine takes the seek location as one of three Enum values. Not only are they
  1522. quite lengthy to type, they're globally available for no good reason and <code class="prettyprint">.seek</code> is virtually
  1523. unique in using this calling convention. I will seek to standardize this routine to take
  1524. mutually-exclusive named arguments instead, preferably with much shorter names, but those
  1525. are yet to be bikeshed.</li>
  1526. <li><code class="prettyprint">IO.umask</code> routine simply shells out to <code class="prettyprint">umask</code>. This fails terribly on OSes that don't have
  1527. that command, especially since the code still tries to decode the received input as
  1528. an octal string, even after the failure. Needs improvement.</li>
  1529. <li><code class="prettyprint">link</code>'s implementation and documentation confuses what a "target" is. Luckily (or sadly?)
  1530. there are exactly zero tests for this routine in the Perl 6 Specification, so we can
  1531. change it to match the behaviour of <code class="prettyprint">ln</code> Linux command and the <code class="prettyprint">foo $existing-thing, $new-thing</code>
  1532. argument order of <code class="prettyprint">move</code>, <code class="prettyprint">rename</code>, and other similar routines.</li>
  1533. <li>When using <code class="prettyprint">run(:out, 'some-non-existant-command').out.slurp-rest</code>
  1534. it will silently succeed and return an empty string. If possible, this
  1535. should be changed to return the failure or throw at some point.</li>
  1536. <li><code class="prettyprint">chdir</code>'s <code class="prettyprint">:test</code> parameter for directory permissions test is taken as a
  1537. single string parameter. This makes it extremely easy to mistakenly write
  1538. broken code: for example, <code class="prettyprint">"/".IO.chdir: "tmp", :test&lt;r w&gt;</code> succeeds, while
  1539. <code class="prettyprint">"/".IO.chdir: "tmp", :test&lt;w r&gt;</code> fails with a misleading error message
  1540. saying the directory is not readable/writable. I will propose for <code class="prettyprint">:test</code>
  1541. parameter to be deprecated in favour of using multiple named arguments to
  1542. indicate desired tests. By extension, similar change will be applied to
  1543. <code class="prettyprint">indir</code>, <code class="prettyprint">tmpdir</code>, and <code class="prettyprint">homedir</code> routines (if they remain in the language).</li>
  1544. <li><em>Documentation:</em> several inaccuracies in the documentation were found. I won't be identifying these in my reports/Action Plan, but will simply ensure the documentation matches the implementation once the Action Plan is fully implemented.</li>
  1545. </ul>
  1547. <h2>Discovered Bugs</h2>
  1549. <p>The hunt for 6-legged friends has these finds so far:</p>
  1551. <h4>Will (attempt to) fix as part of the grant</h4>
  1553. <ul>
  1554. <li>indir() has a race condition where the actual dir it runs in ends up being wrong.
  1555. Using <code class="prettyprint">indir '/tmp/useless', { qx/rm -fr */ }</code> in one thread and backing
  1556. up your precious data in another has the potential to result in some spectacular failurage.</li>
  1557. <li><code class="prettyprint">perl6 -ne '@ = lines'</code> crashes after first iteration, crying about <code class="prettyprint">MVMOSHandle REPR</code>. I suspect
  1558. the code is failing to follow iterator protocol somewhere and is attempting to read
  1559. on an already closed handle. I expect to be able to resolve this and the related
  1560. <a href="">RT#128047</a> as part of the grant.</li>
  1561. <li><code class="prettyprint">.tell</code> incorrectly always returns <code class="prettyprint">0</code> on files opened in append mode</li>
  1562. <li><code class="prettyprint">link</code> mixes up target and link name in its error message</li>
  1563. </ul>
  1565. <h4>Don't think I will be able to fix these as part of the grant</h4>
  1567. <ul>
  1568. <li><code class="prettyprint">seek()</code> with <code class="prettyprint">SeekFromCurrent</code> as location fails to seek correctly if called
  1569. after <code class="prettyprint">.readchars</code>, but only on MoarVM. This appears to occur due to some sort of buffering.
  1570. I filed this as <a href="">RT#130843</a>.</li>
  1571. <li>On JVM, <code class="prettyprint">.readchars</code> incorrectly assumes all chars are 2 bytes long. This appears to be
  1572. just a naive substitute for nqp::readcharsfh op. I filed this as
  1573. <a href="">RT#130840</a>.</li>
  1574. </ul>
  1576. <h4>Already Fixed</h4>
  1578. <ul>
  1579. <li>While making the Routine Map, I discovered <code class="prettyprint">.WHICH</code> and <code class="prettyprint">.Str</code> methods on <code class="prettyprint">IO::Special</code> were <code class="prettyprint">only</code>
  1580. methods defined only for the <code class="prettyprint">:D</code> subtype, resulting in a crash when using, say, <code class="prettyprint">infix:&lt;eqv&gt;</code>
  1581. operator on the type object, instead <code class="prettyprint">Mu.WHICH</code>/<code class="prettyprint">.Str</code> candidates getting invoked.
  1582. This bug was easy and I already commited fix in
  1583. <a href="">radudo/dd4dfb14d3</a>
  1584. and tests to cover it in
  1585. <a href="">roast/63370fe054</a></li>
  1586. </ul>
  1588. <h4>Auxiliary Bugs</h4>
  1590. <p>While doing the work for this grant, I also discovered some non-IO related bugs (some of which I fixed):</p>
  1592. <ul>
  1593. <li><code class="prettyprint">.Bool</code>, <code class="prettyprint">.so</code>, <code class="prettyprint">.not</code>, <code class="prettyprint">.has</code>h, and <code class="prettyprint">.elems</code> on <code class="prettyprint">Baggy:U</code> crash
  1594. (<a href="">fixed in e8af8553</a>)</li>
  1595. <li><code class="prettyprint">.sort</code> on reified empty arrays crashes (<a href="">reported as RT#130866</a>)</li>
  1596. <li>SEGV with Scalar type object in unique() (<a href="">reported as RT#130852</a>)</li>
  1597. <li><code class="prettyprint">.Bool</code>, <code class="prettyprint">.so</code>, <code class="prettyprint">.not</code> and possibly others crash on <code class="prettyprint">Seq:U</code>; need to evaluate entire codebase to see where <code class="prettyprint">only</code>
  1598. methods are used instead of <code class="prettyprint">multi</code>, preventing dispatch to <code class="prettyprint">Mu.*</code> candidates. (<a href="">reported as RT#130867
  1599. </a>)</li>
  1600. <li>Incorrect line number reported for wrong routine call when unpacking/heredocs are used (<a href="">reported
  1601. as RT#130862</a>)</li>
  1602. <li>Warnings produced by core code marked as "shouldn't happen" (<a href="">reported as
  1603. RT#130857</a>)</li>
  1604. </ul>
  1605. ]]>
  1606.    </content>
  1607. </entry>
  1609. <entry>
  1610.    <title>TPF Committee Updates</title>
  1611.    <link rel="alternate" type="text/html" href="" />
  1612.    <id>,2017://18.3855</id>
  1614.    <published>2017-03-22T09:00:00Z</published>
  1615.    <updated>2017-03-27T11:06:44Z</updated>
  1617.    <summary>We&apos;ve been reviewing Perl Foundation committees over the last few months and I&apos;m happy to report some new people have stepped into committee leadership roles. David Oswald is the new conferences committee chair. This position had gone vacant for a period as TPF Treasurer Dan Wright along with others took a more active role in planning for The Perl Conference. The board is happy to once again have someone in this role to help spread the work and responsibilities. David...</summary>
  1618.    <author>
  1619.        <name>Jim Brandt</name>
  1620.        <uri></uri>
  1621.    </author>
  1623.        <category term="Perl Foundation" scheme="" />
  1626.    <content type="html" xml:lang="en-us" xml:base="">
  1627.        <![CDATA[<p>We've been reviewing Perl Foundation committees over the last few months and I'm happy to report some new people have stepped into committee leadership roles.</p>
  1629. <p>David Oswald is the new conferences committee chair. This position had gone vacant for a period as TPF Treasurer Dan Wright along with others took a more active role in planning for The Perl Conference. The board is happy to once again have someone in this role to help spread the work and responsibilities.</p>
  1631. <p>David was one of the lead organizers of YAPC::NA 2015 in Salt Lake City. He is also on the organizing team for the <a href="">OpenWest</a> open source conference. We're confident David's experience will help with this year's <a href="">Perl Conference</a> and with planning going forward.</p>
  1633. <p>Will Coleda is the new Secretary of the Grants Committee. Will has been a member of the Grants Committee since 2008, and involved with the Perl 6 community and development for over a decade. Will's selection is a great example of the cycle of involvement for a TPF member, starting as a committee member and then taking on a bigger role over time.</p>
  1635. <p>The outgoing secretary, Makoto Nozaki, has held this position since February 2014 and he will continue his work as Perl Foundation board Secretary.</p>
  1637. <p>As part of our committee review, I have also been looking into other committees that have recently been less active or inactive. As a result, the Steering Committee is being sunsetted.</p>
  1639. <p>The Steering Committee was originally created as a forum to pull in more active community members to carry out TPF business in the earlier years of the foundation when the board was much less active. When Karen Pauley, who was Steering Committee Chair, took over as president, this activity moved to the board. New committees also were created to handle specific areas of activity like conferences, grants, and marketing. With TPF activity moving to these other groups, the Steering Committee has been largely dormant so we're dissolving it. Thanks to all of the members who contributed their time to TPF through this committee.</p>
  1641. <p>Another committee we are evaluating is the Community Advocacy Committee. This committee was driven for many years by Ya'akov Sloman and we thank him for all of this efforts. He stepped down last year and the committee has been mostly inactive, so we are considering dissolving it as well. However, the board is open to proposals to revive the committee if community members are available to come forward. The <a href="">committee charter is available</a> for review and could be revised by new members if desired.</p>
  1643. <p>Please join us in congratulating and thanking David and Will as they take on their new roles. You can expect to hear more from them in the near future.</p>
  1644. ]]>
  1646.    </content>
  1647. </entry>
  1649. <entry>
  1650.    <title>Maintaining the Perl 5 Core: February 2017 report</title>
  1651.    <link rel="alternate" type="text/html" href="" />
  1652.    <id>,2017://18.3854</id>
  1654.    <published>2017-03-13T23:00:00Z</published>
  1655.    <updated>2017-03-14T03:58:13Z</updated>
  1657.    <summary>This is a monthly report by Dave Mitchell on his grant under Perl 5 Core Maintenance Fund. We thank the TPF sponsors to make this grant possible. The main things I did last month were: Firstly, fixing various issues with scopes in regexes. In particular, (RT #126697), code blocks sometimes failed to undo localisations when backtracking. For example the $s below wasn&apos;t always being restored when the B part of the match failed and it backtracked to try another A...</summary>
  1658.    <author>
  1659.        <name>Makoto Nozaki</name>
  1660.        <uri></uri>
  1661.    </author>
  1663.        <category term="Grants" scheme="" />
  1665.        <category term="Perl 5 Development" scheme="" />
  1668.    <content type="html" xml:lang="en-us" xml:base="">
  1669.        <![CDATA[<p>This is a monthly report by Dave Mitchell on his grant under <a href="">Perl 5 Core Maintenance Fund</a>. We thank the TPF sponsors to make this grant possible.</p>
  1671. <pre>
  1672. The main things I did last month were:
  1674. Firstly, fixing various issues with scopes in regexes. In particular,
  1675. (RT #126697), code blocks sometimes failed to undo localisations when
  1676. backtracking. For example the $s below wasn't always being restored when
  1677. the B part of the match failed and it backtracked to try another A - where
  1678. A represents something complex like (\w+\s+)* which can match in multiple
  1679. ways:
  1681.    /A(?{ local $s = ...})B/
  1683. As part of that work, non-greedy matching of complex sub-expressions with
  1684. captures and repeated backtracking was made more efficient under some
  1685. circumstances; for example the following now runs about 25% faster:
  1687.    $s = ("a" x 1000);
  1688.    $s =~ /^(?:(.)(.))*?[XY]/ for 1..10_000;
  1690. Secondly, improving 't/TEST -deparse'.
  1692. The -deparse option to t/TEST causes it to run all the core's test
  1693. scripts, but after running them through the deparser first. Many of these
  1694. modified scripts are currently known to fail, and there is an exclusion
  1695. file, Porting/deparse-skips.txt, which is supposed to list the known
  1696. failures. However, over time, new failures have appeared which are not in
  1697. the exclusion list. Last August I did some work on and managed
  1698. to reduce some of the expected and unexpected failures, but since then
  1699. more failures have crept in.
  1701. My recent work includes: modifying t/TEST so that it distinguishes
  1702. between expected failures and unexpected passes, and warning of unknown
  1703. files in Porting/deparse-skips.txt; purging Porting/deparse-skips.txt to
  1704. account for files that have been renamed or are no longer in the core, and
  1705. to reflect the current state of things; and fixing to:
  1706.    * better handle 'BEGIN { use_ok() }';
  1707.    * better handle 'BEGIN { require expr }' (as opposed to require Bareword);
  1708.    * deparse lexical var attributes, e.g. 'my $foo :bar(baz)';
  1709.    * avoid a 'deep recursion' warning;
  1710.    * handle an escaped literal tab char in a pattern, e.g
  1711.        /.....\ ..../x where the whitespace char following the backslash is
  1712.        actually a tab; previously the deparse failed to emit the backslash;
  1713.    * handle declarations with multiple lexical vars within a pattern code
  1714.      block, e.g. /(?{ my ($x, $y) = @a; })/
  1716. Because we're currently in code freeze, this as been pushed as
  1717. smoke-me/davem/deparse and will be merged in 5.27.x.
  1719. Thirdly, reviewing and fixing tickets in the security queue. There's quite
  1720. a lot of tickets in the security queue due to fuzzing, where if the fuzzer
  1721. detects a use-after-free or buffer overrun for example, the reporter
  1722. submits it to the security queue rather than the normal queue. Once
  1723. examined, 95% of the time it will be found to be harmless or
  1724. non-exploitable, but until someone has assessed and fixed it, it lingers
  1725. as an open security ticket.
  1727. </pre>
  1728. ]]>
  1729.        <![CDATA[<pre>
  1730. SUMMARY:
  1731.     10:52 RT #126697 local() in embedded code in regex not working as expected
  1732.      0:09 RT #128528 XSLoader may load relative paths
  1733.      7:39 RT #129861 heap-use-after-free S_mro_gather_and_rename
  1734.      6:05 RT #129881 heap-buffer-overflow Perl_pad_sv
  1735.      2:11 RT #130321 heap-buffer-overflow Perl_vivify_ref (pp_hot.c:4362)
  1736.      0:04 RT #130332 double-free affecting multiple Perl versions
  1737.      0:36 RT #130336 attempting free on address which was not malloc()-ed
  1738.      0:10 RT #130344 heap-use-after-free S_gv_fetchmeth_internal
  1739.      1:46 RT #130569 heap-use-after-free in S_regmatch
  1740.      0:43 RT #130624 heap-use-after-free in Perl_sv_setpvn
  1741.      1:56 RT #130650 heap-use-after-free in S_free_codeblocks
  1742.      6:04 RT #130703 heap-buffer-overflow in Perl_pp_formline
  1743.      4:22 RT #130727 S_maybe_multideref: Assertion failed
  1744.      2:22 RT #130766 Substr in encode leaks memory
  1745.      1:12 RT #130841 AddressSanitizer: heap-buffer-overflow
  1746.      0:39 fixup Module::CoreList
  1747.     13:17 fixup failing TEST -deparse issues
  1748.      9:30 process p5p mailbox
  1749.     10:30 review security tickets
  1750.    ------
  1751.     80:07 TOTAL (HH::MM)
  1753. 176.3 weeks
  1754. 2456.8 total hours
  1755.  13.9 average hours per week
  1757. There are 343 hours left on the grant
  1758. </pre>
  1759. ]]>
  1760.    </content>
  1761. </entry>
  1763. <entry>
  1764.    <title>Makoto Nozaki Appointed Secretary</title>
  1765.    <link rel="alternate" type="text/html" href="" />
  1766.    <id>,2017://18.3853</id>
  1768.    <published>2017-03-02T08:29:29Z</published>
  1769.    <updated>2017-03-02T13:37:24Z</updated>
  1771.    <summary>The Perl Foundation is excited to announce that Makoto Nozaki, grants chair, has joined TPF board as secretary. He has served as grants chair since 2014 and has done a great job overseeing grants and providing funding for perl projects. In addition to supporting Makoto&apos;s TPF work, Two Sigma Investments, LP, Makoto&apos;s employer, has also provided donations to TPF for which we are very grateful. A focus for us this year is bringing new people into TPF at all levels,...</summary>
  1772.    <author>
  1773.        <name>Jim Brandt</name>
  1774.        <uri></uri>
  1775.    </author>
  1777.        <category term="Perl Foundation" scheme="" />
  1780.    <content type="html" xml:lang="en-us" xml:base="">
  1781.        <![CDATA[<p>The Perl Foundation is excited to announce that Makoto Nozaki, grants chair, has joined TPF board as secretary. He has served as grants chair since 2014 and has done a great job overseeing grants and providing funding for perl projects. In addition to supporting Makoto's TPF work, <a href="">Two Sigma Investments, LP</a>, Makoto's employer, has also provided donations to TPF for which we are very grateful.</p>
  1783. <p>A focus for us this year is bringing new people into TPF at all levels, and adding a new member to the board as a replacement for Karen Pauley is part of that effort. Thank you to Karen for all of her years of service on the board. As part of his role, Makoto will be taking on some projects to help us get the community more involved.</p>
  1785. <p>One important project scheduled for this year is to launch an updated and more public process for nominating and appointing new board members. TPF isn't a membership organization, so this doesn't mean we'll have elections. However, we would like to get the community involved in nominations and to have an opportunity to ask questions and interact with prospective board members as part of the evaluation process.</p>
  1787. <p>Once we have a new process in place for bringing in new board members, we plan to add more structure around the 2 year terms defined in the TPF bylaws. Currently board members have held their seats until they step down, typically because of time constraints. We would like to revise this process such that at the end of a 2 year term, existing board members will actively seek out another 2 year term if they would like to continue to serve.</p>
  1789. <p>These initiatives are at the idea phase right now and there are many details to work out to define the actual processes for both. We look forward to working these out with Makoto's active work over the next year.</p>
  1790. ]]>
  1792.    </content>
  1793. </entry>
  1795. </feed>

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

  1. Download the "valid Atom 1.0" banner.

  2. Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)

  3. Add this HTML to your page (change the image src attribute if necessary):

If you would like to create a text link instead, here is the URL you can use:

Copyright © 2002-9 Sam Ruby, Mark Pilgrim, Joseph Walton, and Phil Ringnalda