MasterDuke timotimo: was that MVM_dump_backtrace output from that coerce_ni at all useful? 00:14
timotimo it confirmed my hypothesis 00:17
but we're now interested in the code that gens the code that runs there
MasterDuke where is that code? 00:18
timotimo i expect something in the QASTCompilerMAST is to blame 00:19
MasterDuke oof, not the easiest stuff to grok 00:20
timotimo yup 00:21
Geth roast: 6e446c4d68 | usev6++ | S16-io/prompt.t
[JVM] Fudge newly added test for no-arg prompt
 05:20
[Tux] This is Rakudo version 2017.05-32-g379ef6f1d built on MoarVM version 2017.05-9-g37460c7a 06:20
csv-ip5xs 2.473
test 12.766
test-t 4.235 - 4.244
csv-parser 13.246
lizmat Files=1194, Tests=58717, 212 wallclock secs (12.62 usr 4.90 sys + 1252.25 cusr 119.67 csys = 1389.44 CPU) 07:32
Geth rakudo/nom: 1283599c9a | (Elizabeth Mattijsen)++ | CREDITS
Update my email address
 08:41
nqp: ac7f21ab86 | (Jonathan Worthington)++ | 3 files
Implement line reading in steaming decoder on JVM.
 09:27
nqp: 19fe0e62a0 | (Jonathan Worthington)++ | 3 files
Implement decoderbytesavailable on JVM.
 09:49
nqp: feaefe66cf | (Jonathan Worthington)++ | 3 files
Implement decodertakebytes on JVM.

Thus fully passing 05-decoder.t on JVM.		 10:11
nqp: 23a1a12aa9 | (Jonathan Worthington)++ | t/jvm/05-decoder.t
Correct test plan.
 10:12
rakudo/refactor-socket-encoding: e58f591c01 | (Jonathan Worthington)++ | src/core/IO/Socket/INET.pm
Remove leftover from JVM workaround.
 10:42
nine Something wierd is going on with the MANIFEST detection in modules.perl6.org/todo/nine 10:43
All those dists in fact have a MANIFEST and the todo even showed that about an hour ago. Except for Inline::Python which ironically was the first of these to even get a MANIFEST 10:44
jnthn Phew, just 4 failing tests in IO-Socket-INET.t to go on JVM, but otherwise the other sync socket tests in that file and in other files seem to be passing. 10:45
Geth nqp: d260917d59 | (Jonathan Worthington)++ | src/vm/jvm/runtime/org/perl6/nqp/sixmodel/reprs/DecoderInstance.java
Initialize decoded up front.

We'll almost always end up with it, and it saves null checks (which can be easily forgotten - and *were* forgotten - elsewhere).		 10:46
jnthn lunch; bbiab 10:59
jnthn back 11:56
Geth nqp: dbc1484c55 | (Jonathan Worthington)++ | 2 files
Correct an off-by-one in JVM streaming decoder.

This caused us to fail to return the second-to-last char even when it was clearly safe to do so.		 12:32
jnthn Hurrah, with that the socket tests all pass on JVM too 12:33
nine \o/
Zoffix m: my @a = <a b c d e>; dd @a.pick(*-30) 12:34
camelia Coercion to UInt out of range. Is: -25, should be in 0..^Inf
in block <unit> at <tmp> line 1

