japhb eveo: It worked! 00:22
\o/
eveo \o/
Well, this was awesomely painless. Converted toaster web app to Perl 5 and HEAD toast data is now available: toast.perl6.party/ 00:59
Conversion felt like it mostly involved inserting a load of $_-> and brackets and parens all over the place 01:00
something's off with commit sorting .... 01:02
Geth rakudo/ugexe-patch-1: 575533866a | (Nick Logan)++ (committed using GitHub Web editor) | src/core/CompUnit/Repository/Installation.pm
Only slurp source file once during install
 01:20
rakudo: ugexe++ created pull request #1102:
Only slurp source file once during install
eveo buggable, toast 01:25
buggable eveo, Between 2017.05-463-gc532b79 and 2017.05: 5 (0.60%) modules got burnt. 9 (1.08%) got unsucced. Currently 210 (25.27%) out of 831 modules appear unusable.
eveo \o/
buggable, toast 01:26
buggable eveo, Between 2017.05-463-gc532b79 and 2017.05: 5 (0.60%) modules got burnt; 9 (1.08%) got unsucced; 210 (25.27%) out of 831 modules appear unusable. See toast.perl6.party/ for details.
Geth rakudo/nom: 575533866a | (Nick Logan)++ (committed using GitHub Web editor) | src/core/CompUnit/Repository/Installation.pm
Only slurp source file once during install
 01:29
rakudo/nom: aeffd00912 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/CompUnit/Repository/Installation.pm
Merge pull request #1102 from rakudo/ugexe-patch-1

Only slurp source file once during install
MasterDuke eveo: is the perl6 version of the toaster web app in a repo? i could try running it with heaptrack and see if it points out where the leak is 01:55
yoleaux 16 Jun 2017 13:48Z <lizmat> MasterDuke: gist.github.com/lizmat/063358317dc...01de1c2687 :-)
MasterDuke .tell lizmat thanks, i hope to use that for coverable
yoleaux MasterDuke: I'll pass your message to lizmat.
eveo MasterDuke: github.com/zoffixznet/perl6-Toaster#viewing 02:02
MasterDuke thanks 02:03
eveo And you can get the database from temp.perl6.party/toast.sqlite.db if you need it 02:04
MasterDuke `<...>/perl6-Toaster/templates/404.html: No such file or directory` 02:17
eveo Hm, maybe forgot to add it. Just create a dummy file 02:18
wget temp.perl6.party/404.html 02:19
MasterDuke: oohhh
MasterDuke: I've just converted it to Mojolicious. rm -fr templates; mv p6-templates templates 02:20
MasterDuke ah
eveo too sleepy to hunt this race any longer 03:22
eveo goes to bed
Gonna eat this bug for breakfast instead. Nom nom nom! 03:23
Geth rakudo/nom: 1171e67e21 | (Nick Logan)++ (committed using GitHub Web editor) | src/core/CompUnit/PrecompilationStore/File.pm
Skip calling .IO on path parts

  ...and use the `iso-8859-1` encoding name used in other CUR related modules		 04:09
[Tux] This is Rakudo version 2017.05-466-g1171e67e2 built on MoarVM version 2017.05-115-g369c0c5c 06:22
csv-ip5xs 2.798
test 12.726
test-t 4.126 - 4.588
csv-parser 12.855
lizmat Files=1204, Tests=62522, 217 wallclock secs (13.20 usr 4.98 sys + 1301.10 cusr 131.13 csys = 1450.41 CPU) 08:59
yoleaux 01:55Z <MasterDuke> lizmat: thanks, i hope to use that for coverable
pmurias $*VM seems undocumented and the tests only test for existence and not the result of various methods on it 09:15
any idea what I'm supposed to put in $*VM.properties on the JS backend?
Geth roast: c8680b49e1 | pmurias++ | S02-magicals/VM.t
[js] Skip test for a $*VM method I don't how how I'm supposed to implement
 09:20
rakudo/nom: 1acef38f68 | (Stefan Seifert)++ | src/core/CompUnit/PrecompilationRepository.pm
Expand RAKUDO_MODULE_DEBUG output for diagnosing checksum issues
 10:01
