pmichaud (RFC tickets) I'm not entirely comfortable with the notion that language RFCs have the same ticket queue as rakudo bugfixes. To me it promotes too strongly the notion that "Rakudo" == "Perl 6". 02:59
But since I'm not terribly active at the moment, that position perhaps should not carry a lot of weight. 03:00
AlexDaniel pmichaud: I think that most people agree, but what's the alternative? 03:13
committable6: 2015.09,HEAD say join ", ", "ag".."bc" 03:15
committable6 AlexDaniel, ¦«2015.09,HEAD»: ag, af, ae, ad, ac, bg, bf, be, bd, bc
AlexDaniel committable6: 2015.09,HEAD say ‘-5’.succ 03:16
committable6 AlexDaniel, ¦«2015.09,HEAD»: -6
AlexDaniel huggable: dunno
huggable AlexDaniel, ¯\_(ツ)_/¯
pmichaud AlexDaniel: Separate queues for language tickets and rakudo tickets. 03:35
AlexDaniel pmichaud: ah
pmichaud For a while we were doing that by using GitHub's issue tracker on the perl6/specs repository as a place for language discussions to take place.
AlexDaniel so the current queue should be renamed to “rakudo” then?
pmichaud Either that, or we start migrating rakudo tickets to a GitHub issue tracker. But I'm sure people are very much not wanting to do that. 03:36
If the current dev team is fine with mixing language and rakudo issues on the same issue tracker, I won't object. I just think it (wrongly) reinforces the notion that whatever Rakudo does is the language spec. 03:38
and we've worked so hard to separate the two that it seems bad to let an issue tracker muddle things up again
AlexDaniel 👍 03:39
ShimmerFairy pmichaud: yeah, I'd rather see the tracker at least on a separate "group", if not issues on perl6/specs or perl6/roast 04:54
maybe even a 'rfcs.perl6.org' would be a possibility in the future?
in fact, maybe rakudo's tickets should move to GitHub, considering the RT queue is called "perl6", and not "rakudo" :P 05:03
b2gills star-m: say ([[&({@_})]] 1).perl 06:05
camelia star-m 2016.04: OUTPUT«1␤»
b2gills m: say ([[&({@_})]] 1).perl
camelia rakudo-moar b1c444: OUTPUT«[1]␤»
[Tux] This is Rakudo version 2016.08.1-55-gb1c444f built on MoarVM version 2016.08 06:27
csv-ip5xs 10.363
test 15.628
test-t 7.461
csv-parser 16.663
lizmat commute& 07:56
jnthn morning, #perl6-dev 09:20
DrForr Mornin'.
timotimo greetings jnthn 09:21
JimmyZ morning :) 09:26
jnthn has tuits today :) 09:28
masak \o/ 09:29
are they... *round*!? o.O
jnthn They appear to be. 09:30
masak given the number of commits I'm making this morning, I appear to have some too :D 09:32
DrForr I used to make a business filing down square tuits. 09:41
|Tux| jnthn++ 09:47
DrForr jnthn++ # Agreed. 09:49
jnthn is having no luck reproducing rt.perl.org/Ticket/Display.html?id=129120 locally 09:52
Granted I don't have a 32 core box :P
timotimo the worst thing about that code is that it pushes results into an array when it could just use the return value of the for loop instead :P 09:54
JimmyZ jnthn: I can try to reproduce it :) 09:55
jnthn Feel free 09:59
I left some hints on the ticket too 10:00
pmichaud Good morning, #perl6-dev
jnthn o/ pmichaud 10:01
pmichaud: From backlog: I agree language RFCs going in a separate queue would be preferable. 10:02
pmichaud jnthn: thanks. :)
now the question is "How do we do that?"
jnthn Well, that's the harder part. :P
pmichaud given that people have apparently been using the perl6 RT queue for that purpose. 10:03
short answer is to migrate those tickets to wherever we want such things to go.
jnthn Yeah, I don't know why we started having that happen instead of filing them on the design docs github repo
(Is it still called spec? :P)
pmichaud I suspect someone just assumed it was like perl 5, and that it made sense to do RFCs in the rakudo queue
jnthn Yeah
pmichaud and that nobody carped about it until I came in
jnthn Relatedly, do we want to try and get people to provide certain information in an RFC? 10:04
pmichaud Oh, that's an interesting idea.
jnthn It might be nice if we had a page where we can point people at on how to file them, with both where to file them and what info to include.
nine Like a real world use case and information why existing alternatives just won't do it?
pmichaud At any rate, if perl6/specs repo is relegated to "historical" status, I'm not sure the specs/ issue tracker is the place for such things either. 10:05
maybe perl6/roast issue tracker
that would also help reinforce that it's the roast tests that define the language 10:06
jnthn That's an interesting idea.
pmichaud once we figure out where language tickets should go, the next step is to close out the [RFC] tickets in the RT queue by pointing them to the equivalent-minded issues in the new ticket queue 10:07
I think there's only 50 or so of those, so not too onerous yet. 10:08
cygx o/
JimmyZ jnthn: turns out no need 32 core, it happens only sometimes
timotimo so force_gc somewhere perhaps? :P
cygx
.oO( why not just a new repository? )
JimmyZ I got it on my 4 core box :P
cygx incidentally: gist.github.com/cygx/7d792e09b182a...82663dfddb
pmichaud cygx: why not perl6/roast ? 10:09
jnthn JimmyZ: Hm, wonder why I couldn't get it on mine
timotimo when you have encoding and decoding, how should tell and seek work?
JimmyZ I run it two times, and got this error
jnthn o.O
cygx pmichaud: seems a bit of a mixture of concerns again, as the queue will presumably contain both actual bugs inthe test suite and language rfcs... 10:10
jnthn JimmyZ: Can you try the things I suggested in the RT?
cygx: Arguably those are one and the same :)
pmichaud cygx: sure, but that sort of mixing I don't mind.
JimmyZ yeah, not sure I can get it again, haha
pmichaud a bug in the test suite probably means we need a language discussion about why it's a bug
jnthn cygx: If you want to change an existing test that was passing you're changing something somebody could have relied on, and that we'd insinuated we'd support 'cus it's in the test suite. :)
ShimmerFairy
.oO(There is a universe of tests that are implicitly fudged and skip()'d)
 10:11
cygx I don't have any strong feelings on it, it's just that while 'proposing to change a test' and 'proposing a new language feature' feel different to me (yeah, I know, the language is defined in terms of the tet suite and all that ;) ) 10:13
nine pmichaud: it may as well just be a bug in the test setup code completely unrelated to the functionality tested.
cygx s/while//
JimmyZ jnthn: ok, I got it again, I posted it to the rt
pmichaud nine: sure... but I can't see the mixing of roast bugs and language discussions as being a big problem 10:14
as opposed to what we have now, where rakudo's bug tracker is being used to propose language feature changes, entirely removed from roast or spec
ShimmerFairy I can agree with the notion that "overloading" the roast issues wouldn't be ideal. I'd prefer the design doc repo perhaps? 10:15
pmichaud ShimmerFairy: I think "design doc repo" == perl6/specs
and I have the impression that it's no longer the active location for language design notes
ShimmerFairy FWIW I still think we need a human-readable version of the specification, though overhauling the design docs would be a huge undertaking.
pmichaud ShimmerFairy: I suspect that the human-readable version is going to be docs.perl6.org 10:16
ShimmerFairy thinks doing a literate-programming-esque thing with Pod in the test suite would be the best way to accomplish that.
pmichaud at least that's where things seem to be trending 10:17
ShimmerFairy pmichaud: I can see that, though not so much in its current form. docs.perl6.org tends to feel a bit disorganized to me, and certainly not helped by the fact that Pod support isn't where it should be yet.
pmichaud at any rate, I vote for language discussions issues to move to the perl6/roast issue tracker. 10:18
Unless perl6/specs is going to be an active part of language design, in which case it's the natural location (and where a bunch of language-specific issues have been filed already) 10:19
ShimmerFairy yeah, roast is certainly better than the 'perl6' RT queue :)
pmichaud: like I mentioned earlier, maybe a totally separate thing like rfcs.perl6.org would eventually be best, if we can't find a suitable repo to tie it to. 10:20
pmichaud ShimmerFairy: well, language discussions aren't always rfcs
ShimmerFairy true, I only picked 'rfcs' as a subdomain because that's what people were calling it :) 10:21
pmichaud the truth is that we already have a language repository, and it's called perl6/roast
I don't see any issue with adding some documentation and human-readable documents to perl6/roast 10:22
for example, jnthn++'s "language versioning" gist sounds very much to me like it should be a document in perl6/roast
ShimmerFairy sure, and eventually it'd be nice if the test files came with in-file documentation as well, at least in the tricky parts of the language :) 10:23
pmichaud FWIW, not all of the [RFC] marked RT tickets are language issues... some of them are properly Rakudo bugs. 10:27
nine pmichaud: maybe we should resurrect the idea of renaming roast?
pmichaud nine: I'd be in favor of that. 10:28
it could certainly be named "perl6" :)
although I'm sure that would confuse a *bunch* of people eventually.
"I want to download perl6. But github:perl6/perl doesn't seem to contain a compiler!" 10:29
*github:perl6/perl6
renaming 'roast' to 'lang' would certainly brighten my day. 10:30
(or to 'perl6', for that matter)
then we don't have to worry about renaming specs/ :)
jnthn quite likes lang 10:31
roast is cute but a bit too so :)
pmichaud yes, it's cute, but it's hard to explain to outsiders 10:32
timotimo that's probably why it's too cute for jnthn
pmichaud and too cute for me, too. I've never been fond of 'roast'
I liked it better when it was called "spectest". Ironically, that name is far more accurate today than it was then. :-P 10:36
ShimmerFairy
.oO(What about Perl6 Ultimate Grand Spectest, or 'pugs' for short? :P)
 10:39