Actually thrown at:
in block <unit> at <tmp> line 1
Zoffix IMO that should just return an empty list; 'cause the whole point of using `*` is that I don't know what size my list is and I want to pick N-x items
jnthn So in theory that's the socket re-work to not use libuv and to coordinate the decoding in Rakudo sorted out 12:35
Zoffix goes with .pick(*/3)
jnthn++ sweet
jnthn In practice, I'd really like to do a spectest with the Moar/Rakudo branch on OSX before merging 12:36
Should perhaps find a module that uses sockets to try out also
Zoffix m: my @a = <a b c d e f g e h>; @a[(^*).pick: */3] .= uc; dd @a 12:38
camelia Cannot resolve caller pick(Range: WhateverCode); none of these signatures match:
(Range $: *%_)
(Range $: Whatever, *%_)
(Range $: Cool $todo, *%_)
in block <unit> at <tmp> line 1
Zoffix :(
m: my @a = <a b c d e f g e h>; @a[(^*).list.pick: */3] .= uc; dd @a
camelia Array @a = ["a", "b", Any, "d", "E G C", "f", Any, "e", "h"]
Zoffix what are those Anys? :/
Ah... I guess this use is not supported 'cause I see it joined them all up in 1 string 12:39
jnthn I think you're maybe expecting more * currying than is happening
Or not 12:40
moritz didn't even know of .pick(&callable)
Zoffix I'm attempting to change 1/3rd random elements in the array to the value of their .method call
jnthn I'm confused what you wanted so it's perhaps better written another way :P
Zoffix Or more specifically: I have an array of IO::Paths, I want a part of them to be IO::Handles, so I want to call .open on them (and put the handle where IO::Path used to be, in the array) 12:41
m: my @a = <a b c d e f g e h>; @a[$_] .= uc for @a.keys.pick: */3; dd @a 12:43
camelia Array @a = ["A", "b", "c", "d", "E", "F", "g", "e", "h"]
Zoffix that does the job, I guess
jnthn Yeah, I was just realizing, the .= uc was not being distributed :)
[Coke] Having just sent out the RFP for this round of grants, I wonder how Zoffix++ and samcv++ are doing on the existing ones. 12:44
cono jnthn: did you have a chance to look into my PR to your branch? :) 12:47
jnthn cono: Not yet, was busily fighting JVM/NIO so far today
Though I think I've done with that :) 12:48
Well yay, LWP::Simple tests are all happy with my changes
jnthn would still kinda like an OSX test run... 12:51
[Coke] can try that. 12:52
jnthn: what/where/huh? 12:53
cono moarvm branch: sync-socket-no-uv rakudo: refactor-socket-encoding
Zoffix [Coke]: I have all IO routines in an excel file marking which I code-reviewed, documented (or checked documention is present and valid), and tested (or checked the tests are present and sufficient). The current number of completed routines is 84%. I'm currently working on IO::CatHandle and hoping to finish it before the long weekend. After that, I need to finish the remaining routines and The Definitive IO 12:54
Guide. Then I'll need to regenerate data on perl6.wtf (and if my spreadsheet is accurate, all of the routines would then have coverage). I'm hoping to complete that plus the final grant report by end of the upcoming Monday, May 29th. Looking at the completeness criteria in the original grant prosal, there is item "the IO Action Plan document and it will be fully implemented". However, there are two items
that aren't implemented (yet) that I'm hoping is OK for completeness of the grant: (1) Handle's closed status: the Action Plan proposed a role mixin, but it was found to be a poor solution, so the alernative is to make MoarVM do better errors for reads on non-IO stuff (on Nil). (2) Change nqp::stat to accept more than 1 stat info bit to fetch, so that we get some perf improvement in methods like .rwx that
do 5 calls instead of 1. The reason both of those aren't yet implemented is because I don't know moarvm that well. So I *will* implement those things at some point in the future, but I just feel like me trying to learn and rush these to complete the grant might not produce the greatest of work.
So in summation, if the last two points are OK, as far as grant completion goes, then I'll have my final report by end of Monday, May, 29th (EST) and will be done with the grant. 12:55
[Coke] cono, jnthn, building now.
Zoffix * long weekend (I mean this weekend, including Monday; all my weekends this year have been long) 12:56
[Coke] jnthn: MoarVM op 'asyncwritestr' is unknown as a core or extension op
on that rakudo branch, I rm -rf'd ./install and ran: perl Configure.pl --gen-moar=sync-socket-no-uv --gen-nqp 12:57
jnthn Try --gen-nqp=master 12:58
[Coke] You asked me to build sync-socket-no-uv, but 2017.04-78-g1aa523ed is not new enough to satisfy version 2017.05 12:59
let me try this by hand, I guess.
jnthn arrrgh 13:00
Yeah :/
moritz merge master into sync-socket-no-uv?
jnthn Urgh
Then the history looks a mess 13:01
But yeah, [Coke]++ could do that locally :)
[Coke] I can do this, just requires one more cup of coffee.
jnthn I guess actually I could just merge the MoarVM branch :) 13:02
Because we have all of this _VERSION stuff to keep anyone doing normal builds from seeing it anyway :) 13:03
jnthn does that
cono you can rebase to new master
it will clean up history
jnthn I could but if others have it checked out that won't go well ;)
(For them :)) 13:04
I've done it now anyway
(merged the MoarVM branch
)
cono np, I can deal with it :)
jnthn [Coke]: So now what to test is MoarVM master/NQP master/Rakudo refactor-socket-encoding
[Coke] returns from coffee to find easy instructions. 13:08
Use of uninitialized value $moar_version_output in pattern match (m//) at tools/lib/NQP/Configure.pm line 300. 13:09
(it's going fine, just saw that early on)
jnthn Odd...though miles away from anything I've touched... 13:11
[Coke] make test is fine, firing up stresstest. 13:12
jnthn MasterDuke++ # adding TEST_JOBS support to nqp's make test 13:14
They run in like 2s here now :)
Zoffix my $moar_version_output = qx{ $moar_exe --version }; 13:15
Looks like moar --version is busted?
(to produce that varning)
jnthn weird
moar --version
This is MoarVM version 2017.05-20-g9f9a2a0 built with JIT support
On HEAD
Zoffix or the logic fetching it
nine Hmm...weiss ned, ob I mi ja sagen trau. Im Endspurt bei der Umstellung auf CMS 3000 warn wir sehr nachlaessig mit Tests schreiben.
Zoffix github.com/perl6/nqp/blob/master/t...#L283-L286
nine Is there a wrong window contest as well? 13:16
Zoffix Ya! Ya! Shprehen ze dauch!
jnthn Nein!
[Coke]: I expect some test fails 'cus that branch is behind master; main thing I'm looking for is if any socket ones fail :) 13:17
[Coke] jnthn: gist.github.com/coke/11cf1d9ae5795...a720135038 13:21
jnthn yah, that's exact same set as I have on Linux (and all due to fixes in nom that my branch doesn't have) 13:22
Excellent. :D
[Coke]++
Geth nqp: 6f0b5b46a0 | (Jonathan Worthington)++ | tools/build/MOAR_REVISION
Bump MOAR_REVISION.