nine ~~
yoleaux 16 Jun 2017 19:21Z <eveo> nine: are you around by any chance? Does this MODULE_DEBUG output tell you anything why on windows even `zef --help` fails with some kind of rename issue. The code that writes to the file in question definitely closes it: gist.github.com/zoffixznet/87541b1...18235238e0
eveo FWIW, I'm hunting a datarace when one Proc's .out feeds another Proc's .in; dunno if such setup exists in precomp somewhere 10:03
nine eveo: there's more going on. Right at the top it's detecting an outdated precomp file, which means that it thinks the source file has changed since the last precompilation which actually must not happen with an installed dist.
eveo: it doesn't
Later on it again thinks the precomp file for the Zef module is outdated. The only reason for that message can be a source file checksum mismatch. Now even if you changed the source file before running that test, I just don't believe that you would change the source file right during the test. 10:05
I think that's where we should look at. Not the renames. The rename issue may just be a symptom of rakudo not noticing that it already has a perfectly usable precomp file. 10:06
I think what happens is that it thinks the precomp file is outdated, precompiles it again, loads that file (keeping it open for lazy deserialization!), then precompiles another dependency that again tries to load Zef, again thinks it's outdated, precompiles it and boom. 10:07
It cannot rename the tmp file, because the precomp file is already open in a parent process.
eveo: so could you please try again with my above commit? Maybe the checksums give us another hint. 10:08
eveo pulls and builds 10:10
dogbert17 nine: what could cause 'collect2: error: ld returned 1 exit status' when running 'zef install Inline::Perl5'? 10:13
eveo nine: here: gist.github.com/zoffixznet/a8baeea...f3f09a287a
dogbert17 and the important line: /usr/bin/ld: cannot find -lperl 10:14
nine dogbert17: what does "perl -MExtUtils::Embed -e ccopts -e ldopts" give you? 10:15
dogbert17 -Wl,-E -fstack-protector -L/usr/local/lib -L/usr/lib/perl/5.18/CORE -lperl -ldl -lm -lpthread -lc -lcrypt
-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fstack-protector -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/lib/perl/5.18/CORE
nine eveo: there! It gets two totally different checksums for the same source file 10:16
eveo Cool. How to fix it? 10:18
nine eveo: there's probably some slight difference between $path.slurp(:enc<iso-8859-1>) and $handle.open(:enc<iso-8859-1>).slurp(:close) and $handle.open(:bin).slurp(:close).decode('iso-8859-1') 10:23
The latter two have been in use in CompUnit::Repository::Installation. The former is in CompUnit::PrecompilationRepository.
I'd guess the difference is with newline translation or maybe trailing newlines. Something that wouldn't matter anywhere else. 10:24
eveo nine++ damn 10:26
Nice debugging :) Indeed there's a difference
C:\rakudo>perl6 -e "dd 'foo'.IO.slurp: :enc<iso-8859-1>; dd 'foo'.IO.open(:enc<iso-8859-1>).slurp" 10:27
"a\nb\n"
"a\r\nb\r\n"
now.. which one is the right answer? It IO::Handle.slurp seems to give "\r\n" for latin and "\n" for utf8 10:31
and reading the sauce, in both cases `Rakudo::Internals::VMBackedDecoder.new($!encoding, :translate-nl)` appears to be called 10:32
nine Since I don't care about Windows at all, I've never given the topic on how to handle newlines any though. Which is an elaborate way of saying "I have no idea". 10:34
Maybe we should just look at what rakudo did before jnthn's IO refactor?
I don't think he meant to change any semantics there 10:35
eveo ok
eveo builds 2017.04.3
nine dogbert17: is there a libperl.so in /usr/lib/perl/5.18/CORE? 10:39
dogbert17 nine: no, can't se any. I did find a '/usr/lib/libperl.so.5.18' 10:48
eveo on 2017.04.3 in both slurps latin1 gets \r\n, but utf8 gets just \n
eveo doesn't understand this
nine dogbert17: are you just missing a perl-dev or perl-devel or whatever package?
dogbert17 checks 10:49
nine eveo: well latin-1 is pretty much just a 1:1 relationship between bytes and characters while utf-8 is a Unicode encoding with all of the million rules Unicode brings. 10:50
dogbert17 nine: can't find any package with a similar name in Synaptic (running Linux Mint) 10:54
eveo k, well, I'm gonna go with "slower but righter" then, for now 10:55
nine dogbert17: sorry, the directory structure in mirrors.advancedhosters.com/linuxmint/packages/ makes zero sense to me. 11:01
dogbert17 nine: got it working, made a link to the lib in /usr/lib/perl/5.18/CORE and suddenly everything worked :) 11:02
eveo dogbert17: fwiw, I just perlbrew my own perl: gist.github.com/zoffixznet/d41f738...dd32cff23a
nine With a sensible directory structure like openSUSE's you can just go to download.opensuse.org/distribution/...se/x86_64/ and ctrl+f through the package list
eveo Oh, OK, nevermind then
nine dogbert17: then I guess Mint's perl package is broken and you should report that.
dogbert17 perhaps I should try a newer version of Mint first, the one I have is quite old 11:04
eveo ZOFFLOP: t/spec/S11-modules/nested.t 11:05
Geth rakudo/nom: 446dc190e5 | (Elizabeth Mattijsen)++ | src/core/Range.pm
Make ^Inf marginally faster

  ++$i is faster than $i++		 11:12
jnthn morning o/ 11:15
yoleaux 10:15Z <eveo> jnthn: there's apparently an issue with Proc::Async.kill not killing some things (even without the Kernel.signal race issue). Allegedly started with these moarvm commits. Do any look guilty? irclog.perlgeek.de/perl6/2017-06-17#i_14745784
eveo jnthn: morning 11:16
jnthn: do you fancy hunting a race? :)
jnthn The only changes in procops.c in that commit range are adding support for bind-std* 11:17
I can't think of any way the .kill code could have changed in the last month
What's the race?
eveo OK. Maybe it's just a fluke in reporter's test code.
jnthn Well, it's also possible there was always a problem with it 11:18
Guess could always strace and see what signals it actually sends 11:19
Ah, I think the latin-1 problem is that it doesn't actually go through the decodestream mechanism 11:21
oops
Through the normalizer mechanism I meant
And that's where the mapping happens 11:22
eveo jnthn: some sort of race when you use one proc's out pipe as another proc's in pipe. Here's the test case; run it a few times: gist.github.com/zoffixznet/440cf8f...dbb3a625b3 and I added some debug prints gist.github.com/zoffixznet/a8c5f2e...e947a3291b and the output from them is gist.github.com/zoffixznet/3351870...96121ab9a6 So the supply
sequencer seems to be missing one call in the failing case
jnthn That also doesn't seem to be a regression, but it certainly wants a fix
eveo: There's already an RT asking for that to be done totally differently anyway 11:23
eveo OK
jnthn So I'm not inclined to spend time on the current code for it.
eveo Alright
jnthn When it's getting tossed in the next week or so
Hopefully not a blocker?
eveo jnthn: and for the translate-nl thing... it only supposed to happen on utf8?
jnthn No, it's supposed to happen on everything, but latin-1 takes a shortcut 11:24
And misses the place where it happens
eveo oh
jnthn Just been looking at the code and seen why
lizmat afk&
eveo That's a blocker.
jnthn Why? It's not a regression, it's been like that for months. 11:25
I mean, I can put in a quick fix for it, but I hate doing those right before releases.
eveo jnthn: it breaks precomp on Windows. IO::Path.slurp in latin1 now differs from IO::Handle.slurp in latin. And well, I could make IO::Path.slurp use IO::Handle.slurp for release, I guess, if it's more work trying to fix the latin for IO::Handle.slurp 11:27
I actually already got a commit locally doing that
jnthn Ah, ok
Wait, which one is correct? 11:28
eveo IO::Path.slurp
C:\rakudo>perl6 -e "dd 'foo'.IO.slurp: :enc<iso-8859-1>; dd 'foo'.IO.open(:enc<iso-8859-1>).slurp"
"a\nb\n"
"a\r\nb\r\n"
llfourn perl
eveo It decodes manually and got a .substr on it
llfourn (wrong window) 11:29
jnthn Ah, right
eveo while IO::Handle.slurp goes throw vmdecoder newline translator
jnthn .subst?
eveo .subt yeah
jnthn Yeah, but we went through that decoder in previous releases too
But maybe IO::Path.slurp was wrong also then
eveo C:\rakudo-old>perl6 -e "dd 'foo'.IO.slurp: :enc<iso-8859-1>; dd 'foo'.IO.open(:enc<iso-8859-1>).slurp" 11:30
"a\r\nb\r\n"
In past releases yeah, it was.
^ that's 2017.04.3
So I was gonna make it ^ like that again, to unbust precomp
jnthn Hm, so the inconsistency somehow busts precomp? 11:31
Oddness
eveo Yeah, in one place CompUnit code uses one .slurp and in the other, the other
And actually now there's a thrid place, that decodes manually
This one github.com/rakudo/rakudo/commit/57...58a2ef0247
nine jnthn: different places that calculate a checksum for the source file use different methods, so the checksum never matches and it recompiles again and again. 11:32
jnthn oh, it's for a checksum
Now it all makes sense :)
Geth nqp/master: 7 commits pushed by pmurias++
nine The only reason for using latin-1 is cause nqp::sha1 requires a string
jnthn I've got a slightly hacky patch to address it for latin-1
nine: Oh, so we could get faster precomp if we could sha1 a buffer? :) 11:33
nine Probably yes. Probably even faster and with lower memory usage if we could give it a file handle 11:34
jnthn Now I've got a less hacky patch and applied it for the ascii and windows-blah encoding too 11:39
eveo: Committed as MoarVM a0992f3872 11:41
eveo cool. Thanks
jnthn eveo: I'll hold off on doing the MoarVM release until I hear all's good 11:44
eveo hm, precomp is still broken, but now I think it might be github.com/rakudo/rakudo/commit/57...58a2ef0247 11:45
eveo reverts it and builds
the .slurps are the same now tho 11:46
still crashes with same problem 11:50
eveo tries re-installing zef
\o/ 11:51
jnthn: yup. Fixed now
jnthn Phew :)
eveo++
jnthn bbl 11:52
travis-ci NQP build failed. pmurias '[js] Decont the result of the boolification method like the JVM does 12:01
travis-ci.org/perl6/nqp/builds/243962279 github.com/perl6/nqp/compare/f6459...6b737980ea
lizmat sometimes I think we need something like: sub cue(|c) { $*SCHEDULER.cue(|c) } 12:02
so you could say cue { }, :in(5); instead of the wordy $*SCHEDULER.cue: { }, :in(5); 12:03
eveo never used cue in code... 12:06
lizmat: and in that doc commit perhaps Promise.in(5) is more user-friendly? For example, with .cue, dynamics won't be seen 12:08
jnthn Normal users probably shouldn't use cue in code
eveo m: my $*foo; $*SCHEDULER.cue( { say $*foo }, :in(1) ); sleep 2
camelia Unhandled exception in code scheduled on thread 4
Dynamic variable $*foo not found
in block at <tmp> line 1
 12:09