pmichaud ShimmerFairy: I like the idea of inlining human-readable language spec in the test files... but even if it's not inlined, placing such human-readable documentation in the roast subdirectories seems like a nice intermediate subset
indeed, there could even be subdirectories where proposed features live (along with their tests) prior to formal adoption into the language 10:40
ShimmerFairy yeah, I think it would help keep the documentation more organized along the lines of how the tests are organized. 10:41
pmichaud s/proposed features/feature proposals/
ShimmerFairy And I'm sure the inline variation would make Knuth very happy :P
pmichaud ShimmerFairy: that, yes, but also might point out ways to better organize the tests, too.
I've long believed that roast needs a refactor... for a while I was looking for ways to refactor it to closely match the synopses. 10:42
ShimmerFairy indeed, we might see the old Snn- prefixes on directories disappear someday, esp. if/when we want to "really" distance ourselves from the design docs
pmichaud well, eventually the tests, language, etc. will probably want to reorganize themselves to closely match whatever the Perl 6 Camel Book equivalent ends up being. 10:43
ShimmerFairy Ah yes, I forget that the synopses were organized along the P5 Camel Book :)
(though obviously ours would be the Butterfly Book)
pmichaud The test suite does point out one difficulty we had with the synopses... some of those documents just ended up being too long. 10:44
They need(ed) better subdivisions.
a-n-y-w-a-y... I've thrown my hand grenade for today, I think. 10:45
ShimmerFairy However we do it, I think we can agree that expecting potential new developers of new P6 implementations to understand the specifics of the language without human-readable text would be very annoying.
pmichaud: well, I also think that it didn't help in cases where tests you're looking for could be in any of several locations, so a more feature-based organization would be nice. 10:46
nine I'd totally be for a one feature per testfile structure. Nowadays our startup time is low enough to actually consider that. 10:47
jnthn The trouble is that a lot of tests are about the interaction of features - which is often where the interesting bugs are too...
pmichaud So, my proposal (RFC): 1. Rename 'perl6/roast' to 'perl6/lang'. 2. Make the 'perl6/lang' issue tracker a place for tracking language issues, such as proposed new features. 3. Migrate jnthn++'s language versioning document into the perl6/lang repo. 10:48
4. Find any language-modification tickets in the RT ticket queue and move them to the lang issue tracker. Same for any issues left outstanding in the perl6/specs repo.
jnthn Phew, I think I've finally fixed the crappy backtraces issue with sprintf...
Thought that'd be a nice 5 minute fix...turned out not 10:49
pmichaud nicely, a language ticket can be closed when its corresponding tests have been committed to the perl6/lang repo. :)
jnthn is +1 towards pmichaud++'s proposal 10:50
ShimmerFairy jnthn: "feature interaction" is where cross-references come in! (and if all common systems supported it, symlinks!) :)
+1 for the proposal as well
jnthn haha...symlinks on Windows :P
cygx what's wrong with symlinks on windows? 10:51
jnthn oh, talking of Windows, I should try and reproduce that concurrency issue there...where all 8 virtual cores are available
pmichaud I should probably try to get some sleep. bbl 10:52
jnthn Their lack of support, traditionally... :)
pmichaud: Rest well :)
timotimo good rest :)
ShimmerFairy cygx: AIUI, if you see a symlink on windows, something's very wrong with your system :P 10:53
pmichaud
.oO( or something could be very right with your system )
cygx jnthn, ShimmerFairy: mklink /? 10:54
ShimmerFairy I wouldn't know anything about windows, I just remember hearing that it's got no symbolic links (of the ln -s variety linux-wise). 10:56
cygx cf msdn.microsoft.com/en-us/library/w...s.85).aspx
they've been around since Vista 10:57
jnthn lunch time & 10:58
(will commit that fix for printf backtraces after, it spectested ok)
nine They do exist on NTFS. But AFAIK they're not exposed in the UI
ShimmerFairy cygx: oh cool, so all we have to do is "XP not supported" and then we can (ab)use symlinks in all the places! \o/
moritz ... except on fat32 file systems 10:59
cygx nine: well, you get a small arrow on the symbol and the file type column in explorer will display .symlink
the fat32 objection is a fair point 11:00
ShimmerFairy How common is FAT32 for systems, anyway? 11:01
pmichaud ShimmerFairy: used a USB Flash drive lately? 11:02
ShimmerFairy pmichaud: oh yeah. tbf though, I'd sooner reformat any flash drive of my to an ext filesystem unless otherwise necessary :P 11:04
cygx if I may go off-topic for a bit, apparently the NTFS vesion shipped with WindowsXP actually supported symlinks, but did not provide an API 11:05
cf schinagl.priv.at/nt/hardlinkshellex...rwindowsxp
nine Since we're talking about how to find tests for a feature, maybe a human readable index would do just as well 11:07
Or even longer and more descriptive file names. We do not need to support 8.3 after all :) 11:08
cygx well, currently we have things like S16-io/basic-open.t, S16-filehandles/open.t and S32-io/open.t 11:13
ShimmerFairy nine: what are you talking about? VARIAB~7.TST is perfectly understandable! :P 11:14
mst ShimmerFairy: I WILL PEE ON EVERYTHING YOU LOVE 11:44
nine
.oO(IWILLP~1.EEO)
 11:48