Brings socket changes to no longer use libuv.		 13:26
Ā¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...0-g9f9a2a0
cono jnthn: I have this issue when try to compile MoarVM: ./libmoar.so: undefined reference to `MVM_coerce_s_n' 13:27
jnthn cono: Did you re-Configure?
(That was added in a new file, so maybe you've got an outdated Makefile)
cono nah
thanks
Geth rakudo/nom: 13 commits pushed by (Jonathan Worthington)++
review: github.com/rakudo/rakudo/compare/1...8ee383e374		 13:28
rakudo/nom: 6f202fbe9b | (Jonathan Worthington)++ | tools/build/NQP_REVISION
Bump NQP_REVISION.

  * Gets complete JVM support for the streaming decode API, which gets
   synchronous sockets back to passing all of their tests after the
   recent refactors.
  * Brings in MoarVM changes that mean libuv is no longer used for
   synchronous sockets. This in turn means that the exceptions and
   crashes when trying to use handles across different threads are
   now cleared up (for example, accepting a handle on one thread and
   handing it off to another to communicate).		 13:30
Ā¦ rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....3-g6f0b5b4
brrt jnthn++ 13:32
jnthn Now it "just" needs doing for ordinary file handles 13:33
And procs
:P
[Coke] jnthn++ 13:36
cono jnthn: why you have closed my pr ? :( if I push changes it just updates it 13:42
anyway, opened new one: github.com/MoarVM/MoarVM/pull/602 13:43
reworked to simple int/SOCKET logic
Zoffix \o/
jnthn cono: I didn't close it?
I left review on it
Or at least, that's all I thought I did 13:44
Hm, I can't find an RT for the sockets/threads thing
lizmat jnthn: looked closed to me
cono but new IO-Socket-INET.t still segfaults to me :( zsh: segmentation fault perl6 ./IO-Socket-INET.t 13:47
after 9 successfull tests :D
jnthn huh, how'd I end closing it...d'oh
It even said I did it but I've no memory of doing so ;)
Zoffix
.oO( Multiple PR Disorder... )
 13:48
cono :)
nine Mei Anmerkung war eigentlich: prepare, execute, fetchrow_hashref, fetchrow_hashref, fetchrow_hashref, ... 13:49
Zoffix heh
nine thinks he should just go home and stay away from any keyboards for the day
Zoffix war? prepare? execute? 13:50
Zoffix moves further away
:)
brrt lol 13:52
jnthn star: gist.github.com/jnthn/6f6168ad424a...5b7dd007e1 13:53
camelia (timeout)1..5
jnthn m: gist.github.com/jnthn/6f6168ad424a...5b7dd007e1
camelia (timeout)1..5 13:54
jnthn huh 13:55
Zoffix forcees IO::CatHandle being slower than IO::ArgFiles :|
jnthn m: say IO::Socket::INET.new
camelia IO::Socket::INET is disallowed in restricted setting
in sub restricted at src/RESTRICTED.setting line 1
in method new at src/RESTRICTED.setting line 32
in block <unit> at <tmp> line 1
jnthn arse
c: HEAD say IO::Socket::INET.new
committable6 jnthn, Ā¦HEAD(1283599): Ā«IO::Socket::INET is disallowed in restricted settingā¤ in sub restricted at src/RESTRICTED.setting line 1ā¤ in method new at src/RESTRICTED.setting line 32ā¤ in block <unit> at /tmp/E7Jt0KzBoQ line 1ā¤ Ā«exit code = 1Ā»Ā»
Zoffix heh
jnthn So many bots so useless for checking my test :P
Zoffix :D
jnthn Do I really have to build an older revision again? :/ 13:56
Zoffix I know there's... a secret way to bisect without restricted mode
Dunno about executing a particular commit... MasterDuke AlexDaniela?
Dunno about executing a particular commit... MasterDuke AlexDaniel?
Oh! 13:57
specify same start and end commits
1 sec
Oh, I think the secret way is disabled now. I'm getting no response. 13:58
jnthn :(
jnthn builds 2017.05 13:59
yup, it fails there 14:02
Geth roast: a5a46acfd4 | (Jonathan Worthington)++ | S32-io/socket-accept-and-working-threads.t
Cover accept on one thread and recv on another.

Which didn't work prior to the latest fixes.		 14:03
Zoffix m: class Foo { method x ($ = 42) {} }; class Bar { has $.foo = Foo.new; method x(|c) { $!foo.x: |c } }; my $m = Bar.new; for ^500_000 { $ = $m.x }; say now - INIT now 14:11
camelia 0.99089139
Zoffix m: class Foo { method x ($ = 42) {} }; class Bar { has $.foo = Foo.new; method x() { $!foo.x } }; my $m = Bar.new; for ^500_000 { $ = $m.x }; say now - INIT now
camelia 0.4294206
Zoffix ^ I'm gonna NOT support custom IO::Handles that take non-standard args in IO::CatHandle. It's just too expensive to shuttle "rest of args" around to all the methods
m: await start get 14:18
camelia ( no output )
Zoffix \o/
jnthn++
Oh wait, there's no socket involved there...
m: await start get
camelia ( no output )
Zoffix m: await start get
camelia ( no output )
Zoffix m: await start get 14:19
camelia ( no output )
Zoffix vOv works :D
jnthn Maybe it's something to do with the bot
$ perl6-m -e 'await start get'
Tried to get the result of a broken Promise
in block <unit> at -e line 1
Original exception:
Tried to read() from an IO handle outside its originating thread
Zoffix Ah oK :)
jnthn Yeah, I'm about to start on IO::Handle next I *think*
lizmat .tell masak looks like Mixy semantics on (<) and (<=) are tricky, e.g. would (a => -1).Mix (<) ().Mix be True or False? 14:20
yoleaux lizmat: I'll pass your message to masak.
jnthn Hm, IO::ArgFiles inherits from IO::Handle but seems not to use any of its state? 14:22
lizmat .tell could be False because key "a" is missing on right hand side Mix, could be True if missing keys are considered to have value 0
yoleaux lizmat: I'll pass your message to could.
lizmat .tell masak could be False because key "a" is missing on right hand side Mix, could be True if missing keys are considered to have value 0
yoleaux lizmat: I'll pass your message to masak.
jnthn Zoffix: Why does IO::ArgFiles inherit from IO::Handle? 14:23
Zoffix jnthn: in my design? IO::ArgFiles is IO::CatHandle (for backwards compatibility). IO::CatHandle is IO::Handle because it can be basically used anywhere IO::Handle can be used. ATM only write methods aren't defined as I'm unsure what they should do 14:24
jnthn And tell and seek and native-descriptor... 14:25
Zoffix .tell and .seek do it on currently active handle
yoleaux Zoffix: I'll pass your message to and.
Zoffix stupid bot
and native descriptor too
jnthn Zoffix: In your local changes?
Zoffix jnthn: in the finished product, they would yeah. I'm still hacking on it 14:26
jnthn OK
It's just that IO::Handle is chock full of stuff that works against $!PIO
And then absolutely none of it is used in ArgFiles
Zoffix each, but all the methods are the same
s/each/yeah/;
jnthn This is good in so far as I can refactor IO::Handle without hurting anything 14:27
Uh, anything in ArgFiles
It just looks a tad odd
Almost as if IO::Handle wanted to be a role or something
lizmat
.oO( I think I can hear Zoffix starting to scream now )
 14:28
jnthn :)
Mostly I'm just scoping out the likely impact of the changes I'm about to do :)
It looks very much like the two things that subclass IO::Handle aren't messing with its guts 14:29
Zoffix more or less yeah. Like Pipe uses $!PIO, but I'm guessing it stays 14:30
jnthn So in theory, if nothing *else* pokes into IO::Handle, this shouldn't be too bad
Yes
What's going to happen is:
IO::Handle will gain a Decoder instance
We'll read bytes from the VM and shove them into it 14:31
Then all char I/O will pull from the decoder
The end result being that all I/O at VM level will be binary 14:32
Zoffix Will that make stuff slower?
jnthn Greatly simplifying the move away from libuv, and enabling us to add userspace encodings in the future
Maybe yes in the immediate, but not automatically
At the moment we have to do a mutex acquisition every single time we call down to the VM I/O layer
Zoffix OK.
jnthn The Decoder does a far cheaper check to make sure it's not being abused. 14:33
And if we're reading a line at a time, then we'll most of the time only need to touch the decoder
Not the handle
So input I think should either break even or come out faster 14:34
Zoffix Sweet
jnthn Output - we need to call encode and then pass stuff on VM-wards 14:35
I worry a tad more about this performance wise
We could of course add buffering and batch it if needed 14:36
(for files, not for consoles) 14:37
Anyways, making a branch, digging in :) 14:39
Zoffix \o/ 14:40
cono jnthn: If I push bump of tools/build/MOAR_REVISION, would it be possible to merge this PR in the future w/o this file ? 14:44
jnthn cono: If it's not in the PR then somebody will have to do it manually before they merge it anyway 14:45
Since the op doesn't exist in an earlier version of MoarVM
cono ah, looks like build with master got a success 14:46
jnthn Oh, the PR builds against MoarVM master?
cono it does 3 builds: travis-ci.org/perl6/nqp/builds/235...tification 14:47
jnthn oh, right
Yeah
So MOAR_REVISION is needed for the --gen-moar one to pass
cono yeah, but it will be complicated to merge this PR afterwards
to omit changes to MOAR_REVISION 14:48
jnthn Why woulod we need to do that?
*would
The MOAR_REVISION change is a required part of the PR
Without that we can't merge it without manual intervention
Zoffix cono: MOAR_REVISION tells it which version of MoarVM to build. So your PR needs a newer version, hence you'd include the version bump in your PR
and the content of that file is just `git describe` in MoarVM's repo for the version that you need 14:49
cono I'm a bit confused, so is it fine if I put particular revision? I thought only tags or branches should be placed there 14:50
jnthn No, a `git describe` output is fine in there
It's only when we cut a release that it should be a tag
But between releases it's fine
cono in this case you should accept PRs in proper order to not spoil MOAR_REVISION 14:51
jnthn Or we have to manually merge. In reality, it's only a small percentage of PRs that need to do version bumps so it's not really a problem. 14:52
Zoffix There probably will be a merge conflict 'cause there was a bump github.com/perl6/nqp/commit/6f0b5b...8d73bba5a8 14:54
^_^
oh cool, github lets you resolve them on the web now 14:55
cono yea :)
just tried :)
k, travis run on the go
Zoffix cono: I sent you an invite to perl6 github org; that gives you a commit bit to most of perl6/ repos, include perl6/npq. If you find yourself interested in rakudo/rakudo commit bit, it's a bit more involved as you need to sign the CLA ( details github.com/rakudo/rakudo/blob/nom/...on-process ) and for MoarVM... I don't know the process :) 14:59
cono thanks will read :) 15:01
Geth rakudo/refactor-handle-encoding: fba01e38d8 | (Jonathan Worthington)++ | src/core/IO/Handle.pm
Simplify some forms of print/put/say.

These cases all do some computation (evaluating a format or looping) to produce the string to output. Also have various forms produce a single concatenated string rather than making multiple calls down to the I/O layer. This will avoid multiple calls to the encoder.		 15:08
Zoffix "Stage parse : 184.415" sheesh, this box is fun :| 15:18
jnthn Ouch
Zoffix 32-bit
Geth rakudo/refactor-handle-encoding: b1a3f118ea | (Jonathan Worthington)++ | src/core/IO/Handle.pm
Eliminate nqp::printfh use in IO::Handle.

It goes away in favor of explicit calls to .encode and then calling nqp::writefh. This is, without further optimization effort, probably a slowdown, having glanced Str.encode. It's not enough to make any difference to spectest time, however, so it's likely not all that dramatic. This does regress one spectest, which seems to be trying to do string I/O with the encoding 'bin'.		 15:19
jnthn my $fh = open PATH, :rw, :bin, :enc<ASCII>; 15:20
That somehow ends up with $!encoding containing bin
lizmat feels to me that should be an error 15:21
Geth rakudo/newer-cat-handle: 1b8535ef4c | (Zoffix Znet)++ | src/core/IO/CatHandle.pm
Remove unneeded code
rakudo/newer-cat-handle: 8b2133cc6d | (Zoffix Znet)++ | 3 files
Implement IO::CatHandle.lines

and fix all the compilation errors
roast/newer-cat-handle: fe84c4ac4f | (Zoffix Znet)++ | S32-io/io-cathandle.t
Write IO::CatHandle.lines tests
 15:22
jnthn Should you be allowed to .print/.put/.say if you opened with :bin?
Zoffix IMO no
jnthn The only thing I can at present see that is actually impacted by :bin is the default kind of Supply you get when doing .Supply on the handle
Zoffix " jnthn ā”‚ That somehow ends up with $!encoding containing bin" 15:23
jnthn: that's because opening in `bin` mode sets .encoding to 'bin'
Or changing .encoding attribute to 'bin' puts the handle in binary mode.
and :bin wins over :enc arg 15:24
jnthn Right
With my latest changes we now end up calling $str.encode('bin') as a result :)
Which blows up :)
Zoffix heh
jnthn Note that in the entire spectest suite we do this in precisely *one* place
And it's incidental
Rather than the subject of the test 15:25
Zoffix That .encoding is set to 'bin'?
jnthn The test is S32-io/seek.t
It uses .print once at the start of the test
To put some stuff in the file
All other stuff it does is .read/.seek/.tell
Part of the reason I'm asking this is because it also impacts the changes to *input* 15:26
Zoffix That's just an error in the test file 15:27
jnthn We support mixed mode input/output
That is to say, you can open a file as :enc<ascii> for example
And .get
But it's also possible to .read
Zoffix Yeah
jnthn This is really "fun"
Because we have to feed the bytes into the streaming decoder 15:28
And obtain them from it
And it needs to keep track of how much it ate
So it can give the right bytes back
Which is a bit of bookkeeping
Zoffix IMO it shouldn't be possible to also .read. You want binary stuff, put the handle in binary mode.
jnthn Well, that case isn't the problem
We already support it 15:29
If you don't know enough about normalization buffers you can screw yourself but, well, tough
That *is* a problem
Is that if we let .get/.lines work in :bin mode too then we have to shove everything through the decode API
Even though we never actually decode
ugexe it can be "useful" for things like http 1.*, where you know the encoding of the first chunk (headers) but not the following (body / chunked body) 15:30
jnthn Which means a bunch of memory copies
ugexe: Yes, and that case is safe because newlines are normalization terminators, so you won't end up in bother :)
I'm not proposing to change the ability to read/write on handles that are opened without :bin, anyways 15:31
I'm asking whether we should allow any kind of char-level I/O when you *did* open with :bin
Because if the answer is "no" then we can have much faster binary I/O
Well, input at least
Output doesn't care :) 15:32
Geth roast: a0c5ef2cfc | (Zoffix Znet)++ | S32-io/seek.t
Fix broken seek test setup

The setup tries to open the file in both binary and text mode and then
  .print()s test data to it.
Fix by using the Test::Util helper to create the test file. This test file is not part of 6.c-errata		 15:33
Zoffix jnthn: ^ that should fix the fallout you mentioned
jnthn spectests with that :)
Zoffix++
My feeling is that :bin should set a boolean 15:34
Not set $!encoding
Because we can test a boolean quickly
Geth rakudo/nom: 0cb4df4422 | (Elizabeth Mattijsen)++ | src/core/set_operators.pm
Make Map (<=) Map about 15x faster

Based on a 25/26 element hash		 15:35
jnthn To say "no, you're in binary mode" if you try to do stuff you shouldn't on a binary handle
Rather than having to do iseq_s($!encoding, 'bin')
spectest clean again 15:36
Zoffix \o/
jnthn Haivng found we only broke one spectest (now fixed) if we did print/say/put on a :bin file, just thrown in a check if we do get/lines/words/getc/readchars on a bin handle 15:40
To have some data on taht
*that
No failures 15:42
So it looks like we're clear to rule that on a :bin handle you can only read/write 15:44
Zoffix and .spurt
and .slurp and .Slupply 15:45
jnthn Why?
Zoffix They support bin modes
jnthn Oh 15:46
You were saying other things that should be allowed :)
Zoffix Yeah :)
jnthn Yeah, I wasn't even considering the ones that are already clearly defiend as working on both by virtue of a flag :)
They of course should be :)
Geth rakudo/nom: f6f54dcfe6 | (Elizabeth Mattijsen)++ | src/core/set_operators.pm
Make Map (<) Map about 15x faster

Based on a 25/26 element hash
jnthn Alrighty, then I'll probably go that way 15:47
It occurs to me that nqp::isconcrete($!decoder) is also another way to detect non-binary 15:48
(Where $!decoder will soon be added, and will hold the decoder)
Figure it's probably time to go and make some dinner, so will carry on with this tomorrow :) 15:51
Zoffix Looks like out of everyone committing today, I'm having the most unproductive time :) Having chasing compilation errors for the past hour :} 16:03
ZofBot: I feel sad now 16:04
ZofBot Zoffix, jib" file is determined as follows: <prefix>-<package-name>-<version>-<authority>
lizmat Zoffix: I have support for Baggy semantics for (<) and (<=) ready, but they break some Mixy (<) Mixy tests 16:07
hence my question to masak
so I'm not feeling particularly productive today either 16:08
Zoffix :) 16:09
Geth rakudo/nom: d3783d541c | (Elizabeth Mattijsen)++ | src/core/set_operators.pm
We need to decont() to reap benefits of nqp::eqaddr

Also comment on why we don't need to handle object hashes seperately		 16:12
rakudo/newer-cat-handle: 04eeaeedcc | (Zoffix Znet)++ | src/core/IO/CatHandle.pm
Make IO::CatHandle.lines pass its tests
 16:16
Zoffix *phew* finally. Should be smooth saling for the rest of the cathandle
Zoffix &
ugexe famous last words 16:59
Zoffix :) 17:04
timotimo wtmp begins Mon Feb 1 03:55:37 2016 17:21
cygx Zoffix: re .seek/.tell, in principle they need not throw if the bytes stuck in the decoding buffers are properly taken into account 17:22
if they are not, it's probably better to throw
Zoffix ok 17:23
timotimo: what's wtmp? 17:24
Zoffix is experiencing Perl6geist
Geth rakudo/nom: 8fe858d665 | (Elizabeth Mattijsen)++ | src/core/Baggy.pm
Oops, forgot to remove code that's no longer needed

This should have happened in accf51985006df755e
rakudo/nom: d92e71dec4 | (Elizabeth Mattijsen)++ | src/core/set_operators.pm
Give (<) Baggy and Mixy semantics for Bags/Mixes

This oddly enough does *not* break any spectests, even though before only Set semantics were used. Given A and B:
For Bags: a key in A must exist in B with val(A) < val(B) For Mixes:
   - matching keys in A and B should have val(A) < val(B)
   - missing keys in A should have val(B) > 0
   - missing keys in B should have val(A) < 0
lizmat m: say (a => -1).Mix (<) mix() # will become True 17:25
camelia False
Zoffix I accidentally used `dd` to dump a var in Perl 5 code... and to my surprise there *is* a `&dd` sub that converts the stuff into `<dd>...</dd>` markup, but it's coming from nowhere. Not the 1 module I'm `use`ing nor anywhere else in the code
I think this website is trying to tell me it wants me to rewrite it in Perl 6 :}
lizmat Zoffix: wouldn't be the first time people copied a good idea from Perl 6 :-) 17:26
timotimo Zoffix: that's the output of "last words" on the console ;)
Zoffix wtmp begins Tue May 2 08:11:28 2017
lizmat m: say mix() (<) (a => -1).Mix # will become False
camelia False
Zoffix timotimo: hah 17:27
lizmat: looks kinda crazy :i
lizmat m: say mix().Set (<) (a => -1).Mix.Set
camelia False
lizmat m: say set() (<) <a>.Set 17:28
camelia False
lizmat huh ?
Zoffix I see
lizmat that *should* be true in my book ?
m: say SetHash.new (<) <a>.Set
Zoffix I would've figured the "Bag is a degenerate Mix and Set is a degenerate Bag" thing to be applied to all the operators
camelia False
lizmat Zoffix: that's what I'm working on :-) 17:29
Zoffix lizmat: hm, but then to me (a => -1).Mix is a mix with 1 element and mix() is a mix with 0 elements, so it's obviously a subset of the first mix. 17:30
like... the subsettiness isn't concerned with weights
oh
lizmat: never mind :) it clicked
lizmat well, if you have Baggy semantics, the weights *are* concerned
and a missing key is supposed to be 0
Zoffix yeah, now I get it :)
Bisectable points to for the set() (<) <a>.Set thing: github.com/rakudo/rakudo/commit/43...a2855c11dc 17:32
lizmat yeah, found it :-) 17:34
Geth rakudo/nom: e6506bfdd7 | (Elizabeth Mattijsen)++ | src/core/set_operators.pm
Fix behaviour of set() (<) X.Set

The empty set is always a proper subset of any non-empty Set.		 17:49
rakudo/nom: c9c1ee3dcc | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
Introducing R:Q.MIX-ALL-(POSITIVE|NEGATIVE)

Abstracting some functionality from Mixy (<) Mixy to be used in Mixy (<=) Mixy		 18:16
rakudo/nom: dd6d6cc477 | (Elizabeth Mattijsen)++ | src/core/set_operators.pm
Use new R:Q.MIX-ALL-(POSITIVE|NEGATIVE)
cono Zoffix: will you be able to merge github.com/perl6/nqp/pull/360 and github.com/rakudo/rakudo/pull/1086 ? 18:23
Zoffix cono: unsure if you know of it... but did you run spectest? TEST_JOBS=8 make spectest (where 8 is $number-of-cores-on-your-processor *1.3) 18:24
I recall mentions of segfaults somewhere. Is that something new added by the PRs or was that in there already? 18:25
cono it doesn't work for me :( most of them rely on $*DISTRO.name instead of $*VM.osname and on my linux it gives "gentoo"
Zoffix: its only for new tests: github.com/perl6/roast/pull/270 18:26
I'm not asking to merge it yet :)
Zoffix Ah, OK
m: dd [ $*DISTRO.name, $*VM.osname ]
camelia ["opensuse", "linux"]
Zoffix ok, 1 sec. Lemme build and spectest 18:27
cono look into current IO-Socket-INET.t
there are distro.name
and there are no opensuse
only ubuntu, linux
imho it should be rewrited to $VM.osnmae
Geth nqp/master: 5 commits pushed by cono++, (Jonathan Worthington)++ 18:28
Ā¦ nqp/master: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...-gd86a35b6
Zoffix yeah, we got VM.osname only like this month 18:30
c: bisect say VM.osname 18:31
committable6 Zoffix, Ā¦bisect: Ā«Cannot find this revision (did you mean ā€œ6ccecb1ā€?)Ā»
Zoffix bisect: say VM.osname
bisectable6 Zoffix, Bisecting by exit code (old=2015.12 new=1283599). Old exit code: 1
Zoffix notices bisectable6 got a lot slower :/
star: VM.osname 18:32
camelia No such method 'osname' for invocant of type 'VM'
in block <unit> at <tmp> line 1
cono $*VM i guess
Zoffix Oh well
m: say VM.osname
lizmat m: say $VM.config<osname>
camelia linux
5===SORRY!5=== Error while compiling <tmp>
Variable '$VM' is not declared
at <tmp>:1
------> 3say 7ā5$VM.config<osname>
lizmat m: say $*VM.config<osname>
camelia linux
lizmat j: say $*VM.properties<os.name> 18:33
camelia Linux
lizmat yuck
Zoffix heh
j: say VM.osname
camelia Method 'osname' not found for invocant of class 'VM'
in block <unit> at <tmp> line 1
cono j: say $*VM.osname
camelia Method 'osname' not found for invocant of class 'VM'
in block <unit> at <tmp> line 1
lizmat huh?
cono m: say $*VM.osname
camelia linux
Zoffix it's still stuck on Jan 4th commit 18:34
lizmat yup, looks like :-(
Zoffix .tell nine seems camelia's JVM rakudo is stuck again. Uses Jan 3rd commit
yoleaux Zoffix: I'll pass your message to nine.
Zoffix uhh "No registered operation handler for 'getport'" 18:35
timotimo insufficiently new nqp 18:36
Zoffix ah, ok, I expected it to build master since I manually cloned it
timotimo did we forget to bump the version requirement? 18:37
Geth rakudo/nom: b1d83f9d69 | (Elizabeth Mattijsen)++ | src/core/set_operators.pm
Give (<=) Baggy and Mixy semantics for Bags/Mixes

This oddly enough does *not* break any spectests, even though before only Set semantics were used. Given A and B:
For Bags: a key in A must exist in B with val(A) <= val(B) For Mixes:
   - matching keys in A and B should have val(A) <= val(B)
   - missing keys in A should have val(B) >= 0
   - missing keys in B should have val(A) <= 0
   - since we don't have 0 values in Mixes, the <= can be <
cono timotimo: do we have version requirement for nqp too ?
Zoffix timotimo: no, it's the fork
cono: yeah, in tools/build/NQP_REVISION in rakudo
cono heh, should I add it to my PR ? 18:38
I mean to this one: github.com/rakudo/rakudo/pull/1086
Zoffix Nah, I'll bump it while your fork compiles and stresstests :)
cono thanks a lot :)
lizmat Please note that Baggy/Mixy semantics for (<) and (<=) and friends can be easily moved to 6.d should that be necessary 18:40
Zoffix lizmat: do they break 6.c tests?
lizmat it's just adding a number of candidates to (<) and (<=) 18:41
6.c hmmm...
it doesn't break anything in roast/master
Zoffix Ah, then IMO they're fine :D
lizmat that doesn't mean there won't be any ecosystem fallout 18:42
you could argue that any tests are apparently poorly written
timotimo have you considered grepping through perl6-all-modules for the operators you've changde?
lizmat m: say <a b>.Bag (<) <a b c>.Bag # doesn't matter whether Set or Bag semantics 18:43
camelia False
Zoffix huggable: all modules
huggable Zoffix, github.com/moritz/perl6-all-modules
Zoffix
.oO( need a bot that greps that from IRC )
cono or something like this :) grep.metacpan.org/ 18:44
lizmat m: say <a b>.Bag.Set (<) <a b c>.Bag.Set
camelia True
Zoffix yeah
lizmat so that changed
m: say <a b>.Bag (<=) <a b c>.Bag
camelia True
lizmat m: say <a b>.Bag.Set (<=) <a b c>.Bag.Set # didn't change 18:45
camelia True
lizmat problem with grepping is that (<) also affects (>) as well as the unicode versions of each 18:46
so that's like 8 different ops to look for
Zoffix What sucks is the coverage tells us these ops are covered: perl6.wtf/SETTING__src_core_set_op....html#L204
lizmat note that $a (>) $b is essentially $b (<) $a
Zoffix but evidently lots of cases aren't covered
lizmat well, that is from an older version of the settings: I added a lot of candidates 18:47
that aren'y shown in there
cono wow Bag nice data structure for ml classification prolems
Zoffix ZOFVM: Files=1242, Tests=135655, 114 wallclock secs (22.22 usr 3.16 sys + 2342.07 cusr 138.52 csys = 2505.97 CPU) 18:48
Geth rakudo/nom: e13a3a6837 | (Zoffix Znet)++ | tools/build/NQP_REVISION
Bump NQP

NQP bump brought changes:
  github.com/perl6/nqp/compare/2017....8-gdebd8be
debd8be Merge pull request #360 from cono/socket_get_port_op bd57598 Merge branch 'master' into socket_get_port_op b5f29e9 Bump moar revision 191958d Rename get_port -> getport eeb2379 Add mapping of the op code get_port_sk
Ā¦ rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....8-gdebd8be
rakudo/refactor-socket-encoding: bc98e671c9 | cono++ | src/core/IO/Socket/INET.pm
Update localport if we made bind on port 0

There is a common practice to bind on first un-used port, you have to bind on port 0 and after that with help of getsockname call you can get what port is in use.
rakudo/refactor-socket-encoding: ab9d9e2528 | cono++ | src/core/IO/Socket/INET.pm
Rename get_port -> getport
rakudo/refactor-socket-encoding: 919fc362d5 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/IO/Socket/INET.pm
Merge pull request #1086 from cono/refactor-socket-encoding

Update localport if we made bind on port 0
cono sorry for not squashing it :( Just read that its required step
timotimo i'm not sure we require squashing commits for pull requests?
Zoffix didn't even know that was a required step :}
wait, wtf happend.. 18:50
cono github.com/rakudo/rakudo/blob/nom/...on-process
// and please squash out any intermediate commits, like adding/removing debug output.
timotimo i expect that only refers to stuff that gets added in one part of the PR, and then removed again later
Zoffix Oh it got merged into the sock refactor, but should've gone to nom, no? 18:51
timotimo i'm not actually sure what you did :D
Zoffix yup
cono dunno, jnthn asked me to use this branch
timotimo ah, the one before was just a nqp version bump
jnthn I merged the refactor-socket-encoding branch earlier 18:52
Geth rakudo: zoffixznet++ created pull request #1087:
Merge sock branch
jnthn I think it's just recreated the branch
Geth rakudo/nom: 4 commits pushed by cono++, (Zoffix Znet)++
jnthn So it's just a case of merging it into nom 18:53
Zoffix Yeah
jnthn Or doing a like that :P
Zoffix notes to self: double check branches next time you're merging stuff :) 18:54
cono as for the segfault, I'll open issue in MoarVM with link to roast's PR, as currently I don't have a clue what is going on in GC... pretty a lot of things to learn
timotimo have i seen that segv? 18:55
cono timotimo: github.com/perl6/roast/pull/270
it strange that it fails after third run of the same sub: pastebin.com/HbKZq5PC 18:56
timotimo there's some #define in the code that will make gc problems appear closer to what caused 'em
cono so first 2 times of thread.finish works fine 18:57
what define? 18:58
Zoffix ZOFVM: Files=1242, Tests=135655, 113 wallclock secs (22.01 usr 3.13 sys + 2351.16 cusr 137.27 csys = 2513.57 CPU)
Result: PASS
y
k. That's nom HEAD all pass :)
Zoffix returns to lurning
timotimo it's called MVM_GC_DEBUG
(but there's also some enum values called MVM_GC_DEBUG_SOMETHING, which are for something different 18:59
jnthn bbl
cono++ # .localport improvements :) 19:00
cono thanks :)
Zoffix TIL "2nd Defenestration of Prague" is a thing 19:05
Happened on this day, in 1618: twitter.com/weird_hist/status/8670...2624522241
timotimo how did they defenestrate prague, and how the heck did they manage to do it a second time? :P
Zoffix :)
moritz windows still open, eh? :-) 19:20
lizmat m: &infix:<(elem)>.name # is there a way to get at "(elem)" without having to do matching on .name ? 20:01
evalable6
lizmat m: say &infix:<(elem)>.name # is there a way to get at "(elem)" without having to do matching on .name ?
evalable6 infix:<(elem)>
jnthn I don't know of one; by that point it's just a mangled symbol in the symbol table 20:02
timotimo and it being installed in the grammar with the right kind of token makes it "work"
jnthn decides to keep away from open windows
lizmat but the grammar somehow needs to know it's (elem) ?
I'm just thinking having the actual operator name available would be nice to have for hyper ops error messages 20:03
jnthn At parse time, then we have the pieces to hand. At import time we only have the symbol name, and we do it by a match :-) 20:05
You can steal the regex at least ;-)
lizmat ok, fair enough
jnthn (Near the end of method import in Perl6::World, fwiw)
So yeah, there ain't a smarter way. :) 20:06
lizmat I'll just go for: "for &infix:<āˆˆ>, "āˆˆ", &infix:<(elem)>, "(elem)" -> &op, $name:
jnthn But note that we already reduce the numerous forms that may exist down to just a couple of them
lizmat jnthn: not sure what you mean ? 20:07
I mean, we have candidates for all forms
jnthn I mean that it could be written infix:<< + >> and infix:<+> and infix:['+']
But .name is already standardized to just infix:<+> whichever one it is written as in the source code 20:08
lizmat ah, yes, ok, gotcha
jnthn So it's actually much easier to match that it may first appear :)
*than
Geth roast: 7356cee9d2 | (Elizabeth Mattijsen)++ | S03-operators/set.t
Make (elem) and (cont) tests more data driven

To make it easier to add a whole load of other tests.		 20:41
roast: 93a79c852c | (Elizabeth Mattijsen)++ | S03-operators/set.t
Rename variables to current representation

SetHash used to be called KeySet (hence $ks -> $sh) BagHash used to be called KeyBag (hence $kb -> $bh)
For easier understandability.		 20:49
roast: 03f448c646 | (Elizabeth Mattijsen)++ | 3 files
Use a slightly faster showkv
 20:58
roast: 95e574b6ef | (Elizabeth Mattijsen)++ | S03-operators/set.t
Fix copy-pasto
 21:06
lizmat is going to reorganize the set operator tests in S03-operators/(set|bag|mix).t into files grouped by operator 21:08
so that we can have a more thorough test coverage easier 21:09
Geth roast: a5d5075f0f | (Elizabeth Mattijsen)++ | 2 files
Move (elem) and related tests to S03-operators/elem.t
 21:12
rakudo/nom: c82b72ae3a | (Elizabeth Mattijsen)++ | t/spectest.data
Add S03-operators/elem.t for testing
 21:14
Zoffix judges RT#131349 an accidental improvement 22:01
AlexDaniel it probably is 22:02
Geth roast: e86264fe7d | (Elizabeth Mattijsen)++ | S03-operators/elem.t
More thorough tests for (elem) and friends
Zoffix The behaviour change is due to a perf commit ( 7ea0f66189 ) but Baggy and Map .invert return Seqs too, and we already have .antipair on Pair to get an inverted pair
gonna fix up the docs, add tests, and close the ticket
lizmat has written too many tests today and goes to bed 22:03
Zoffix night
Also lizmat++ tests \o/ 22:04
MasterDuke jnthn, timotimo: sorry to keep bugging you about it, but any more pointers on that nqp int bug? i've added lots of prints in ./src/vm/moar/QAST/QASTCompilerMAST.nqp, but haven't found anything relevant/helpful 22:08
Zoffix cool, found a bug while writing those test5s 22:39
m: my @t = [ <a b c> => <d e f>, <d e f> => <a b c> ],; for @t -> ($a, $b) {}
evalable6 (exit code 1) This type cannot unbox to a native string: P6opaque, List
in block <unit> at /tmp/n054vyw6Ox line 1
Zoffix m: for [(<a b> => <d e>, <c d>),] -> ($a, $b) {} 22:40
evalable6 (exit code 1) This type cannot unbox to a native string: P6opaque, List
in block <unit> at /tmp/jgWfb6tyKO line 1
Zoffix m: for [(Pair.new: <a b>, <d e>),] -> ($a) {} 22:41
evalable6 (exit code 1) Too few positionals passed; expected 1 argument but got 0 in sub-signature
in block <unit> at /tmp/n_Q1TLKr3R line 1
Zoffix huh? I *am* passing 1 in sub sig
nm 22:42
m: for [(<a b> => <d e>,),] -> ($a) {}
evalable6 (exit code 1) This type cannot unbox to a native string: P6opaque, List
in block <unit> at /tmp/GvDtKhehsp line 1
Zoffix m: for [((<foo> => <d e>),),] -> ($a) {}
evalable6 (exit code 1) Too few positionals passed; expected 1 argument but got 0 in sub-signature
in block <unit> at /tmp/42XTnfpZeF line 1
Zoffix doesn't seem to get it
m: my @a; @a[0] = (<foo> => <d e>),; dd @a; for @a -> ($a) {} 22:44
evalable6 (exit code 1) Array @a = [(:foo(("d", "e")),),]
Too few positionals passed; expected 1 argument but got 0 in sub-signature
in block <unit> at /tmp/3uPqnFDfqa line 1
Zoffix yeah, something's weird
aha 22:45
m: dd (<a b> => 42,).Capture
evalable6 (exit code 1) This type cannot unbox to a native string: P6opaque, List
in block <unit> at /tmp/UKE9ABo5a_ line 1
Zoffix m: (class {} => 42,).Capture 22:46
evalable6 (exit code 1) Cannot unbox a type object (<anon|58874688>) to a str.
in block <unit> at /tmp/8dT_67Gnbc line 1
ugexe m: for [((<foo> => <d e>),),] -> $a {} # but why is it ok without ()?
evalable6
Zoffix yeah, just need a parametirezed nqp::hash
ugexe: because <foo> is a Str not a List 22:47
ugexe: oh, I misread the question
ugexe yeah i mean it seems to be () + Capture that causes it?
Zoffix ugexe: because then it just passes the list without unpacking it
Yeah, it's List.Capture that causes it: this line: github.com/rakudo/rakudo/blob/c82b...st.pm#L886
TBH, kinda weird that just any old Pair gets turned into a named arg 22:57
Maybe containerized thing doesn't apply to them
Filed as rt.perl.org/Ticket/Display.html?id=131351 22:59
ugexe agree, i'd expect you'd have to | it for that 23:00
Zoffix m: sub ( (:$a, :$b) ) { dd [ $a, $b ] }( [:42a, :72b], ) 23:04
evalable6 [42, 72]
Zoffix m: sub ( (:$a, :$b) ) { dd [ $a, $b ] }( [%(:42a, :72b)], ) 23:05
evalable6 [42, 72]
Zoffix m: sub ( (:$a, :$b) ) { dd [ $a, $b ] }( [%(:42a, :72b),], )
evalable6 (exit code 1) Too many positionals passed; expected 0 arguments but got 1 in sub-signature
in sub at /tmp/Fx0ibYcWJn line 1
in block <unit> at /tmp/Fx0ibYcWJn line 1
Zoffix mkay
m: dd %(<a b c> => <d e f>, :42a).invert 23:11
evalable6 (42 => "a", :d("a b c"), :e("a b c"), :f("a b c")).Seq
Zoffix this also looks messed up 23:12
m: dd %(<a b c d>) => %(<e f g h>).invert
evalable6 ({:a("b"), :c("d")}) => (:h("g"), :f("e")).Seq
Zoffix m: dd (%(<a b c d>) => %(<e f g h>)).invert 23:13
evalable6 ((:g("h")) => {:a("b"), :c("d")}, (:e("f")) => {:a("b"), :c("d")}).Seq
Zoffix this too
Zoffix shrugs
m: dd %( %(<a b c x>) => %(<d e f g>) ) 23:15
evalable6 Hash % = {"a\tb\nc\tx" => ${:d("e"), :f("g")}}
Zoffix this three
ZofBot: it's a bug hole! Abort! Abort! Leave while you can!
ZofBot Zoffix, here github.com/perl6/whateverable/blob...#L172-L173
Zoffix oh wait, last one is ok 23:17
m: dd :{ %(<a b c d>) => %(<d e f g>) }.invert 23:18
evalable6 ((:d("e")) => {:a("b"), :c("d")}, (:f("g")) => {:a("b"), :c("d")}).Seq
Zoffix this one is kinda weird
Ah, I've been in this hole already. 23:20
It's by design. If you want just invert behaviour, that's waht .antipairs are for
Per design.perl6.org/S32/Containers.html#Hash and a test
Zoffix sees future-[Coke] frown as he reads over these soliloquies, trying to backlog :P 23:21
geekosaur perhaps if it keeps tripping you/others up, it should be reconsidered and maybe much more clearly documented
Zoffix shrugs
I'm not exactly a model user. I never read docs and don't program tons of Perl 6
Yeah, this behaviour is documented: docs.perl6.org/type/Map#method_invert 23:22
Zoffix notes to read the docs next time :D
Geth roast: f4828aaf64 | (Zoffix Znet)++ | S02-types/pair.t
Spec Pair.invert

RT#131349: rt.perl.org/Ticket/Display.html?id=131349		 23:33
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131349
Zoffix Ah, hahaha 23:53
There actually *are* test for Pair.invert, but notice the problem: github.com/perl6/roast/blob/6.c-er...#L330-L332 23:54
They're using [0] index without checking what's it being called on, the tests were passing despite behaviour being wrong :)

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!