eveo m: my $*foo; Promise.in(1).then: { say $*foo }; sleep 2
camelia (Any)
lizmat eveo jnthn: ok, good points
it's just too bad that we don't expose :every and :times functionality :-( 12:10
jnthn Supply.interval for :every 12:11
Add .head for times
lizmat anyways, afk for a bit of schlepping&
jnthn Yup, and lunch making here :) 12:12
eveo ZOFFLOP: t/spec/S17-procasync/kill.t
jnthn eveo: Not quite sure how my afternoon will look, but drop me a message when you're happy I can cut the MoarVM release and I'll do it when free :)
eveo jnthn: I think I'm happy right now 12:14
Geth rakudo/nom: 222b4083c9 | (Zoffix Znet)++ | src/core/Buf.pm
Make invocation of Blob.decode() 2.7x faster

  - We don't need to normalize encoding when we already know what it is
  - The 2.7x speedup is for short strings and by 10_000-char strings
   gets drowned by the decode operation
eveo jnthn: so anytime you're free, cut it :)
dogbert17 ran a spectest with some debug options set, the only test which fails constantly (in that setting) is t/spec/S17-procasync/no-runaway-file-limit.t (SEGV) 12:22
OTOH, it's been like this for quite some time so I don't think any recent refactors are to blame
eveo ZOFFLOP: t/spec/S10-packages/precompilation. 12:25
Geth nqp: ed1a5d868a | (Zoffix Znet)++ | tools/build/MOAR_REVISION
Bump MoarVM

MoarVM bump brought commits:
  github.com/MoarVM/MoarVM/compare/2...6-ga0992f3
a0992f3 Fix newline translation in various encodings.
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...6-ga0992f3
rakudo/nom: 369f2511a6 | (Zoffix Znet)++ | tools/build/NQP_REVISION
Bump NQP

NQP bump brought commits:
  github.com/perl6/nqp/compare/2017....0-ged1a5d8
ed1a5d8 Bump MoarVM e66b737 [js] Decont the result of the boolification method like the JVM does ... (13 more lines)
¦ rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....0-ged1a5d8
star: 0ee2ebdf7e | (Steve Mynott)++ | 3 files
native resources no longer used by linenoise
 12:36