jnthn back 12:21
dalek kudo/nom: dc7f279 | jnthn++ | src/core/Backtrace.pm:
We need to be smart about terminating backtraces.

The sprintf implementation is done in NQP and parsed using a grammar. On an error with the format or processing the format, we panic, which is fine. However, panic is in NQPHLL. We used detection of NQPHLL in order to trim the bottommost frames from stack traces (which are the HLL::Compiler startup infrastructure, which is not useful to show). Unfortuantely, this led to us trimming all the useful userspace lines away from the backtrace of sprintf also, meaning the user had no context for where the error came from. Sad! Also fixed it so that panic does not show up in the backtrace, which apparently made some users panic too. :-)		 12:27
moritz jnthn++ 12:28
[Coke] I am less worried about our users being confused about our super confusing ticketing systems, and more concerned about the tickets not getting addressed, regardless of what system they're in. 12:31
moritz agrees 12:32
[Coke] I'll finish documenting the state of the mess in github.com/rakudo/rakudo/wiki/rt-introduction in the next day or so since this came up again. 12:33
jnthn [Coke]: That's in part a tough one to crack in so far as it's partly a "resources" problem
The taggings have helped in that, for example, I can now easily have a list of all [CONC] tickets. That's certainly nice. 12:34
And it may help more people who know that stuff to be able to find them and work on them, but it doesn't suddenly give people a bunch more time to work on tickets. :) 12:35
If somebody fancies writing a test, rt.perl.org/Ticket/Display.html?id=129088 can now we closed with one :) 12:36
[Coke] actually starts editing that page right now.
jnthn Wonder if the lack of backtrace on sprintf also has another ticket somewhere... 12:37
[Coke] jnthn: there are a ton of sprintf tickets.
jnthn Yeah, but I don't see one for that.
[Coke] (ton==6)
jnthn: (time) right, and now we're going to spend time moving tickets around instead of answering them. :) 12:39
jnthn [Coke]: That assumes the people with the ability to do the moving also have the ability to do the answering :-) 12:40
[Coke] also. someone asks "can we change this behavior". do we really expect that user to know a priori if that's a compiler issue and not a spec issue? 12:45
trying to list all the options in the doc but stress that we'd rather get the ticket than not. 12:46
MetaZoffix jnthn: commented on rt.perl.org/Ticket/Display.html?id=129120 Slightly golfed and a few backtraces
Hm... "This is Rakudo version 2016.07.1-197-g1728139 built on MoarVM version 2016.07-17-g40948f6"... 12:49
MetaZoffix upgrades to bleed to try again
jnthn MetaZoffix: hmmm 12:50
MetaZoffix: ooh 12:51
Any chance you could test it on the Rakudo branch missing-clones?
MetaZoffix sure
[Coke] updated: github.com/rakudo/rakudo/wiki/rt-introduction
.tell pmichaud please see github.com/rakudo/rakudo/wiki/rt-introduction 12:52
yoleaux2 [Coke]: I'll pass your message to pmichaud.
[Coke] Anyone mind if I remove the section Reporting Bugs in the README.md and replace it with a link to the wiki? 12:54
moritz [Coke]: +1
MetaZoffix +1
moritz [Coke]: maybe also link/consolidate with rakudo.org/tickets/
MetaZoffix jnthn: still crashes on missing-clones: gist.github.com/zoffixznet/48cbee1...2efe9355b5 13:05
[Coke] .tell pmichaud - also ; it's not just [RFC]. See [@LARRY], [NYI], [TODO] - there's no guarantee any of these are actually rakudo bugs at this point. 13:06
yoleaux2 [Coke]: I'll pass your message to pmichaud.
[Coke] m: say 10+56+91+19 13:07
camelia rakudo-moar dc7f27: OUTPUT«176␤»
[Coke] that's the minimum count on tickets that need considering.
(i'm not saying let's not do this; I'm all for reviewing tickets because we can probably close some as we review them. It's just not easy)
updated github.com/rakudo/rakudo/wiki/rt-introduction more. 13:09
dalek kudo/nom: af4c2ef | coke++ | README.md:
replace with wiki doc
 13:10
