Post closed tickets in your report. | Note: This channel is for our weekly status meetings (Tuesdays at 19:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/
Set by moderator on 2 March 2013.
13:09 bluescreen joined 16:07 xcombelle joined 17:35 tadzik joined 18:52 darbelo joined 19:25 contingencyplan joined 19:27 not_gerd joined 19:29 bluescreen joined 19:45 moritz joined
cotto hello 19:50
not_gerd o/
not_gerd needs to discuss his readline() changes
cotto Go for it. 19:51
not_gerd ok
Rakudo's HTTP::Easy is broken
readline waits for max_bytes_per_codepoint chars (4 in case of UTF-8), but an empty line only has two (\\r\\n) 19:52
this means we're blocking until the client closes the connection, never terminating the HTTP header
I fixed that in a branch and sent a pull request, which JimmyZ applied (prematurely) 19:53
I regressed on some other things, and have a 2nd pull request open tp fix that
either the 2nd request needs to be applied as well or ther merge into master reverted
cotto I appreciate the documentation updates in that pull request. 19:54
not_gerd I also changed readline semantics a bit - it always block until a whole line is read 19:55
otherwise, we need to recreate the whole buffering logic again on the Rakudo side 19:56
note that even before my changes, readline could potentially block
(which is the reason behind the HTTP::Easy breakage)
there's till an edge case that's not handles corretcly, I believe: 19:57
interaction of non-readline IO with readline
if it happens that a multi-byte terminator gets spit across chunks and you do a non-readline read before a readline one, you'll never find the terminator 19:58
also, I did not see any code to handle a wrong terminator encoding
my preference for now: merge 2nd oull request into master, handle terminator encoding Rakudo-side and add timeout logic (possibly via new socket handle attribute) at a later date 20:00
^pull request
Util needs to discuss pending murderous branches. 20:02
cotto After giving the pull request a brief overview, it looks good. That code is plenty of edge cases though, so more careful review wouldn't hurt.
not_gerd: If nobody finds the time to review it in the next few days, feel free to merge. 20:03
not_gerd note that the 2nd pull request passes all tests, and whiteknight did cover many edge cases - just not all of them, and in particular socket IO seems to be insufficiently tested 20:04
there are 3 test I'd like to see added 20:05
I can probably do that this week
cotto not_gerd: even better
not_gerd (will involve some PIR cargo coding - why can't I write tests in Perl6 ;))
cotto not_gerd: I know that feeling. 20:06
not_gerd: is there anything else you need before we go on to Util? 20:07
not_gerd no, that's it from me
cotto Util: What's your concern? Are the branches not murderous enough? 20:08
Util I know that we are focusing on Rakudo now, to the exclusion of theoretical needs of other theoretical language clients,
and to that end we have branches that will kill off some of Parrot's current functionality.
Since we may have DarkPAN clients, please `git tag` our repo with something that indicates the loss of a group of features,
just before any branch merge that kill the features.
That will allow easier recovery of the features if we need them in the future, and allow easier forking of Parrot
if a unknown client relied on those features.
cotto Util: that's a reasonable request. I don't like the DarkPAN argument as a reason for keeping features around, but tags aren't much of a burden. 20:09
not_gerd note that except one commit that probably targeted the wrong branch, all killing till now has happened in a branch 20:11
the final decision to make sixparrot master hasn't happened yet
Util Ignoring DarkPAN, we are leaving clues for the archeologists who may dig for our murdered code after we all are no longer available to ask.
cotto not_gerd: I thought that it was already decided, just not executed yet. 20:12
Util Unrelated: I intend to claim Manager role for next week's release, to shake out changes to our R.M.Guide.
cotto or rather, decided apart from the timing
Util Do we have benchmarks showing improvement in Rakudo due to any feature removal? 20:14
not_gerd my fear is that sixparrot quietly dies (like, say, the m0 effort) so I'd like to delay the move to master until there's some real benefit to Rakudo (performance!) 20:15
cotto The work that's been done so far isn't expected to have a direct performance impact. Removing things like nqp-rx means that we're less constrained in what we can remove, but it doesn't have a direct impact in itself.
allison++'s mmd removal may have a small change though 20:17
Util As long as there is strategy & thought behind removal, I am fine with removal without direct performance impact. I was loosely following some changes and discussions, and became worried that some of it was just in the form of "well, we *can* remove this and Rakudo will still work, so *remove* it." 20:18
cotto That's hard to resist. 20:19
not_gerd imagines a mob of developers relying on OpenGL and SDL waiting at my door, pitchforks at the ready 20:21
Util Even if one can't resist mudering everything extraneous, I recommend prioritizing the *completion* of murderous branches and merges that have strategic value *over* less helpful pruning of the meerly extraneous. 20:23
That is just a nudge in a helpful direction, to any mobs with pitchforks :) 20:25
Right now, I favor the active mob over a ghost-town of inactivity. 20:26
We are reaching 1 hour; anything else to discuss? 20:28
cotto not on my end
not_gerd neither 20:29
cotto Let's call it a wrap. 20:30
20:32 not_gerd left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!