eveo nqp JVM fails "java.lang.RuntimeException: Unimplemented case of read_ref"
More output: gist.github.com/zoffixznet/d2d29a4...fce54ee6c8
m: class Foo { method x(str $y) {} }; dd Foo.^lookup('x').cando: \(Foo, my str $ = 'x') 12:40
camelia ()
eveo Looks like something's busted with .cando and native params
(been for awhile)
holy crap! 12:42
ZOFVM: Files=1254, Tests=139499, 102 wallclock secs (13.84 usr 2.66 sys + 1542.68 cusr 304.13 csys = 1863.31 CPU)
This might be fastest run ever :) Almost up to double-digits :)
Filed cando thing as rt.perl.org/Ticket/Display.html?id=131590 12:45
pmurias eveo: re JVM fail, a newly added test fails :/ I'll look into fixing the JVM backend up 12:49
stmuk perlpilot: I just ran across github.com/perlpilot/Grammar-Profi...e/issues/6 and there is a PR open claimed to fix it 12:50
the debugger is still broken I see .. 12:52
eveo Heh grep accepts `-nerd` as commandline options 12:54
stmuk: it is, yeah
Was hoping to fix for this realease, but no time
stmuk: R* release is next month, not this month, right?
huggable: star 12:55
huggable eveo, Estimated Rakudo Star releases for 2017: .01, .04, .07 & .10
stmuk eveo: yes .. I was just doing a dry run of some R* modules
++evo
eveo `cool 12:56
nine jnthn: I gave implementing a sha1_fh op a try. Though in theory that should be faster, the difference is just not measurable. You'd probably need to load a really large number of modules from your top-level script to see a difference. 13:04
eveo ZOFFLOP: t/spec/S17-promise/nonblocking-await.t 13:07
ZOFFLOP: t/spec/S17-supply/syntax.t
travis-ci NQP build failed. Zoffix Znet 'Bump MoarVM 13:08
travis-ci.org/perl6/nqp/builds/243970661 github.com/perl6/nqp/compare/e66b7...1a5d868ad4
Geth rakudo/nom: a5be845438 | (Zoffix Znet)++ | src/core/CompUnit/Repository/Installation.pm
Fix Windows precomp checksum mismatch issue

The .slurp we're using elsewhere in the CompUnit code translates newlines, so we need to do the same here, where we're decoding manually.
eveo BAHA! 13:13
ZOFVM: Files=1254, Tests=139499, 93 wallclock secs (14.59 usr 2.67 sys + 1635.43 cusr 170.64 csys = 1823.33 CPU)
Just look it at! Look at that 93 secs stresstest run! 13:14
Geth rakudo/nom: 46eecdae8a | (Zoffix Znet)++ | src/core/Distro.pm
Micro-opt .subst call in INITIALIZE-A-DISTRO-NOW

We don't need to use a regex here and Str matcher with :g will fast-path		 13:16
rakudo/nom: 6788833bb8 | (Zoffix Znet)++ | src/core/IO/Path.pm
Optimize newline translation in IO::Path.slurp

instead of going through .subst, do the same work with nqp ops in place. This change to translation is 55x faster for empty strings and diminishes to a wash by the time we do 12_000-char strings.		 13:18
eveo does another stresstest run to ensure it wasn't a fluke :P
nine Oh, there's still a difference between reading binary and latin-1 on reading the ∖ character (set difference)
eveo m: with '/tmp/dfasdasas'.IO { .spurt: "∖"; dd .slurp: :enc<latin-1>; dd .slurp(:bin).decode: "latin-1"; dd .open(:enc<latin-1>).slurp; dd .open(:bin).slurp.decode: "latin-1" } 13:20
camelia "â\x[88]\x[96]"
"â\x[88]\x[96]"
"â\x[88]\x[96]"
"â\x[88]\x[96]"
eveo looks same to me
ZOFFLOP: t/spec/S11-modules/require.t 13:21
all this floppiness isn't very nice
nine I get different checksums between nqp::sha1("/home/nine/rakudo/install/share/perl6/site/sources/924DBC42DF8BAD45FCD18E9C01EE80DE055FF2BF".IO.slurp(:enc<latin-1>)); and Rakudo::Internals.sha1-file("/home/nine/rakudo/install/share/perl6/site/sources/924DBC42DF8BAD45FCD18E9C01EE80DE055FF2BF".IO.open) because of that character 13:22
eveo s: Rakudo::Internals, 'sha1-file'
SourceBaby eveo, Something's wrong: ␤ERR: Unhandled exception: Missing or wrong version of dependency '/home/zoffix/services/sourceable/building-perl6/install/bin/../share/nqp/lib/MAST/Nodes.nqp' (from 'src/Perl6/Pod.nqp')␤ at <unknown>:1 (./blib/Perl6/Pod.moarvm:<dependencies+deserialize>)␤ from src/vm/moar/ModuleLoader.nqp:51 (/home/zoffix/services/sourceable/building-perl6/install/share/nqp/lib/ModuleLoader.moarvm:)␤ from src/vm/moar/M
eveo nine: did you upgrade to include latest nqp bump to fix the difference between ::Handle.slurp and ::Path.slurp? 13:23
nine: oh wait. No upgrade neede. ::Path.slurp translates newlines. Are you doing that in binary? 13:24
Oh wait. You're not on Windows :)
eveo shuts up and continues stresstesting 13:25
nine eveo: no, I'm not. But it's not newlines (I'm on Linux anyway). It's the ∖ character. So reading latin-1 is not really equivalent to reading binary.
eveo Weird
How come there's no difference in my eval above tho?
nine eveo: you're ecoding in every case
eveo ah 13:26
m: with '/tmp/dfasdasas'.IO { .spurt: "∖"; dd .slurp(:enc<latin-1>).encode: "latin-1"; dd .slurp(:bin); dd .open(:enc<latin-1>).slurp.encode: "latin-1"; dd .open(:bin).slurp: "latin-1" } 13:27
camelia Blob[uint8].new(226,136,150)
Buf[uint8].new(226,136,150)
Blob[uint8].new(226,136,150)
Too many positionals passed; expected 1 argument but got 2
in block <unit> at <tmp> line 1
eveo m: with '/tmp/dfasdasas'.IO { .spurt: "∖"; dd .slurp(:enc<latin-1>).encode: "latin-1"; dd .slurp(:bin); dd .open(:enc<latin-1>).slurp.encode: "latin-1"; dd .open(:bin).slurp }
camelia Blob[uint8].new(226,136,150)
Buf[uint8].new(226,136,150)
Blob[uint8].new(226,136,150)
Buf[uint8].new(226,136,150)
nine There you see the difference! Err....
eveo I see type difference but not the bytes 13:28
ZOFVM: Files=1254, Tests=139499, 109 wallclock secs (20.01 usr 3.19 sys + 2170.54 cusr 154.49 csys = 2348.23 CPU)
93s was a fluke :/
nine That's why I hate character encoding issues. 13:29
eveo pmurias: maybe we should just add a fudger to nqp? Otherwise, you're basically coding js backend while also doing bugfixes to jvm
fixes for bugs that existed already
eveo runs another toaster run 13:31
dogbert17 also, when stresstesting the latest MoarVM t/spec/S17-procasync/stress.t fails with 'MoarVM panic: Adding item to past fromspace to GC worklist'. Dunno if that's recent though. 13:34
jnthn ZofBot: About 6788833bb8, why didn't you just put that code in subst? :) 13:44
ZofBot jnthn, Colon pairs (but not arrow pairs) are recognized within double angles
jnthn cah
eveo: ^^
nine: I'd rather not have an op that does that taking a file handle anyway. I just spent time disentangling I/O from stuff. :P 13:46
eveo jnthn: it's there, but it's also checking for a ton of subst options and involves 2 method calls
jnthn: (not sure if you saw above). You can cut MoarVM anytime you're readyt 13:47
jnthn Can't it just quickly check it got no options? 13:48
eveo s: '', 'subst', \(:g, '', '')
SourceBaby eveo, Sauce is at github.com/rakudo/rakudo/blob/6788...r.pm#L1142
eveo Not sure how to make it any faster there 13:49
And Rakudo::Internals.TRANSPOSE's guts is the code I used in 6788833bb8
jnthn Well, just before release isn't the time, but I'm pretty sure I can figure out how to optimize subst(Str, Str) some :) 13:52
eveo \o/
eveo afk for a bit 13:53
nine jnthn: at least we now know that 1. adding a sha1 op for binary data won't buy us anything and 2. we couldn't do that anyway as it would break checksums of installed modules 13:54
lizmat jnthn: re Str.subst(Str), faster than: nqp::join($final,nqp::split($original,$string)) ?? 13:56
jnthn lizmat: I don't think we can do that faster without VM-backing, but I meant faster than it is now 14:10
lizmat Str.subst already checks for Str,Str and does a TRANSPOSE
the only gain there is the cost of the named parameter handling
*could be 14:11
*reducing
jnthn Yeah, but we could decide that with multi-dispatch instead :)
lizmat yeah, I've worked on that already, but it becomes huge
and as soon as regexes come into play, any gains are dwarved by the regex engine overhead
so I abandoned that for the time being 14:12
jnthn This is the non-regex case, though :)
But yeah, fair enough
Also until this week, spesh was less good at dealing with named parameters
So the costs may have shifted a bit too
lizmat jnthn: the point is that you cannot really handle 5 optional named parameters in dispatch
as we don't have a signature for "no other named parameters" 14:13
if we would have that, something like:
eveo BTW, I think .subst(Str, Str) (no :g modifier) goes through regex path. Dunno if making it nqp::index would have any gains or whatever
lizmat multi sub a(:$foo!, :!%_)
eveo m: for ^100_000 { $ = 'fobar'.subst: 'b', 'x'; }; say now - INIT now 14:15
camelia 13.9065733
eveo m: for ^100_000 { $ = 'fobar'.subst: :g, 'b', 'x'; }; say now - INIT now
camelia 0.75058546
lizmat eveo: good point, will fix in a mo
spectesting now 14:17
Geth rakudo/nom: 0331fb9d50 | (Elizabeth Mattijsen)++ | src/core/Str.pm
Fastpath Str.subst(Str) without :g as well

Spotted by Zoffix++		 14:24
lizmat m: say "foo".subst(Str,Str) 14:25
camelia Cannot resolve caller match(Str: Str, :g(Any)); none of these signatures match:
(Str $: Cool:D $pattern, |c is raw)
(Str $: Regex:D $pattern, :continue(:$c)!, *%_)
(Str $: Regex:D $pattern, :pos(:$p)!, *%_)
(Str $: Regex:D $patter…
lizmat ^^^ makes Str.subst(Str:D,Str:D) about 12x faster 14:31
m: for ^100_000 { $ = 'fobar'.subst: 'b', 'x'; }; say now - INIT now
camelia 0.9400674
lizmat m: say 13.9065733 / 0.9400674 14:32
camelia 14.79316621
lizmat actually looks to be more :-)
afk& 14:38
eveo cool :) lizmat++ 14:44
stmuk this is odd on OpenBSD/moar say $*KERNEL.signal("SIGHUP") returns 2 .. whereas say $*KERNEL.signal(SIGHUP) correctly returns 1 14:46
eveo m: dd [$*KERNEL.signal("SIGHUP"), $*KERNEL.signal(SIGHUP) ] 14:47
camelia [1, 1]
eveo stmuk: what does dd say $*KERNEL.signals give you?
m: dd $*KERNEL.signal
camelia Cannot resolve caller signal(Kernel: ); none of these signatures match:
(Kernel:D $: Str:D $signal, *%_ --> Int:D)
(Kernel:D $: Signal:D \signal, *%_ --> Int:D)
(Kernel:D $: Int:D \signal, *%_ --> Int:D)
in block <unit> at <tmp> lin…
eveo m: dd $*KERNEL.signals 14:48
camelia Array @!signals = [Any, Signal::SIGHUP, Signal::SIGINT, Signal::SIGQUIT, Signal::SIGILL, Signal::SIGTRAP, Signal::SIGABRT, Signal::SIGBUS, Signal::SIGFPE, Signal::SIGKILL, Signal::SIGUSR1, Signal::SIGSEGV, Signal::SIGUSR2, Signal::SIGPIPE, Signal::SIGALR…
eveo stmuk: looks like values are obtained from kill; I see some mangling involved for, say, windows. Maybe some is needed for bsd too. What does qx/kill -l/.words.say give you? 14:51
On my bodhi linux: (0 HUP INT QUIT ILL TRAP ABRT BUS FPE KILL USR1 SEGV USR2 PIPE ALRM TERM 16 CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH IO PWR SYS 32 33 RTMIN RTMIN+1 RTMIN+2 RTMIN+3 RTMIN+4 RTMIN+5 RTMIN+6 RTMIN+7 RTMIN+8 RTMIN+9 RTMIN+10 RTMIN+11 RTMIN+12 RTMIN+13 RTMIN+14 RTMIN+15 RTMAX-14 RTMAX-13 RTMAX-12 RTMAX-11 RTMAX-10 RTMAX-9 RTMAX-8 RTMAX-7 RTMAX-6 RTMAX-5 RTMAX-4 RTMAX-3
RTMAX-2 RTMAX-1 RTMAX)
stmuk > dd $*KERNEL.signals 14:53
Array @!signals = [Any, Any, Signal::SIGHUP,
..snip
eveo Wonder if it was broken by this commit: github.com/rakudo/rakudo/commit/79...9fb352ac13 14:54
stmuk > qx!kill -l!.words.say 14:55
(1 HUP Hangup 17 STOP Suspended (signal) 2 INT
..snip
eveo hm, OK, so looks like it was busted up already before 14:57
dogbert17 m: NFC.new 14:59
camelia Cannot create an NFD directly
in block <unit> at <tmp> line 1
eveo s: NFC, 'new', \() 15:04
SourceBaby eveo, Sauce is at github.com/rakudo/rakudo/blob/6788...ni.pm#L104
Geth rakudo/nom: e824266fd5 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Uni.pm
Fix copy-pastoed type name in error messages; dogbert17++
 15:05
eveo buggable: toast 15:08
buggable eveo, Between 2017.05-473-g6788833 and 2017.05: 5 (0.60%) modules got burnt; 9 (1.08%) got unsucced; 207 (24.91%) out of 831 modules appear unusable. See toast.perl6.party/ for details.
eveo ^ results for HEAD~2
stmuk 'kill -l' looks normal to me ... its almost as if qx!! is sneaking an extra flag in 15:09
eveo stmuk: tty vs. no tty?
kill -l prints human-friendly stuff if I run it from terminal 15:10
stmuk ah its calling the ksh kill!
qx!/bin/kill -l!.words.say is correct 15:14
mst heh, and 'man kill' even mentions the problem of an inferior built-in 15:16
(I didn't know -l existed so went RTFMing)
stmuk eveo: human friendly is probably a shell built in kill 15:18
eveo stmuk: you could fix it for openbsd: github.com/rakudo/rakudo/blob/nom/...#L104-L132 15:23
stmuk sure .. gimme a min 15:24
eveo hm... just did update-perl6 on local box and getting "/usr/bin/env: perl6#: No such file or directory" twice in the output at the end :/
wonder where that's from... 15:25
ohhh...
nine Is there a way to get rid of rakudobrew on travis? I no longer have any reference to rakudobrew in my .travis.yml but it still gets used for installing rakudo 15:26
eveo: seen the same message in Inline::Perl5's travis output
eveo Yeah, something's got busted up. just running `zef` gives me that
nine: you could remove "language perl6". It's installed by default: docs.travis-ci.com/user/languages/perl6 15:27
Ah, ok, I see the problem 15:36
Wow, tests not catching it is scary :/
stmuk eveo: I'm tempted to just use /bin/kill (which should exit on all UNIX systems) rather than detecting OpenBSD and acting differently... any strong views? 15:39
s/exit/exist/
its in the Filesystem Hierarchy Standard 15:40
eveo Not my area of expertise, but if you're doing that for all unix system, then I'd prefer to do that after release 15:41
stmuk ok I'll just special case OpenBSD (as is done already for other systems) 15:42
the ubuntu fix looks very hacky :)
mst eveo: I have the same issue with bash on debian 15:46
so I suspect actually /bin/kill everywhere is a good idea 15:47
there's probably other environments that have this bug
Geth rakudo/nom: fb50f49611 | (Zoffix Znet)++ | src/core/Rakudo/Internals.pm
Fix regression in Str.subst(Str:D, Str:D)

The TRANSPOSE-ONE routine uses incorrect string's length to figure out where to cut off the replaced piece.
Also fixes issues with generated wrappers for binaries.		 15:53
roast: a80a064e3c | (Zoffix Znet)++ | S05-substitution/subst.t
Test Str.subst(Str:D, Str:D)

Rakudo fix: github.com/rakudo/rakudo/commit/fb50f49611
eveo re-runs update-perl6 15:54
stmuk I probably shouldn't be trying to dev on a Celeron N2840 :/ 15:57
eveo ===> Extraction [OK]: JSON::Name to /home/zoffix/.zef/store/JSON-Name.git 16:09
Invalid json? File: /home/zoffix/.zef/store/Inline-Perl5-0.27.tar.gz/Inline-Perl5-0.27/Build.pm
I've seen that before recently.... We didn't fix it, did we?
ugexe weird... wonder how thats getting fed to a from-json call 16:10
eveo Dies repeatedly, so I guess that's another release blocker? 16:12
or again, I guess
Full error: gist.github.com/zoffixznet/8510de8...762d7cb03e 16:13
Geth rakudo: stmuk++ created pull request #1103:
Fix t/spec/S02-magicals/KERNEL.t on OpenBSD
rakudo/nom: 8f1651f798 | (Steve Mynott)++ | src/core/Kernel.pm
Fix t/spec/S02-magicals/KERNEL.t on OpenBSD
 16:20
rakudo/nom: f9ca0b2e1a | (Steve Mynott)++ | src/core/Kernel.pm
changed to self.name following code review
rakudo/nom: 9435c14eb3 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Kernel.pm
Merge pull request #1103 from stmuk/nom

Fix t/spec/S02-magicals/KERNEL.t on OpenBSD
ugexe yeah it happens for me now too... worked yesterday but having looked at the commits it doesn't seem like it should be related
pmurias eveo: I wrap the harder to fixed tests with an if 16:24
eveo ugexe: is there a way to make zef run with --ll-exception perl6? 16:27
pmurias eveo: I fear if we stop fixing up the jvm backend stuff will diverge too much and it will be abandoned :/ 16:28
ugexe only run zef --help, chop off the basename and last path part, add bin/zef, and run with perl6 --ll-exception 16:29
(chop off basename/path part from the config file path shown)
mst pmurias: that kinda worries me too
eveo cool
mst I mean, I don't particularly care about the JVM backend for my own use, but it needs to at least sort-of keep up 16:30
Geth nqp: 9b11c1a078 | pmurias++ | src/vm/js/nqp-runtime/core.js
[js] Make nqp::sech_n work the same as on other backends in an edge case
 16:31
nqp: 6a5d316518 | pmurias++ | t/serialization/01-basic.t
[jvm] Fixup test
ugexe eveo: seems related to the new version of Inline::Perl5.... `zef install "Inline::Perl5:ver<0.26>"` still works 16:37
eveo Oh
Geth nqp: 8132519655 | pmurias++ | t/serialization/01-basic.t
Avoid manually numbering tests
 16:38
eveo I don't get how Build.pm ends up coming up from a routine that looks for metafiles tho
And the same error existed 1 or 2 days ago
ugexe maybe if you were fetching inline::perl5 from github 16:39
which would be HEAD and not 0.16
0.26
eveo weird. it just switches to 0.27 in the middle of the install process: gist.github.com/zoffixznet/07cf592...b728d1dd2e 16:41
ugexe: this also works: zef --/cpan --/cached --debug install Inline::Perl5 16:43
Crypt::Bcrypt also uses Build.pm and installed with no issues. I guess there's nothing wrong with rakudo 16:45
eveo goes to take a nap and will release afterwards
ugexe wonder if Inline::Perl5 is .tar.gz incorrectly 16:46
compare against 0.26 16:47
there is extra stuff in the root directory (that is also in the correct first subdir)
yep 16:53
zef install github.com/niner/Inline-Perl5/arch...ter.tar.gz
works
0.27's .tar.gz archive is not the standard format
nine: ^ 16:54
wonder if the inclusion of that manifest made cpan re-tar it differently than before, or if it was just an accident 17:08
nine ugexe: what do you mean by "not the standard format"? 17:41
travis-ci NQP build passed. pmurias '[jvm] Fixup test' 17:49
travis-ci.org/perl6/nqp/builds/244017602 github.com/perl6/nqp/compare/ed1a5...5d316518bf
ugexe nine: i just checked and if I view the 27.tar.gz in osx file manager it looks ok, but viewing it in windows 7zip the root path had copies of Inline-Perl5/examples|lib 17:56
installation on linux failed, but works if i use a github .tar.gz of inline::Perl:ver<0.27> 17:57
and standard format i mean inside the archive is a single folder which contains everything else 17:58
but this has copies of some subfolders alongside (what is supposed to be) the single folder 17:59
nine ugexe: I don't see that here, neither in the original .tar.gz nor in the one I downloaded from CPAN :/ 18:01
It may be some weird GNU tar extension
ugexe gist.github.com/ugexe/f06fe6b58854...aafc287835 18:04
nine: this shows the problem as far as zef is concerned 18:05
geekosaur looks like a version of tar that doesn't store directories 18:07
ugexe fwiw that gist is the same for both bsd and gnu tar 18:10
geekosaur ah, right. how is this being created? 18:12
because this is v7 tar format
which did not store directories
extracting it needs to be told that, or it will not create directories
ugexe well nine presumably does it manually, but cpan also re-archives it I think? 18:13
travis-ci Rakudo build failed. Zoffix Znet 'Optimize newline translation in IO::Path.slurp 18:17
travis-ci.org/rakudo/rakudo/builds/243980050 github.com/rakudo/rakudo/compare/4...88833bb831
buggable [travis build above] ✓ All failures are due to timeout (0), missing build log (0), GitHub connectivity (0), or failed make test (3). Across all jobs, only 04-nativecall/06-struct.t test file failed.
ugexe this could also be fixed in zef, but we should still figure out why this happened in the first place 18:20
fixing it in zef might be rather involved though to work with all the various formats, although I cant remember why. the problem re: zef is that it was able to know the first item listed could work for `my $root-dir = $save-as.IO.child(@files[0]);` 18:23
e.g. figuring out where it will be extracted to before extracting it 18:24
geekosaur well, having directories in the archive at all is not portable 18:25
ugexe this is how other archives on cpan are 18:26
geekosaur most extensions to basic tar format include them because you'd generally like to support directory permissions, but you should really support the case where they have been omitted for portability
ugexe i suppose it could check that if A) the root dir is not listed and B) all files listed share a common rootdir. But if they don't all share a common root dir its back to not knowing what to do
geekosaur I expect the correct thing to do in that case is fail because you do not have a proper package, unless you want to treat it as a stream format where it includes multiple packages 18:28
if cpan is repacking stuff then you probably need to look into recent changes to the server side of cpan 18:29
ugexe im betting its because there is a manifest file now and *that* doesnt list that directory
as in thats why it didnt get included all of a sudden
nine ugexe: I guess it's because I used the --transform option to store the files in a sub directory
ugexe: do you see any weirdness in this archive? niner.name/files/Inline-Perl5-0.27.tar.gz 18:32
ugexe i wonder why 7zip trips up so badly on it
nine: `zef --/wget install niner.name/files/Inline-Perl5-0.27.tar.gz` worked and the tar --list output looked like 0.26 18:37
why I had to --/wget I dont know lol... it just freezes up
nine: `wget niner.name/files/Inline-Perl5-0.27.tar.gz` doesnt work heh 18:42
everything else works with it from what i can tell though
probably an ip6 thing 18:43
yeah... `wget -4 niner.name/files/Inline-Perl5-0.27.tar.gz` works 18:45
is `$lock.protect({ $foo += 1 }); $lock.protect({ $foo += 1 });` the same as `$lock.lock; $foo += 1 $lock.unlock; $lock.lock; $foo += 1; $lock.unlock` ? 18:52
e.g. does the second .protect lock the first .protect? 18:53
nine yes
travis-ci NQP build passed. pmurias 'Avoid manually numbering tests' 18:54
travis-ci.org/perl6/nqp/builds/244019387 github.com/perl6/nqp/compare/6a5d3...32519655c4
nine So should I release an Inline::Perl5 0.28 with a fixed tar file?
ugexe awesome, i saw all the code in CUR that implied such but I didn't know it worked like that
nine Well src/core/Lock.pm is just 32 very readable lines :) 18:55
ugexe nine: probably. i'm still going to try and make it handle that situation better but I have to test on each OS 18:56
nine File successfully copied to '/home/ftp/incoming/Inline-Perl5-0.28.tar.gz' 18:57
ugexe now I just need a trait or subtype that automatically locks/unlocks when reading/writing to a hash to skip all the additional $lock.protect: { } 19:00
nine ugexe: github.com/jnthn/oo-monitors 19:01
Ah, that's per method
ugexe I suppose a proxy would work 19:02
then again i remember proxy reads a bunch of times per access, which would probably make that super slow 19:04
...or deadlock heh
I also probably need to expand that a bit to also allow a file lock type .protect 19:06
lizmat eveo: good spot on the TRANSPOSE-ONE 19:32
turns out I wrote it a long time ago, but never used it internally
dogbert17 lizmat: just added this, docs.perl6.org/type/Any#method_nodemap, do you see anything that should be added/removed? 19:41
lizmat dogbert17: will check on a mp
*mo
dogbert17 moritz has already helped out but perhaps there are more differences 19:42
BenGoldberg It feels like all of those methods ought to be a single 'map' method, differentiated by :deep, :node, :duck 19:46
lizmat is still trying to grok deep node and duck 19:56
TIL I learned the difference between map and nodemap: handling of slips 19:58
dogbert17 quacks 19:59
ugexe gist.github.com/ugexe/50e9b6ec0a8d...39fc63dd6d - heres a failing test, but not sure where to submit it since it will deadlock on rakudos prior to 2017.06
when its incorrect the total size ends up being a few different values but some repeat more than others (like 262144) 20:07
its always an even number 20:08
geekosaur is it always a *power* of 2? 20:09
262144 = 0x40000 20:10
ugexe no - although some other less-occuring values have been 131072, 700672, 591040 20:17
any idea how to at least tell if its the input or output thats getting lost? 20:25
geekosaur replace «cat -» with «dd» 20:32
it will output summary statistics on stderr
lizmat m: for ^100000 { 42 ~~ /^ <[0..9]> / }; say now - INIT now
camelia 1.1948762
lizmat m: for ^100000 { 42 ~~ m/^ <[0..9]> / }; say now - INIT now # what a difference a letter maketh
geekosaur you may also want to experiment with the ibs and obs options, which might reveal buffering issues
camelia 9.173497 20:33
lizmat m: say 9.173497 / 1.1948762
camelia 7.67736189
lizmat looks like the m// version calls Str.match 20:37
.tell [Tux] CSV can become a bit faster if you replace all m{} by // 20:53
yoleaux lizmat: I'll pass your message to [Tux].
jnthn Is there any reason we can't fix that in the compiler? :) 20:55
lizmat jnthn: there may be a subtle difference about $/ being set / not set 20:57
jnthn Hm, OK
lizmat lemme check
hmmm... no, that's not it 20:58
looks like // calls Regex.ACCEPTS directly, and m// goes through Str.match 20:59
anyways, keeping that until *after* the release for sure
lizmat already got burnt once today with a "simple" optimization :-(
jnthn :)
It's surprisingly easy to be fast and wrong. 21:00
lizmat yeah
travis-ci Rakudo build failed. Zoffix Znet 'Fix copy-pastoed type name in error messages; dogbert17++'
travis-ci.org/rakudo/rakudo/builds/243998340 github.com/rakudo/rakudo/compare/0...24266fd59f
buggable [travis build above] ✓ All failures are due to timeout (0), missing build log (0), GitHub connectivity (0), or failed make test (3). Across all jobs, only 04-nativecall/06-struct.t test file failed.
lizmat on that thought, /me is going to take some R&R
good night, #perl6-dev!
jnthn Enjoy :)
o/
dogbert17 if a method is declared as, e.g. 'method annotations()', does that mean there's an implied :D invocant? 21:16
ugexe geekosaur: thanks, with dd i see that all bytes are being written 21:19
jnthn dogbert17: No 21:25
dogbert17 m: callframe 21:44
camelia ( no output )
dogbert17 m: say callframe
camelia <tmp> at line 1
dogbert17 m: say CallFrame.callframe
camelia Callframe.callframe not yet implemented. Sorry.
in block <unit> at <tmp> line 1
dogbert17 thx jnthn, this means I just commited an error, grr :) 21:45
eveo hm, wonder what's up with that 04-nativecall/06-struct.t test. 22:23
Reproed it immediatelly locally, then removed .precomp dirs and now it's not failing anymore
timotimo perhaps CStruct is serializing/deserializing itself improperly? though that'd require the CStruct to be inside a precompiled module to mess anything up 22:25
eveo Annoyingly can't repro it at all anymore. Though, I notice the travis whining is for commits before the "Fix regression in Str.subst(Str:D, Str:D)" commit 22:33
Also something makes tests in Concurrent::File::Find fail on HEAD, but not on 2017.05 22:42
too bad it's gfldex-ware... 22:43
"my &start = -> ( &c ) { c } if $no-thread;" really :/
Geth rakudo: ugexe++ created pull request #1104:
Fix run/shell :merge
rakudo/nom: 06263e512b | (Nick Logan)++ | src/core/Proc.pm
Fix run/shell :merge

Previously this command would deadlock:
  `my $proc = run("ls", :merge).out.slurp.say`		 22:46
rakudo/nom: 807496671c | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Proc.pm
Merge pull request #1104 from ugexe/proc-merge

Fix run/shell :merge
eveo something to do with .mapping on a Seq 23:02
and for loops 23:04
m: sub foo ($) { (1, 2).Seq.map: &say }; .&foo for 1 23:07
camelia ( no output )
eveo c: 2017.05 sub foo ($) { (1, 2).Seq.map: &say }; .&foo for 1
committable6 eveo, ¦2017.05: «1␤2»
eveo prays to FSM this isn't a change in MoarVM
bisect: sub foo ($) { (1, 2).Seq.map: &say }; .&foo for 1
bisectable6 eveo, On both starting points (old=2015.12 new=8074966) the exit code is 0 and the output is identical as well
eveo, Output on both points: «»
eveo reaaaly
bisect: old=2017.05,new=HEAD sub foo ($) { (1, 2).Seq.map: &say }; .&foo for 1 23:08
bisectable6 eveo, Bisecting by output (old=2017.05 new=8074966) because on both starting points the exit code is 0
eveo, bisect log: gist.github.com/86d16f9097d2ce8c1b...546b557fef
eveo, (2017-06-15) github.com/rakudo/rakudo/commit/9b...a9bb083507
eveo That looks really fancy-pants.. :/
Maybe it's not meant to sink that map? 23:09
"megamorphic callsites" :o 23:10
"¦«2015.09,2015.10,2015.11,2015.12,2016.01.1,2016.02,2016.03,2016.04,2016.05,2016.06,2016.07.1,HEAD(8074966)»: 23:11
¦«2016.08.1,2016.09,2016.10,2016.11,2016.12,2017.01,2017.02,2017.03,2017.04.3,2017.05»: 1
2
So it worked the new way for about a year
Crap. Should've looked at this toaster burn before napping :) Now everyone's gone :) 23:12
eveo lunches
hm 23:26
c: 2017.05,HEAD sub foo($) { (1, 2).Seq.map: &say }; foo($_) for 1
committable6 eveo, ¦2017.05,HEAD(8074966): «»
eveo c: 2017.05,HEAD sub foo($) { (1, 2).Seq.map: &say }; .&foo for 1
committable6 eveo, ¦2017.05: «1␤2» ¦HEAD(8074966): «»
eveo looks like it working was somewhat accidentall
c: 2017.05,HEAD sub foo($) { (1, 2).Seq.map: &say }; (.&foo for 1) 23:27
committable6 eveo, ¦2017.05,HEAD(8074966): «1␤2»
eveo Yeah. I guess I can leave it as is for release. 23:30
Tho looking at it it really should get sunk in that case, and thus .map be evaluated 23:32
bisect: old=2016.06,new=2016.09 sub foo($) { (1, 2).Seq.map: &say }; .&foo for 1 23:34
bisectable6 eveo, Bisecting by output (old=2016.06 new=2016.09) because on both starting points the exit code is 0
eveo, bisect log: gist.github.com/cdd0d8d7a3a2d9d3c1...a13ec33042
eveo, (2016-08-11) github.com/rakudo/rakudo/commit/97...e6ff5f620a
eveo ZOFFLOP: t/spec/S11-modules/nested.t 23:35
ZOFFLOP: t/spec/S17-supply/interval.t
ZOFFLOP: t/spec/S32-io/pipe.t
Damn. That's off one run. Though pipe.t I know what it is and will be fixed next week
samcv eveo, what's ZOFFLOP? 23:36
Geth rakudo/nom: 932b10f6a9 | (Zoffix Znet)++ | 3 files
Revert "Change the way we code-gen simple for loops."

This reverts commit 9b0b9effe5fee1f35497cf97a5e7bda9bb083507.
Reverting for release, as it causes a regression in .map sinkage in for loops:
Zoffix__> c: 2017.05,HEAD sub foo($) { ^2 .map: &say }; .&foo for 1
  <committable6> Zoffix__, ¦2017.05: «0␤1» ¦HEAD(8074966): «»
eveo samcv: flopping tests when stresstesting
the fail in the run, but then are OK when you run them again
samcv which ones? or just lots of them?
yeah i know what flopping tests are.
eveo Just in that file
samcv ah you're just saying "these files have dflopping tests"
gotcha
eveo k. that fixes the burn in Concurrent::File::Find 23:37
the burn with Event::Emitter looks to be just its own tests being racy and floppy 23:39
gonna run another toast run, just in case. The 2017.06 release is itching to be a lemon it seems :/ 23:41
ugexe whats wrong with pipe.t? 23:48
ugexe is still chasing gist.github.com/ugexe/50e9b6ec0a8d...39fc63dd6d and wonder if it could be related 23:49
on osx it always seems to work, but on a linux vm it fails 10-20 tests every time
eveo ugexe: irclog.perlgeek.de/perl6-dev/2017-...i_14746057 23:57
kinda sucks to release with that bug in, but I don't know how to fudge for it and proper fix will be done next week 23:58
s/fudge/kludge/

Powered by Cro and the Raku® Programming Language.

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

Thank you!