<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>Hi,</p>
<p>find ich sehr gut! Gerade bei Parallelität und Asynchronität sehe ich die Stärken von Perl 6.</p>
<p>+1 von mir also.</p>
<p>LG Alex</p>
<p>Am 2017-08-29 11:49, schrieb Thomas Klausner:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Hi!<br /> <br /> Beim letzten Meeting (im Juni) haben wir (bzw ein Teil) besprochen, dass <br /> wir einen Teil unseres immer noch vorhandenen YAPC-2007-Geldes ausgeben <br /> koennen, indem wir Jonathan Worthington sponsorn, ein paar nette <br /> Perl6-Features zu implementieren.<br /> <br /> Er ist dazu generell bereit (bzw sucht ja aktiv Sponsoren):<br /> <a href="https://6guts.wordpress.com/2017/05/12/looking-for-perl-6-rakudo-and-moarvm-development-funding/">https://6guts.wordpress.com/2017/05/12/looking-for-perl-6-rakudo-and-moarvm-development-funding/</a><br /> <br /> Jonathan hat mir vor dem Sommer mal eine Liste mit Ideen geschickt, was <br /> er in ca 50h machen koennte (siehe weiter unten). Ich weiss nicht, ob <br /> die Liste noch aktuell ist, aber falls nicht, koennen wir sicher <br /> aehnliche Features finden.<br /> <br /> Budgetmaessig reden wir von 55€ x 50h = 2750€<br /> Am Konto haben wir etwas ueber 6000€<br /> <br /> Ich wuerde vorschlagen, wir diskutieren das mal kurz, und machen nachste <br /> Woche eine Abstimmung (sagen wir bis Freitag, 8.9., 12:00)<br /> Da es um Vereinsgeld geht, sind bei der Abstimmung nur Vereinsmitglieder <br /> stimmberechtigt. Vereinsmitglied ist, wer den Mitgliedsbeitrag (10€) <br /> bezahlt hat (allerdings sind die Aufzeichnungen daruber recht duerftig). <br /> Falls also jemand noch schnell bezahlen mag:<br /> <a href="http://vienna.pm.org/verein.html">http://vienna.pm.org/verein.html</a><br /> Name: VIENNA.PM-VEREIN PROGRAMMIERSPRACHE PERL<br /> IBAN: AT133200000002776474<br /> BIC: RLNWATWW<br /> <br /> (und wow, die website ist alt!)<br /> <br /> <br /> <br /> Jonathans Vorschlaege vom 21.6.:<br /> <br /> There are certainly a number of outstanding concurrency and parallelism<br /> tasks which would benefit from funding. Some key areas are:<br /> <br /> * Completing the work on non-blocking `await`, which makes `await` not<br /> really block a thread in the thread pool, but instead return it to the<br /> scheduler to use for something else. At present, it's quite easy -<br /> especially if doing divide and conquer style things - to exhaust the thread<br /> pool, but with most threads blocked awaiting a result from a child task<br /> rather than actually doing work. With this change, the threads would not<br /> block, but instead work on completing the child tasks. This was always the<br /> plan, but there wasn't time ahead of 6.c to realize it. I already started<br /> this work and have a working proof of concept (just `use v6.d.PREVIEW`),<br /> but it interacts badly with `supply`/`react` blocks and has some other<br /> rough edges that need dealing with before we can really consider it ready.<br /> This would be a good thing to deal with.<br /> <br /> * Improving the thread pool scheduler. This is the component that spreads<br /> tasks over threads. The current implementation is very simplistic, usually<br /> starting more threads than are really needed. It also doesn't distinguish<br /> between time, I/O, and computation in any way, meaning that a huge amount<br /> of input coming in from a spawned process can swamp the work queue and<br /> prevent a timer event intended to kill the process from firing on time.<br /> There's many ways to do better in this area.<br /> <br /> * Continuing the work on .race and .hyper, which should allow for data<br /> parallel list operations (think of a chain of map and grep, but where the<br /> input data is partitioned automatically into chunks and then the chains run<br /> on different threads). I've done a good bit of planning work on this front,<br /> but now the actual implementation work is needed.<br /> <br /> Any of these would be useful (I suspect with 50 hours I could deal with the<br /> first issue and get a good way into the second, for example). I'm open to<br /> other suggestions and priorities you might come up with also.<br /> <br /> <br /> <br /> Schoene Gruesse,<br /> Thomas</div>
</blockquote>
<p><br /></p>
</body></html>