[Coke] MetaZoffix: I deliberately did not refer to all the [] tags we have, only the ones that I felt users should be mucking with 13:11
I would not object at all if someone went through that doc and improved formatting or grammar.
jnthn MetaZoffix: OK, at lesat we know one more thing it isn't :) 13:12
MetaZoffix :D
jnthn I need to fix up those commits too, but for now am taking on the long-put-off phaser scoping/cloning fixes. 13:13
liztormato waves from Salzburg
jnthn Because they in turn sorta block my sockets string I/O fixes
And also prevent us from having a more robust protect that copes fine with control exceptions etc. 13:14
(We should really release the lock in a LEAVE)
o/ liztormato
liztormato jnthn++
jnthn Enjoy the salt mountain!
liztormato jnthn: having lunch in the same place we had after the last Austrian PW 13:15
jnthn m: for ^5 { my $x will leave { .foo } = class :: { method foo() { say 'left' } } }
camelia rakudo-moar dc7f27: OUTPUT«left␤left␤left␤left␤left␤»
jnthn liztormato: ooh :) Nice!
m: for ^5 { my $x will leave { .foo } = class :: { has $.x; method foo() { say 'left $!x' } }.new(x => $_) } 13:16
camelia rakudo-moar dc7f27: OUTPUT«left $!x␤left $!x␤left $!x␤left $!x␤left $!x␤»
jnthn d'oh :)
m: for ^5 { my $x will leave { .foo } = class :: { has $.x; method foo() { say "left $!x" } }.new(x => $_) }
camelia rakudo-moar dc7f27: OUTPUT«left 0␤left 1␤left 2␤left 3␤left 4␤»
jnthn Hmm, I wonder how that gets the right answer
m: await for for ^4 { start for ^5 { my $x will leave { .foo } = class :: { has $.x; method foo() { say "left $!x" } }.new(x => $_) } } 13:17
camelia rakudo-moar dc7f27: OUTPUT«===SORRY!===␤Word 'for' interpreted as a listop; please use 'do for' to introduce the statement control word␤at <tmp>:1␤------> await for for⏏ ^4 { start for ^5 { my $x will leave { ␤Unexpected block in infix position (two terms in a…»
jnthn m: await do for ^4 { start for ^5 { my $x will leave { .foo } = class :: { has $.x; method foo() { say "left $!x" } }.new(x => $_) } }
camelia rakudo-moar dc7f27: OUTPUT«left 0␤left 0␤left 1␤left 1␤left 2␤left 2␤left 0␤left 3␤left 1␤left 3␤left 4␤left 2␤left 3␤left 4␤left 4␤left 0␤left 1␤left 2␤left 3␤left 4␤»
[Coke] when jnthn wonders how something works, eek. 13:18
jnthn Well, I think there's probably a way go get a data race in there somewhere 13:19
liztormato On to Innsbruck&
jnthn ooh
That is probably a pretty drive :)
[Coke] adds 289 untagged tickets to the pile to review.
jnthn the Salzburg - Innsbruck train is, anyway ;) 13:20
[Coke] oh, and one [SPEC] ticket. 13:21
MetaZoffix buggable: tags 13:22
buggable MetaZoffix, Total: 1378; BUG: 542; UNTAGGED: 287; LTA: 118; NYI: 91; JVM: 62; RFC: 56; CONC: 51; SEGV: 37; TESTNEEDED: 37; REGEX: 34; UNI: 30; PERF: 26; @LARRY: 19; POD: 18; IO: 15; NATIVECALL: 14; BUILD: 11; PRECOMP: 11; TODO: 11; MATH: 7; OO: 7; TESTCOMMITTED: 7; STAR: 6; BOOTSTRAP: 5; GLR: 4; OSX: 4; REPL: 4; WEIRD: 3; CONFIGURE: 1; DOCS: 1; LIBRARY: 1; RT: 1; SITE: 1; SPEC: 1; See perl6.fail/ for details
[Coke] those numbers are looking closer. 13:26
MetaZoffix These now get auto-updated every 10 minutes (or rather... will be once I figure out why cron is not running my update script :P)
moritz environment variables. It's always those crazy environment variables. 13:28
[Coke] you fixed the bug with multiple tags, looks like.
jnthn Seems that actually I can not shave the phaser yak this side of the encoding fixes for async sockets 13:31
Which is nice 'cus it means I can get a fix in for that rather than piling up fixes that need fixes :)
moritz is your YAG-Graph directional and acyclical? :-) 13:32
erm, yak-graph, I should say
jnthn I really hope so :P
[Coke] moritz: rt.perl.org/Ticket/Display.html?id=123667 - there's no sample code here to test. 13:33
... oh, there's a sha1 buried in there. 13:34
nevermind.
moritz [Coke]: if the sha1 isn't available anymore in the repo (branch deleted, maybe), feel free to close the ticket 13:35
[Coke] it's there.
and even has a 'start' in it.
note that htmlify does have a theoretically functional start block in HEAD these days 13:36
m: s[ea] = "rea"; # RT #114388 13:40
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=114388
camelia rakudo-moar af4c2e: OUTPUT«Method 'match' not found for invocant of class 'Any'␤ in block <unit> at <tmp> line 1␤␤»
MetaZoffix m: $_ = 'meaw'; s[ea] = "rea"; 13:41
camelia ( no output )
MetaZoffix m: $_ = 'meaw'; s[ea] = "rea"; say $_
camelia rakudo-moar af4c2e: OUTPUT«mreaw␤»
[Coke] m: say (* < 7 and * > 5)(6) 13:42
camelia rakudo-moar af4c2e: OUTPUT«True␤»
[Coke] m: say (* < 7 and 7 > 5)(7)
camelia rakudo-moar af4c2e: OUTPUT«No such method 'CALL-ME' for invocant of type 'Bool'␤ in block <unit> at <tmp> line 1␤␤»
dalek kudo/async-socket-str-fixes: 6e76f7e | jnthn++ | src/core/IO/Socket/Async.pm:
Cope with empty socket reads.

There's a problem with LAST/QUIT phasers in the case that an iteration of the whenever never takes place. This wants fixing, but in our case it's safe to work around the problem.		 13:45
jnthn So, interesting problem 13:51
Suppose you receive the byte buffer corresponding to "abcd"
Previously, with a chars supply, we'd decode that packet as a unit 13:52
That's crazy broken and I've fixed it
However, I also break a test.
Why? Because if you send that, and we use the streaming coder, it spits out only "abc"
And you never see the "d" unless another packet comes through. Why? 'cus the first char we get might be a combining char. 13:53
moritz sees the problem
jnthn Fixing the test is easy: you stick a \n on the end
Control chars are always NFG terminators (just falls out of the Unicode grapheme boundary algo) 13:54
I'm personally happy to change the test (and in errata) 13:56
I think this will only be a limited practical problem for non-toy examples since:
a) It doesn't even happen if you're doing binary protocls 13:57
b) If you're doing a text-based protocol like HTTP correctly, you'll likely be doing it in binary and then handling decoding more carefully because the headers mean you have to switch encoding at some point
c) If your protocol is line-based you're fine 13:58
d) If you set an encoding like ASCII or latin-1, you can't have this problem (and I'll implement doing that shortly)
nine jnthn: is there a way to force it to stop decoding and give you that last character without modifying the input data? 13:59
jnthn Well, I guess that falls under
e) If you have knowledge that lets you safely handle things, you can use the streaming decoder API, feeding it binary buffers, and tell it to just treat what it has as The End. 14:00
(Exposing the streaming decode API is also part of what I'm doing)
Which I think is a cleaner way to have people do it than trying to inject a back channel somewhere :) 14:01
Or maybe I mis-understood what you meant?
nine I was aiming at some "close the socket and read the rest" or something 14:02
jnthn Oh, if the socket is closed then the supply is done
And the done forces it to just finish decoding and spit out what it has
Woodi socket can be closed only for sending, this don't change anything ? 14:03
nine Ok, so unless your protocol is supremely weird and the last single character signifies the end of the stream, you're fine.
jnthn Woodi: I thought close() closed it both ways, and shutdown was used if you wanted to close only one part? 14:09
*one direction I guess
So close would mean the echo client in the test could never receive the echo back 14:11
If you were really building an echo server you'd surely just take the easy path and do it with bytes too :P 14:13
Woodi I just found Winsock examples of "app" exit only when client part closes sending side, maybe totaly unrelevant here: msdn.microsoft.com/pl-pl/library/w...85%29.aspx
anyway, getting only "abc" is strange... 14:15
jnthn Indeed. On the other hand, getting a grapheme in two parts is wrong. 14:16
Either way, I should really implement shutdown :) 14:22
dalek p/expose-decode-stream: b1fb57c | jnthn++ | t/moar/05-decoder.t:
Tests for VM decoder line reading.
 15:13
TimToady I would like to point out that, despite the fact that "roast" is cute, that was not the primary motivation for picking the term; it was picked to be an unambiguous proper noun, and to serve the linguistic and cultural slot of a proper noun, and I don't think people quite realize how much you all have been using it as a proper noun 16:14
both "perl6" and "lang" are very overloaded, in contrast, and not very searchable
so I think "roast" should stay the name of the spectest repository, to give it the primacy it has, and if we want a language design repo, the correct approach is not to rename roast, but to include roast as part of a larger repo that can have any name you like 16:16
we put a lot of work into unconfusing people that roast is THE language definition 16:18
let's not dilute that
pmichaud works for me 16:21
yoleaux2 12:52Z <[Coke]> pmichaud: please see github.com/rakudo/rakudo/wiki/rt-introduction
13:06Z <[Coke]> pmichaud: - also ; it's not just [RFC]. See [@LARRY], [NYI], [TODO] - there's no guarantee any of these are actually rakudo bugs at this point.
TimToady I am also vaguely suspicious of the attempt to use cuteness as an antipattern marker; sure, "You think that's cute today" is one of our Perl 6 design principles, but that's just a palliative to one of the longstanding principles of Perl culture, that humor is *orthogonal* to professionalism. 16:27
We've been fighting that battle for a generation now.
pmichaud +1. I'm not against cuteness on its own... I still very much like "phaser", for example. :) 16:28
[Coke]: +1 to the rt-introduction document you've drafted. Yes, it means we may end up moving tickets from place to place. 16:30
dalek p/expose-decode-stream: c0b8473 | jnthn++ | t/moar/05-decoder.t:
Add tests for the byte-level Decoder ops.
 16:42
p/expose-decode-stream: 1507603 | jnthn++ | docs/ops.markdown:
Document the new streaming decode ops.
jnthn Docs :) 16:43
I'm vaguely hoping I might be able to trade in having written docs and a bunch of tests for somebody to port this stuff to the JVM backend? ;-) 16:44
dalek p: b30de50 | jnthn++ | src/vm/moar/QAST/QASTOperationsMAST.nqp:
Map decodestream ops.
 16:46
p: 39d4365 | jnthn++ | t/moar/05-decoder.t:
Stub in tests for decoder.

Bump MOAR_REVISION for streaming decode ops.
jnthn That merges the MoarVM support.
TimToady lovely vague word, "vaguely" :)
timotimo lovaguely 16:47
jnthn: "config" will be the place to put things such as "what to do with b0rked utf8" and such? 16:48
like, put replacement character or throw exception
jnthn timotimo: Maybe some day
timotimo python has that kind of option available
jnthn timotimo: But for now, it'll be whether to translate newlines or not
timotimo ah
jnthn But yeah, it's intended as a hook for those sorts of things.
timotimo good good
TimToady speaking of overloaded terms, what is this "config" of which you speak?
timotimo the third argument to nqp::decoderconfigure 16:49
since nqp doesn't actually have named args, it doesn't matter :)
er. i mean nqp ops don't have named args
jnthn Not yet, no :)
TimToady Not quite yet!
travis-ci NQP build failed. Jonathan Worthington 'Merge branch 'expose-decode-stream''
travis-ci.org/perl6/nqp/builds/156574659 github.com/perl6/nqp/compare/8c76b...a15a0adeeb
timotimo it's definitely possible to do, since we'd have all necessary info available at compile time
MoarVM op 'decoderconfigure' is unknown as a core or extension op 16:50
^- apparently forgot to bump?
jnthn d'oh
TimToady wonders if the purpose of the ' there is to indicate the headsmack...
jnthn Just maybe :)
Elfoonto travis-ci.org/perl6/nqp/builds/156574659
jnthn Or it looks like a drop of beer, which reflects that I might just have worked enough today
Elfoonto Oh, it's nqp. 16:52
Was wondering why buggable is silent :)
jnthn Yeah, I wondered that too :)
I was like "really, I have to check myself if it's a genuine fail?"
Bots make me lazy :)
Elfoonto :)
travis-ci NQP build passed. Jonathan Worthington 'Bump MOAR_REVISION for streaming decode ops.' 16:54
travis-ci.org/perl6/nqp/builds/156575856 github.com/perl6/nqp/compare/13a15...18591c9198
jnthn For the immediate fix this supports over in async sockets, I can put in some conditional stuff to make it fall back on the existing things on JVM. But then for all the other things...that's gonna get old really fast. 16:55
Such that it may make more sense just to port it.
Anyways, time for some rest, and some cooking :) 16:57
timotimo \o/
dalek p: d14d42e | (Zoffix Znet)++ | docs/release_guide.pod:
Add a blurb on what to install to get jvm
 17:04
Elfoonto NeuralAnomaly: status 17:44
NeuralAnomaly Elfoonto, [✘] Next release will be in 2 weeks and 2 days. Since last release, there are 25 new still-open tickets (4 unreviewed and 0 blockers). See perl6.fail/release/stats for details
[Coke] that url is showing tags for tickets that don't currently exist on the ticket. 17:50
e.g. for RT #129150
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129150
[Coke] (and I assume you know this, but no indication which of those tickets need review) 17:51
Elfoonto I think the tag is still there, because the system added the proper-RT-tag for "bug" when it saw "[BUG]" in the title. 17:52
So R6 is picking up "[RFC][IO]" from the subject line and "[Bug]" from the RT tag
And now I tossed it and it got removed from R6 too 17:54
And yeah, I'll add indication of which tickets need be reviewed. Right now it's visible only if you log in as release manager. 17:55
i.imgur.com/bqrxHfY.png 17:57
"review" in this instance means review by release manager to see if the ticket is a blocker or not (so on release date this is all done)
[Coke] 129131 isn't a blocker, if that helps 17:59
nor is 142
ItayAlmog Ok, i think that i have a way for a rep system on the attributes part, but how do you treat a method ? 18:29
[Coke] wasn't that chat on #perl6 ? 18:45
dalek ast: 97e3fe6 | usev6++ | S03-metaops/reduce.t:
Skip newly dying test for JVM, RT #129153
 19:54
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129153
lizmat waves from Innsbruck 20:22
masak hello, Innsbruck 20:25
lizmat masak o/ 20:26
are you coming?
MasterDuke masak: re RT #115758, in Any-iterable-methods.pm, i tried adding a new multi method max(:&by) that just called self.max(&by) 20:35
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=115758
MasterDuke this works for 'say {0 => 1, 1 => 0}.max(:by(*.value))', but breaks 'say 1 max 2 max 0' with the error message "Method 'arity' not found for invocant of class 'Callable'"
i feel like i'm missing something, but i'm not sure what 20:36
geekosaur that sounds like a change TimToady made recently 20:38
[30 22:29] <dalek> rakudo/nom: b1c444f | TimToady++ | src/core/metaops.pm:
[30 22:29] <dalek> rakudo/nom: Calling unary on reduce needs arity, not count
masak lizmat: no :( 20:39
MasterDuke geekosaur: yeah, was wondering about that. thought maybe i should reset back before his commit and then try my change
masak MasterDuke: weird. wish I could help, but I don't have any leads. 20:40
MasterDuke but i don't understand his change well enough to know if it is actually relevant, or am i just triggering on the 'arity'
masak: ah well, thanks anyway, i'll keep at it 20:41
dalek kudo/nom: 9bafd6a | lizmat++ | src/core/metaops.pm:
Make many metaops about 10% faster

By using nqp::eqaddr / nqp::not_i instead of =:= and ! This is
  because these operators are too accepting, so they cannot be optimized
  (yet, anyway).		 20:43
timotimo lizmat: neat :) 20:50
lizmat the benchmark was: my @a = ^100; for ^1000 { [-] @a }
timotimo is the improvement noticable with for ^100 X ^100 { } for example? 20:51
lizmat timotimo: lemme see 20:56
eh, that one is not covered in metaops.src, and I covered only that file right now 21:00
timotimo oops! 21:04
i thought i saw metaop_cross there
yeah, the very fir st part of the diff has METAOP_CROSS with a change in it
dinner time! afk 21:05
MasterDuke jnthn: could i bother you for a pointer re RT #115758? did you happen to catch my conv with masak and geekosaur approx an hour ago? 21:33
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=115758
dalek kudo/nom: ec9e814 | lizmat++ | src/core/metaops.pm:
Squeeze another 5% out of simple [op] @values

Rewrite the whole logic in nqp ops without need to return anything		 21:43
jnthn m: { 0 => 1, 1 => 0 }.^lookup('max').signature.say
camelia rakudo-moar 9bafd6: OUTPUT«($: | is raw)␤»
jnthn m: { 0 => 1, 1 => 0 }.^lookup('max').cando(\({ 0 => 1, 1 => 0 })).say 21:44
camelia rakudo-moar 9bafd6: OUTPUT«(max)␤»
jnthn m: { 0 => 1, 1 => 0 }.^lookup('max').cando(\({ 0 => 1, 1 => 0 }))[0].signature.say
camelia rakudo-moar 9bafd6: OUTPUT«($: *%_)␤»
jnthn grrr :)
MasterDuke yeah, i haven't been able to ^lookup or ^find_method anything that seemed helpful 21:46
jnthn Well, I was curious if we overrode it specially on Hash
But I guess not
m: { 0 => 1, 1 => 0 }.max(:by({ .WHAT.say; .value })) 21:47
camelia ( no output )
jnthn m: { 0 => 1, 1 => 0 }.pairs.max(:by({ .WHAT.say; .value }))
camelia ( no output )
jnthn huh
m: [ 0 => 1, 1 => 0 ].max(:by({ .WHAT.say; .value }))
camelia ( no output )
MasterDuke m: say { 0 => 1, 1 => 0 }.max(:by({ .WHAT.say; .value }))
camelia rakudo-moar 9bafd6: OUTPUT«1 => 0␤»
jnthn Uh, does :by work on *anything*?
m: [ 0 => 1, 1 => 0 ].max({ .WHAT.say; .value }) 21:48
camelia rakudo-moar 9bafd6: OUTPUT«(Pair)␤(Pair)␤»
jnthn m: [ 0 => 1, 1 => 0 ].pairs.max({ .WHAT.say; .value })
camelia rakudo-moar 9bafd6: OUTPUT«(Pair)␤(Pair)␤»
MasterDuke m: say max :by(*.value), { 0 => 1, 1 => 0 }
jnthn m: { 0 => 1, 1 => 0 }.pairs.max({ .WHAT.say; .value })
camelia rakudo-moar 9bafd6: OUTPUT«0 => 1␤»
rakudo-moar 9bafd6: OUTPUT«(Pair)␤(Pair)␤»
jnthn Yes but that's on the sub form
the method just takes the condition directly, not as a named arg?
m: say { 0 => 1, 1 => 0 }.max(*.value) 21:49
camelia rakudo-moar 9bafd6: OUTPUT«0 => 1␤»
jnthn That loosk right
*looks
MasterDuke there's no named arg in the method
jnthn Right 21:50
So did the RT ticket simply expect something to work that was never intended to? :)
Do we have any other places that have :by on the method form?
MasterDuke that's what i was trying to ask in my comment, but didn't really explain 21:51
Supply
jnthn Hmm
m: Supply.from-list(1..10).max(-*).tap(&say) 21:52
camelia rakudo-moar ec9e81: OUTPUT«1␤»
jnthn m: Supply.from-list(1..10).max(by => -*).tap(&say)
camelia rakudo-moar ec9e81: OUTPUT«1␤2␤3␤4␤5␤6␤7␤8␤9␤10␤»
jnthn o.O
m: Supply.from-list(1..10).max.tap(&say) 21:53
camelia rakudo-moar ec9e81: OUTPUT«1␤2␤3␤4␤5␤6␤7␤8␤9␤10␤»
jnthn What makes you think Supply takes it? :) 21:54
MasterDuke right, saw the &by, just realized it's not named
jnthn :)
I'm curious if any other non-max methods take :by though. I'd thought we were doing that on the sub forms to not confuse the transform with a list value 21:55
But on the method forms there's no such ambiguity
MasterDuke git grep 'method.*:by'
returns no results 21:56
jnthn Suggests "no" then :)
In which case the ticket is kinda asking us to add them *everywhere* since it'd be odd to do it just for max. :)
But I'm not really that inclined to.
MasterDuke the sub forms of min,max,minmax all have :&by, but those are it 21:57
but thanks for the help, i'll comment on the ticket again 22:00
jnthn Yeah, so far as I recall we went that way on the subs, and positional for the methods, and it was a deliberate choice 22:01
sleep time for me; 'night o/ 22:05
MasterDuke night

Powered by Cro and the Raku® Programming Language.

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

Thank you!