Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2017-06-17

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:22 japhb eveo: It worked!
00:22 japhb \o/
00:22 eveo \o/
00:59 eveo Well, this was awesomely painless. Converted toaster web app to Perl 5 and HEAD toast data is now available: https://toast.perl6.party/
01:00 eveo Conversion felt like it mostly involved inserting a load of $_-> and brackets and parens all over the place
01:02 eveo something's off with commit sorting ....
01:20 Geth ¦ rakudo/ugexe-patch-1: 575533866a | (Nick Logan)++ (committed using GitHub Web editor) | src/core/CompUnit/Repository/Installation.pm
01:20 Geth ¦ rakudo/ugexe-patch-1: Only slurp source file once during install
01:20 Geth ¦ rakudo/ugexe-patch-1: review: https://github.com/rakudo/rakudo/commit/575533866a
01:20 Geth ¦ rakudo: ugexe++ created pull request #1102: Only slurp source file once during install
01:20 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/1102
01:20 buggable joined #perl6-dev
01:23 buggable joined #perl6-dev
01:25 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.
01:25 eveo \o/
01:26 buggable joined #perl6-dev
01:26 eveo 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 https://toast.perl6.party/ for details.
01:29 Geth ¦ rakudo/nom: 575533866a | (Nick Logan)++ (committed using GitHub Web editor) | src/core/CompUnit/Repository/Installation.pm
01:29 Geth ¦ rakudo/nom: Only slurp source file once during install
01:29 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/575533866a
01:29 Geth ¦ rakudo/nom: aeffd00912 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/CompUnit/Repository/Installation.pm
01:29 Geth ¦ rakudo/nom: Merge pull request #1102 from rakudo/ugexe-patch-1
01:29 Geth ¦ rakudo/nom:
01:29 Geth ¦ rakudo/nom: Only slurp source file once during install
01:29 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/aeffd00912
01:49 ilbot3 joined #perl6-dev
01:49 Topic for #perl6-dev is now Perl 6 language and compiler development 2.0 | Logs at http://irclog.perlgeek.de/perl6-dev/today | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
01:55 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: https://gist.github.com/lizmat/063358317dc17a87d32f6d01de1c2687  :-)
01:55 MasterDuke .tell lizmat thanks, i hope to use that for coverable
01:55 yoleaux MasterDuke: I'll pass your message to lizmat.
02:02 eveo MasterDuke: https://github.com/zoffixznet/perl6-Toaster#viewing
02:03 MasterDuke thanks
02:04 eveo And you can get the database from https://temp.perl6.party/toast.sqlite.db if you need it
02:17 MasterDuke `<...>/perl6-Toaster/templates/404.html: No such file or directory`
02:18 eveo Hm, maybe forgot to add it. Just create a dummy file
02:19 eveo wget https://temp.perl6.party/404.html
02:19 eveo MasterDuke: oohhh
02:20 eveo MasterDuke: I've just converted it to Mojolicious. rm -fr templates; mv p6-templates templates
02:20 MasterDuke ah
03:09 geekosaur joined #perl6-dev
03:22 eveo too sleepy to hunt this race any longer
03:22 * eveo goes to bed
03:23 eveo Gonna eat this bug for breakfast instead. Nom nom nom!
04:09 Geth ¦ rakudo/nom: 1171e67e21 | (Nick Logan)++ (committed using GitHub Web editor) | src/core/CompUnit/PrecompilationStore/File.pm
04:09 Geth ¦ rakudo/nom: Skip calling .IO on path parts
04:09 Geth ¦ rakudo/nom:
04:09 Geth ¦ rakudo/nom: ...and use the `iso-8859-1` encoding name used in other CUR related modules
04:09 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1171e67e21
05:45 geekosaur joined #perl6-dev
06:22 [Tux] This is Rakudo version 2017.05-466-g1171e67e2 built on MoarVM version 2017.05-115-g369c0c5c
06:22 [Tux] csv-ip5xs        2.798
06:22 [Tux] test            12.726
06:22 [Tux] test-t           4.126 - 4.588
06:22 [Tux] csv-parser      12.855
06:46 geekosaur joined #perl6-dev
07:54 [TuxCM] joined #perl6-dev
08:30 sacomo joined #perl6-dev
08:59 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
09:14 pmurias joined #perl6-dev
09:15 pmurias $*VM seems undocumented and the tests only test for existence and not the result of various methods on it
09:15 pmurias any idea what I'm supposed to put in $*VM.properties on the JS backend?
09:20 Geth ¦ roast: c8680b49e1 | pmurias++ | S02-magicals/VM.t
09:20 Geth ¦ roast: [js] Skip test for a $*VM method I don't how how I'm supposed to implement
09:20 Geth ¦ roast: review: https://github.com/perl6/roast/commit/c8680b49e1
09:47 robertle joined #perl6-dev
09:56 robertle_ joined #perl6-dev
10:01 Geth ¦ rakudo/nom: 1acef38f68 | (Stefan Seifert)++ | src/core/CompUnit/PrecompilationRepository.pm
10:01 Geth ¦ rakudo/nom: Expand RAKUDO_MODULE_DEBUG output for diagnosing checksum issues
10:01 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1acef38f68
10:01 nine ~~
10:01 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: https://gist.github.com/zoffixznet/87541b1b135620a656595f18235238e0
10:03 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.
10:03 nine eveo: it doesn't
10:05 nine 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:06 nine 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:07 nine 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 nine It cannot rename the tmp file, because the precomp file is already open in a parent process.
10:08 nine eveo: so could you please try again with my above commit? Maybe the checksums give us another hint.
10:10 * eveo pulls and builds
10:13 dogbert17 nine: what could cause 'collect2: error: ld returned 1 exit status' when running 'zef install Inline::Perl5'?
10:13 eveo nine: here: https://gist.github.com/zoffixznet/a8baeeafc930c931e8f63af3f09a287a
10:14 dogbert17 and the important line: /usr/bin/ld: cannot find -lperl
10:15 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
10:15 dogbert17 -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
10:16 nine eveo: there! It gets two totally different checksums for the same source file
10:18 eveo Cool. How to fix it?
10:23 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 nine The latter two have been in use in CompUnit::Repository::Installation. The former is in CompUnit::PrecompilationRepository.
10:24 nine I'd guess the difference is with newline translation or maybe trailing newlines. Something that wouldn't matter anywhere else.
10:26 eveo nine++ damn
10:26 eveo Nice debugging :) Indeed there's a difference
10:27 eveo C:\rakudo>perl6 -e "dd 'foo'.IO.slurp: :enc<iso-8859-1>; dd 'foo'.IO.open(:enc<iso-8859-1>).slurp"
10:27 eveo "a\nb\n"
10:27 eveo "a\r\nb\r\n"
10:31 eveo now.. which one is the right answer? It IO::Handle.slurp seems to give "\r\n" for latin and "\n" for utf8
10:32 eveo and reading the sauce, in both cases `Rakudo::Internals::VMBackedDecoder.new($!encoding, :translate-nl)` appears to be called
10:34 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 nine Maybe we should just look at what rakudo did before jnthn's IO refactor?
10:35 nine I don't think he meant to change any semantics there
10:35 eveo ok
10:35 * eveo builds 2017.04.3
10:39 nine dogbert17: is there a libperl.so in /usr/lib/perl/5.18/CORE?
10:48 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
10:48 * eveo doesn't understand this
10:48 nine dogbert17: are you just missing a perl-dev or perl-devel or whatever package?
10:49 * dogbert17 checks
10:50 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:54 dogbert17 nine: can't find any package with a similar name in Synaptic (running Linux Mint)
10:55 eveo k, well, I'm gonna go with "slower but righter" then, for now
11:01 nine dogbert17: sorry, the directory structure in http://mirrors.advancedhosters.com/linuxmint/packages/ makes zero sense to me.
11:02 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: https://gist.github.com/zoffixznet/d41f7380da254ec3f26943dd32cff23a
11:02 nine With a sensible directory structure like openSUSE's you can just go to http://download.opensuse.org/distribution/leap/42.2/repo/oss/suse/x86_64/ and ctrl+f through the package list
11:02 eveo Oh, OK, nevermind then
11:02 nine dogbert17: then I guess Mint's perl package is broken and you should report that.
11:04 dogbert17 perhaps I should try a newer version of Mint first, the one I have is quite old
11:05 eveo ZOFFLOP: t/spec/S11-modules/nested.t
11:12 Geth ¦ rakudo/nom: 446dc190e5 | (Elizabeth Mattijsen)++ | src/core/Range.pm
11:12 Geth ¦ rakudo/nom: Make ^Inf marginally faster
11:12 Geth ¦ rakudo/nom:
11:12 Geth ¦ rakudo/nom: ++$i is faster than $i++
11:12 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/446dc190e5
11:15 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? https://irclog.perlgeek.de/perl6/2017-06-17#i_14745784
11:16 eveo jnthn: morning
11:16 eveo jnthn: do you fancy hunting a race? :)
11:17 jnthn The only changes in procops.c in that commit range are adding support for bind-std*
11:17 jnthn I can't think of any way the .kill code could have changed in the last month
11:17 jnthn What's the race?
11:17 eveo OK. Maybe it's just a fluke in reporter's test code.
11:18 jnthn Well, it's also possible there was always a problem with it
11:19 jnthn Guess could always strace and see what signals it actually sends
11:21 jnthn Ah, I think the latin-1 problem is that it doesn't actually go through the decodestream mechanism
11:21 jnthn oops
11:21 jnthn Through the normalizer mechanism I meant
11:22 jnthn 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: https://gist.github.com/zoffixznet/440cf8f7131632aa673b75dbb3a625b3  and I added some debug prints https://gist.github.com/zoffixznet/a8c5f2eb3ca064044bbb04e947a3291b  and the output from them is https://gist.github.com/zoffixznet/3351870822c4e2a54117e296121ab9a6  So the supply
11:22 eveo sequencer seems to be missing one call in the failing case
11:22 jnthn That also doesn't seem to be a regression, but it certainly wants a fix
11:23 jnthn eveo: There's already an RT asking for that to be done totally differently anyway
11:23 eveo OK
11:23 jnthn So I'm not inclined to spend time on the current code for it.
11:23 eveo Alright
11:23 jnthn When it's getting tossed in the next week or so
11:23 jnthn Hopefully not a blocker?
11:23 eveo jnthn: and for the translate-nl thing... it only supposed to happen on utf8?
11:24 jnthn No, it's supposed to happen on everything, but latin-1 takes a shortcut
11:24 jnthn And misses the place where it happens
11:24 eveo oh
11:24 jnthn Just been looking at the code and seen why
11:24 lizmat afk&
11:24 eveo That's a blocker.
11:25 jnthn Why? It's not a regression, it's been like that for months.
11:25 jnthn I mean, I can put in a quick fix for it, but I hate doing those right before releases.
11:27 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 eveo I actually already got a commit locally doing that
11:27 jnthn Ah, ok
11:28 jnthn Wait, which one is correct?
11:28 eveo IO::Path.slurp
11:28 eveo C:\rakudo>perl6 -e "dd 'foo'.IO.slurp: :enc<iso-8859-1>; dd 'foo'.IO.open(:enc<iso-8859-1>).slurp"
11:28 eveo "a\nb\n"
11:28 eveo "a\r\nb\r\n"
11:28 llfourn perl
11:28 eveo It decodes manually and got a .substr on it
11:29 llfourn (wrong window)
11:29 jnthn Ah, right
11:29 eveo while IO::Handle.slurp goes throw vmdecoder newline translator
11:29 jnthn .subst?
11:29 eveo .subt yeah
11:29 jnthn Yeah, but we went through that decoder in previous releases too
11:29 jnthn But maybe IO::Path.slurp was wrong also then
11:30 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 eveo "a\r\nb\r\n"
11:30 eveo "a\r\nb\r\n"
11:30 eveo In past releases yeah, it was.
11:30 eveo ^ that's 2017.04.3
11:30 eveo So I was gonna make it ^ like that again, to unbust precomp
11:31 jnthn Hm, so the inconsistency somehow busts precomp?
11:31 jnthn Oddness
11:31 eveo Yeah, in one place CompUnit code uses one .slurp and in the other, the other
11:31 eveo And actually now there's a thrid place, that decodes manually
11:31 eveo This one https://github.com/rakudo/rakudo/commit/575533866a816c7fd5c55451ea43d458a2ef0247
11:32 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
11:32 jnthn Now it all makes sense :)
11:32 Geth ¦ nqp/master: 7 commits pushed by pmurias++
11:32 Geth ¦ nqp/master: 43556764af | [js] Fix nqp::ctxcallerskipthunks
11:32 Geth ¦ nqp/master: 6500a4df15 | Test serializing a nqp::list_n
11:32 Geth ¦ nqp/master: 281f827877 | [js] Decontainerize the result of Str when stringifying
11:32 Geth ¦ nqp/master: 8a0388f37b | [js] Delete empty unused file
11:32 Geth ¦ nqp/master: 727b2f59c6 | [js] Use seperate types for nqp::list_s, nqp::list_n and nqp::list_i
11:32 Geth ¦ nqp/master: 7e4d32edac | Test that lowlevel typed lists don't get hllizied
11:32 Geth ¦ nqp/master: e66b737980 | [js] Decont the result of the boolification method like the JVM does
11:32 Geth ¦ nqp/master: review: https://github.com/perl6/nqp/compare/f6459b6d4d...e66b737980
11:32 nine The only reason for using latin-1 is cause nqp::sha1 requires a string
11:32 jnthn I've got a slightly hacky patch to address it for latin-1
11:33 jnthn nine: Oh, so we could get faster precomp if we could sha1 a buffer? :)
11:34 nine Probably yes. Probably even faster and with lower memory usage if we could give it a file handle
11:39 jnthn Now I've got a less hacky patch and applied it for the ascii and windows-blah encoding too
11:41 jnthn eveo: Committed as MoarVM a0992f3872
11:41 eveo cool. Thanks
11:44 jnthn eveo: I'll hold off on doing the MoarVM release until I hear all's good
11:45 eveo hm, precomp is still broken, but now I think it might be https://github.com/rakudo/rakudo/commit/575533866a816c7fd5c55451ea43d458a2ef0247
11:45 * eveo reverts it and builds
11:46 eveo the .slurps are the same now tho
11:50 eveo still crashes with same problem
11:50 * eveo tries re-installing zef
11:51 eveo \o/
11:51 eveo jnthn: yup. Fixed now
11:51 jnthn Phew :)
11:51 jnthn eveo++
11:52 hankache joined #perl6-dev
11:52 * jnthn bbl
12:01 travis-ci joined #perl6-dev
12:01 travis-ci NQP build failed. pmurias '[js] Decont the result of the boolification method like the JVM does
12:01 travis-ci https://travis-ci.org/perl6/nqp/builds/243962279 https://github.com/perl6/nqp/compare/f6459b6d4d76...e66b737980ea
12:01 travis-ci left #perl6-dev
12:02 lizmat sometimes I think we need something like: sub cue(|c) { $*SCHEDULER.cue(|c) }
12:03 lizmat so you could say cue { }, :in(5);   instead of the wordy $*SCHEDULER.cue: { }, :in(5);
12:06 * eveo never used cue in code...
12:08 eveo 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
12:08 eveo m: my $*foo; $*SCHEDULER.cue( { say $*foo }, :in(1) ); sleep 2
12:09 camelia rakudo-moar 446dc1: OUTPUT: «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
12:09 camelia rakudo-moar 446dc1: OUTPUT: «(Any)␤»
12:09 lizmat eveo jnthn: ok, good points
12:10 lizmat it's just too bad that we don't expose :every and :times functionality  :-(
12:11 jnthn Supply.interval for :every
12:11 jnthn Add .head for times
12:11 lizmat anyways, afk for a bit of schlepping&
12:12 jnthn Yup, and lunch making here :)
12:12 eveo ZOFFLOP: t/spec/S17-procasync/kill.t
12:12 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 :)
12:14 eveo jnthn: I think I'm happy right now
12:14 Geth ¦ rakudo/nom: 222b4083c9 | (Zoffix Znet)++ | src/core/Buf.pm
12:14 Geth ¦ rakudo/nom: Make invocation of Blob.decode() 2.7x faster
12:14 Geth ¦ rakudo/nom:
12:14 Geth ¦ rakudo/nom: - We don't need to normalize encoding when we already know what it is
12:14 Geth ¦ rakudo/nom: - The 2.7x speedup is for short strings and by 10_000-char strings
12:14 Geth ¦ rakudo/nom:     gets drowned by the decode operation
12:14 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/222b4083c9
12:14 eveo jnthn: so anytime you're free, cut it :)
12:22 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 dogbert17 OTOH, it's been like this for quite some time so I don't think any recent refactors are to blame
12:25 eveo ZOFFLOP: t/spec/S10-packages/precompilation.
12:25 Geth ¦ nqp: ed1a5d868a | (Zoffix Znet)++ | tools/build/MOAR_REVISION
12:25 Geth ¦ nqp: Bump MoarVM
12:25 Geth ¦ nqp:
12:25 Geth ¦ nqp: MoarVM bump brought commits:
12:25 Geth ¦ nqp: https://github.com/MoarVM/MoarVM/compare/2017.05-115-g369c0c5...2017.05-116-ga0992f3
12:25 Geth ¦ nqp:
12:25 Geth ¦ nqp: a0992f3 Fix newline translation in various encodings.
12:25 Geth ¦ nqp: review: https://github.com/perl6/nqp/commit/ed1a5d868a
12:25 Geth ¦ nqp: version bump brought these changes: https://github.com/MoarVM/MoarVM/compare/2017.05-115-g369c0c5...2017.05-116-ga0992f3
12:25 Geth ¦ rakudo/nom: 369f2511a6 | (Zoffix Znet)++ | tools/build/NQP_REVISION
12:25 Geth ¦ rakudo/nom: Bump NQP
12:25 Geth ¦ rakudo/nom:
12:26 Geth ¦ rakudo/nom: NQP bump brought commits:
12:26 Geth ¦ rakudo/nom: https://github.com/perl6/nqp/compare/2017.05-192-gf6459b6...2017.05-200-ged1a5d8
12:26 Geth ¦ rakudo/nom:
12:26 Geth ¦ rakudo/nom: ed1a5d8 Bump MoarVM
12:26 Geth ¦ rakudo/nom: e66b737 [js] Decont the result of the boolification method like the JVM does
12:26 Geth ¦ rakudo/nom: <…commit message has 13 more lines…>
12:26 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/369f2511a6
12:26 Geth ¦ rakudo/nom: version bump brought these changes: https://github.com/perl6/nqp/compare/2017.05-192-gf6459b6...2017.05-200-ged1a5d8
12:36 Geth ¦ star: 0ee2ebdf7e | (Steve Mynott)++ | 3 files
12:36 Geth ¦ star: native resources no longer used by linenoise
12:36 Geth ¦ star: review: https://github.com/rakudo/star/commit/0ee2ebdf7e
12:36 eveo nqp JVM fails "java.lang.RuntimeException: Unimplemented case of read_ref"
12:36 eveo More output: https://gist.github.com/zoffixznet/d2d29a4e58c8b49d66112cfce54ee6c8
12:40 eveo m: class Foo { method x(str $y) {} }; dd Foo.^lookup('x').cando: \(Foo, my str $ = 'x')
12:40 camelia rakudo-moar 369f25: OUTPUT: «()␤»
12:40 eveo Looks like something's busted with .cando and native params
12:40 eveo (been for  awhile)
12:42 eveo holy crap!
12:42 eveo ZOFVM: Files=1254, Tests=139499, 102 wallclock secs (13.84 usr  2.66 sys + 1542.68 cusr 304.13 csys = 1863.31 CPU)
12:42 eveo This might be fastest run ever :) Almost up to double-digits :)
12:45 eveo Filed cando thing as https://rt.perl.org/Ticket/Display.html?id=131590
12:49 pmurias eveo: re JVM fail, a newly added test fails :/ I'll look into fixing the JVM backend up
12:50 stmuk perlpilot: I just ran across https://github.com/perlpilot/Grammar-Profiler-Simple/issues/6 and there is a PR open claimed to fix it
12:52 stmuk the debugger is still broken I see ..
12:54 eveo Heh grep accepts `-nerd` as commandline options
12:54 eveo stmuk: it is, yeah
12:54 eveo Was hoping to fix for this realease, but no time
12:54 eveo stmuk: R* release is next month, not this month, right?
12:55 eveo huggable: star
12:55 huggable eveo, Estimated Rakudo Star releases for 2017: .01, .04, .07 & .10
12:55 stmuk eveo: yes .. I was just doing a dry run of some R* modules
12:55 stmuk ++evo
12:56 eveo `cool
13:04 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:07 eveo ZOFFLOP: t/spec/S17-promise/nonblocking-await.t
13:07 eveo ZOFFLOP: t/spec/S17-supply/syntax.t
13:08 travis-ci joined #perl6-dev
13:08 travis-ci NQP build failed. Zoffix Znet 'Bump MoarVM
13:08 travis-ci https://travis-ci.org/perl6/nqp/builds/243970661 https://github.com/perl6/nqp/compare/e66b737980ea...ed1a5d868ad4
13:08 travis-ci left #perl6-dev
13:08 Geth ¦ rakudo/nom: a5be845438 | (Zoffix Znet)++ | src/core/CompUnit/Repository/Installation.pm
13:08 Geth ¦ rakudo/nom: Fix Windows precomp checksum mismatch issue
13:08 Geth ¦ rakudo/nom:
13:08 Geth ¦ rakudo/nom: The .slurp we're using elsewhere in the CompUnit code translates newlines,
13:08 Geth ¦ rakudo/nom: so we need to do the same here, where we're decoding manually.
13:08 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a5be845438
13:13 eveo BAHA!
13:13 eveo ZOFVM: Files=1254, Tests=139499, 93 wallclock secs (14.59 usr  2.67 sys + 1635.43 cusr 170.64 csys = 1823.33 CPU)
13:14 eveo Just look it at! Look at that 93 secs stresstest run!
13:16 Geth ¦ rakudo/nom: 46eecdae8a | (Zoffix Znet)++ | src/core/Distro.pm
13:16 Geth ¦ rakudo/nom: Micro-opt .subst call in INITIALIZE-A-DISTRO-NOW
13:16 Geth ¦ rakudo/nom:
13:16 Geth ¦ rakudo/nom: We don't need to use a regex here and Str matcher with :g will fast-path
13:16 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/46eecdae8a
13:18 Geth ¦ rakudo/nom: 6788833bb8 | (Zoffix Znet)++ | src/core/IO/Path.pm
13:18 Geth ¦ rakudo/nom: Optimize newline translation in IO::Path.slurp
13:18 Geth ¦ rakudo/nom:
13:18 Geth ¦ rakudo/nom: instead of going through .subst, do the same work with nqp ops in place.
13:18 Geth ¦ rakudo/nom: This change to translation is 55x faster for empty strings and
13:18 Geth ¦ rakudo/nom: diminishes to a wash by the time we do 12_000-char strings.
13:18 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/6788833bb8
13:18 * eveo does another stresstest run to ensure it wasn't a fluke :P
13:18 nine Oh, there's still a difference between reading binary and latin-1 on reading the ∖ character (set difference)
13:20 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 rakudo-moar 369f25: OUTPUT: «"â\x[88]\x[96]"␤"â\x[88]\x[96]"␤"â\x[88]\x[96]"␤"â\x[88]\x[96]"␤»
13:20 eveo looks same to me
13:21 eveo ZOFFLOP: t/spec/S11-modules/require.t
13:21 eveo all this floppiness isn't very nice
13:22 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'
13:22 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
13:23 eveo nine: did you upgrade to include latest nqp bump to fix the difference between ::Handle.slurp and ::Path.slurp?
13:24 eveo nine: oh wait. No upgrade neede. ::Path.slurp translates newlines. Are you doing that in binary?
13:24 eveo Oh wait. You're not on Windows :)
13:25 * 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.
13:25 eveo Weird
13:25 eveo How come there's no difference in my eval above tho?
13:25 nine eveo: you're ecoding in every case
13:26 eveo ah
13:27 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: "latin-1" }
13:27 camelia rakudo-moar 369f25: OUTPUT: «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␤␤»
13:27 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 }
13:27 camelia rakudo-moar 369f25: OUTPUT: «Blob[uint8].new(226,136,150)␤Buf[uint8].new(226,136,150)␤Blob[uint8].new(226,136,150)␤Buf[uint8].new(226,136,150)␤»
13:27 nine There you see the difference! Err....
13:28 eveo I see type difference but not the bytes
13:28 eveo ZOFVM: Files=1254, Tests=139499, 109 wallclock secs (20.01 usr  3.19 sys + 2170.54 cusr 154.49 csys = 2348.23 CPU)
13:28 eveo 93s was a fluke :/
13:29 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
13:29 eveo fixes for bugs that existed already
13:31 * eveo runs another toaster run
13:34 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:44 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
13:44 jnthn cah
13:44 jnthn eveo: ^^
13:46 jnthn 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
13:47 eveo jnthn: (not sure if you saw above). You can cut MoarVM anytime you're readyt
13:48 jnthn Can't it just quickly check it got no options?
13:48 eveo s: '', 'subst', \(:g, '', '')
13:48 SourceBaby eveo, Sauce is at https://github.com/rakudo/rakudo/blob/6788833/src/core/Str.pm#L1142
13:49 eveo Not sure how to make it any faster there
13:49 eveo And Rakudo::Internals.TRANSPOSE's guts is the code I used in 6788833bb8
13:51 lucasb joined #perl6-dev
13:52 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/
13:53 * eveo afk for a bit
13:54 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:56 lizmat jnthn: re Str.subst(Str), faster than: nqp::join($final,nqp::split($original,$string)) ??
14:10 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
14:10 lizmat the only gain there is the cost of the named parameter handling
14:11 lizmat *could be
14:11 lizmat *reducing
14:11 jnthn Yeah, but we could decide that with multi-dispatch instead :)
14:11 lizmat yeah, I've worked on that already, but it becomes huge
14:11 lizmat and as soon as regexes come into play, any gains are dwarved by the regex engine overhead
14:12 lizmat so I abandoned that for the time being
14:12 jnthn This is the non-regex case, though :)
14:12 jnthn But yeah, fair enough
14:12 jnthn Also until this week, spesh was less good at dealing with named parameters
14:12 jnthn So the costs may have shifted a bit too
14:12 lizmat jnthn: the point is that you cannot really handle 5 optional named parameters in dispatch
14:13 lizmat as we don't have a signature for "no other named parameters"
14:13 lizmat if we would have that, something like:
14:13 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
14:13 lizmat multi sub a(:$foo!, :!%_)
14:15 eveo m: for ^100_000 { $ = 'fobar'.subst: 'b', 'x'; }; say now - INIT now
14:15 camelia rakudo-moar 678883: OUTPUT: «13.9065733␤»
14:15 eveo m: for ^100_000 { $ = 'fobar'.subst: :g, 'b', 'x'; }; say now - INIT now
14:15 camelia rakudo-moar 678883: OUTPUT: «0.75058546␤»
14:15 lizmat eveo: good point, will fix in a mo
14:17 lizmat spectesting now
14:22 cognominal joined #perl6-dev
14:24 Geth ¦ rakudo/nom: 0331fb9d50 | (Elizabeth Mattijsen)++ | src/core/Str.pm
14:24 Geth ¦ rakudo/nom: Fastpath Str.subst(Str) without :g as well
14:24 Geth ¦ rakudo/nom:
14:24 Geth ¦ rakudo/nom: Spotted by Zoffix++
14:24 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/0331fb9d50
14:25 lizmat m: say "foo".subst(Str,Str)
14:25 camelia rakudo-moar 678883: OUTPUT: «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…»
14:31 lizmat ^^^ makes Str.subst(Str:D,Str:D) about 12x faster
14:31 lizmat m: for ^100_000 { $ = 'fobar'.subst: 'b', 'x'; }; say now - INIT now
14:31 camelia rakudo-moar 0331fb: OUTPUT: «0.9400674␤»
14:32 lizmat m: say 13.9065733 / 0.9400674
14:32 camelia rakudo-moar 0331fb: OUTPUT: «14.79316621␤»
14:32 lizmat actually looks to be more :-)
14:38 lizmat afk&
14:44 eveo cool :) lizmat++
14:46 stmuk this is odd on OpenBSD/moar say $*KERNEL.signal("SIGHUP") returns 2 .. whereas say $*KERNEL.signal(SIGHUP) correctly returns 1
14:47 eveo m: dd [$*KERNEL.signal("SIGHUP"), $*KERNEL.signal(SIGHUP) ]
14:47 camelia rakudo-moar 0331fb: OUTPUT: «[1, 1]␤»
14:47 eveo stmuk: what does dd say $*KERNEL.signals give you?
14:47 eveo m: dd $*KERNEL.signal
14:47 camelia rakudo-moar 0331fb: OUTPUT: «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…»
14:48 eveo m: dd $*KERNEL.signals
14:48 camelia rakudo-moar 0331fb: OUTPUT: «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…»
14:51 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 eveo 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
14:51 eveo RTMAX-2 RTMAX-1 RTMAX)
14:53 stmuk > dd $*KERNEL.signals
14:53 stmuk Array @!signals = [Any, Any, Signal::SIGHUP,
14:53 stmuk ..snip
14:54 eveo Wonder if it was broken by this commit: https://github.com/rakudo/rakudo/commit/79b8ab9d3f9a5499e8a7859f34b4499fb352ac13
14:55 stmuk > qx!kill -l!.words.say
14:55 stmuk (1 HUP Hangup 17 STOP Suspended (signal) 2 INT
14:55 stmuk ..snip
14:57 eveo hm, OK, so looks like it was busted up already before
14:59 dogbert17 m: NFC.new
14:59 camelia rakudo-moar 0331fb: OUTPUT: «Cannot create an NFD directly␤  in block <unit> at <tmp> line 1␤␤»
15:04 eveo s: NFC, 'new', \()
15:04 SourceBaby eveo, Sauce is at https://github.com/rakudo/rakudo/blob/6788833/src/core/Uni.pm#L104
15:05 Geth ¦ rakudo/nom: e824266fd5 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Uni.pm
15:05 Geth ¦ rakudo/nom: Fix copy-pastoed type name in error messages; dogbert17++
15:05 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/e824266fd5
15:08 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 https://toast.perl6.party/ for details.
15:08 eveo ^ results for HEAD~2
15:09 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?
15:10 eveo kill -l prints human-friendly stuff if I run it from terminal
15:10 stmuk ah its calling the ksh kill!
15:10 [TuxCM] joined #perl6-dev
15:14 stmuk qx!/bin/kill -l!.words.say is correct
15:16 mst heh, and 'man kill' even mentions the problem of an inferior built-in
15:16 mst (I didn't know -l existed so went RTFMing)
15:18 stmuk eveo: human friendly is probably a shell built in kill
15:23 eveo stmuk: you could fix it for openbsd: https://github.com/rakudo/rakudo/blob/nom/src/core/Kernel.pm#L104-L132
15:24 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 :/
15:25 eveo wonder where that's from...
15:25 eveo ohhh...
15:26 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 nine eveo: seen the same message in Inline::Perl5's travis output
15:26 eveo Yeah, something's got busted up. just running `zef` gives me that
15:27 eveo nine: you could remove "language perl6". It's installed by default: https://docs.travis-ci.com/user/languages/perl6
15:36 eveo Ah, ok, I see the problem
15:36 eveo Wow, tests not catching it is scary :/
15:39 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 stmuk s/exit/exist/
15:40 stmuk its in the Filesystem Hierarchy Standard
15:41 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:42 stmuk ok I'll just special case OpenBSD (as is done already for other systems)
15:42 stmuk the ubuntu fix looks very hacky :)
15:43 btyler joined #perl6-dev
15:46 mst eveo: I have the same issue with bash on debian
15:47 mst so I suspect actually /bin/kill everywhere is a good idea
15:47 mst there's probably other environments that have this bug
15:53 Geth ¦ rakudo/nom: fb50f49611 | (Zoffix Znet)++ | src/core/Rakudo/Internals.pm
15:53 Geth ¦ rakudo/nom: Fix regression in Str.subst(Str:D, Str:D)
15:53 Geth ¦ rakudo/nom:
15:53 Geth ¦ rakudo/nom: The TRANSPOSE-ONE routine uses incorrect string's length to figure out
15:53 Geth ¦ rakudo/nom: where to cut off the replaced piece.
15:53 Geth ¦ rakudo/nom:
15:53 Geth ¦ rakudo/nom: Also fixes issues with generated wrappers for binaries.
15:53 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/fb50f49611
15:53 Geth ¦ roast: a80a064e3c | (Zoffix Znet)++ | S05-substitution/subst.t
15:53 Geth ¦ roast: Test Str.subst(Str:D, Str:D)
15:53 Geth ¦ roast:
15:53 Geth ¦ roast: Rakudo fix: https://github.com/rakudo/rakudo/commit/fb50f49611
15:53 Geth ¦ roast: review: https://github.com/perl6/roast/commit/a80a064e3c
15:54 * eveo re-runs update-perl6
15:57 stmuk I probably shouldn't be trying to dev on a Celeron N2840 :/
16:09 eveo ===> Extraction [OK]: JSON::Name to /home/zoffix/.zef/store/JSON-Name.git
16:09 eveo Invalid json? File: /home/zoffix/.zef/store/Inline-Perl5-0.27.tar.gz/Inline-Perl5-0.27/Build.pm
16:09 eveo I've seen that before recently.... We didn't fix it, did we?
16:10 ugexe weird... wonder how thats getting fed to a from-json call
16:12 eveo Dies repeatedly, so I guess that's another release blocker?
16:12 eveo or again, I guess
16:13 eveo Full error: https://gist.github.com/zoffixznet/8510de8ffce42adc2afff7762d7cb03e
16:13 Geth ¦ rakudo: stmuk++ created pull request #1103: Fix t/spec/S02-magicals/KERNEL.t on OpenBSD
16:13 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/1103
16:14 nebuchadnezzar joined #perl6-dev
16:20 Geth ¦ rakudo/nom: 8f1651f798 | (Steve Mynott)++ | src/core/Kernel.pm
16:20 Geth ¦ rakudo/nom: Fix t/spec/S02-magicals/KERNEL.t on OpenBSD
16:20 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8f1651f798
16:20 Geth ¦ rakudo/nom: f9ca0b2e1a | (Steve Mynott)++ | src/core/Kernel.pm
16:20 Geth ¦ rakudo/nom: changed to self.name following code review
16:20 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/f9ca0b2e1a
16:20 Geth ¦ rakudo/nom: 9435c14eb3 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Kernel.pm
16:20 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
16:20 Geth ¦ rakudo/nom: Merge pull request #1103 from stmuk/nom
16:20 Geth ¦ rakudo/nom:
16:20 Geth ¦ rakudo/nom: Fix t/spec/S02-magicals/KERNEL.t on OpenBSD
16:20 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/9435c14eb3
16:24 pmurias eveo: I wrap the harder to fixed tests with an if
16:27 eveo ugexe: is there a way to make zef run with --ll-exception perl6?
16:28 pmurias eveo: I fear if we stop fixing up the jvm backend stuff will diverge too much and it will be abandoned :/
16:29 ugexe only run zef --help, chop off the basename and last path part, add bin/zef, and run with perl6 --ll-exception
16:29 ugexe (chop off basename/path part from the config file path shown)
16:29 mst pmurias: that kinda worries me too
16:29 eveo cool
16:30 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:31 Geth ¦ nqp: 9b11c1a078 | pmurias++ | src/vm/js/nqp-runtime/core.js
16:31 Geth ¦ nqp: [js] Make nqp::sech_n work the same as on other backends in an edge case
16:31 Geth ¦ nqp: review: https://github.com/perl6/nqp/commit/9b11c1a078
16:31 Geth ¦ nqp: 6a5d316518 | pmurias++ | t/serialization/01-basic.t
16:31 Geth ¦ nqp: [jvm] Fixup test
16:31 Geth ¦ nqp: review: https://github.com/perl6/nqp/commit/6a5d316518
16:37 ugexe eveo: seems related to the new version of Inline::Perl5.... `zef install "Inline::Perl5:ver<0.26>"` still works
16:37 eveo Oh
16:38 Geth ¦ nqp: 8132519655 | pmurias++ | t/serialization/01-basic.t
16:38 Geth ¦ nqp: Avoid manually numbering tests
16:38 Geth ¦ nqp: review: https://github.com/perl6/nqp/commit/8132519655
16:38 eveo I don't get how Build.pm ends up coming up from a routine that looks for metafiles tho
16:38 eveo And the same error existed 1 or 2 days ago
16:39 ugexe maybe if you were fetching inline::perl5 from github
16:39 ugexe which would be HEAD and not 0.16
16:39 ugexe 0.26
16:40 BenGoldberg joined #perl6-dev
16:41 eveo weird. it just switches to 0.27 in the middle of the install process: https://gist.github.com/zoffixznet/07cf59226e172472f0481eb728d1dd2e
16:43 eveo ugexe: this also works: zef --/cpan --/cached --debug install Inline::Perl5
16:45 eveo 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
16:46 ugexe wonder if Inline::Perl5 is .tar.gz incorrectly
16:47 ugexe compare against 0.26
16:47 ugexe there is extra stuff in the root directory (that is also in the correct first subdir)
16:53 ugexe yep
16:53 ugexe zef install https://github.com/niner/Inline-Perl5/archive/master.tar.gz
16:53 ugexe works
16:53 ugexe 0.27's .tar.gz archive is not the standard format
16:54 ugexe nine: ^
17:08 ugexe wonder if the inclusion of that manifest made cpan re-tar it differently than before, or if it was just an accident
17:13 stmuk joined #perl6-dev
17:41 nine ugexe: what do you mean by "not the standard format"?
17:49 travis-ci joined #perl6-dev
17:49 travis-ci NQP build passed. pmurias '[jvm] Fixup test'
17:49 travis-ci https://travis-ci.org/perl6/nqp/builds/244017602 https://github.com/perl6/nqp/compare/ed1a5d868ad4...6a5d316518bf
17:49 travis-ci left #perl6-dev
17:56 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:57 ugexe installation on linux failed, but works if i use a github .tar.gz of inline::Perl:ver<0.27>
17:58 ugexe and standard format i mean inside the archive is a single folder which contains everything else
17:58 d4l3k_ joined #perl6-dev
17:59 ugexe but this has copies of some subfolders alongside (what is supposed to be) the single folder
18:01 nine ugexe: I don't see that here, neither in the original .tar.gz nor in the one I downloaded from CPAN :/
18:01 nine It may be some weird GNU tar extension
18:04 ugexe https://gist.github.com/ugexe/f06fe6b58854f3ab237556aafc287835
18:05 ugexe nine: this shows the problem as far as zef is concerned
18:07 geekosaur looks like a version of tar that doesn't store directories
18:10 ugexe fwiw that gist is the same for both bsd and gnu tar
18:12 geekosaur ah, right. how is this being created?
18:12 geekosaur because this is v7 tar format
18:12 geekosaur which did not store directories
18:12 geekosaur extracting it needs to be told that, or it will not create directories
18:13 ugexe well nine presumably does it manually, but cpan also re-archives it I think?
18:17 travis-ci joined #perl6-dev
18:17 travis-ci Rakudo build failed. Zoffix Znet 'Optimize newline translation in IO::Path.slurp
18:17 travis-ci https://travis-ci.org/rakudo/rakudo/builds/243980050 https://github.com/rakudo/rakudo/compare/46eecdae8aea...6788833bb831
18:17 travis-ci left #perl6-dev
18:17 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.
18:20 ugexe this could also be fixed in zef, but we should still figure out why this happened in the first place
18:23 ugexe 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:24 ugexe e.g. figuring out where it will be extracted to before extracting it
18:25 geekosaur well, having directories in the archive at all is not portable
18:26 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
18:26 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
18:28 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:29 geekosaur 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
18:29 ugexe as in thats why it didnt get included all of a sudden
18:29 nine ugexe: I guess it's because I used the --transform option to store the files in a sub directory
18:32 nine ugexe: do you see any weirdness in this archive? http://niner.name/files/Inline-Perl5-0.27.tar.gz
18:32 ugexe i wonder why 7zip trips up so badly on it
18:37 ugexe nine: `zef --/wget install http://niner.name/files/Inline-Perl5-0.27.tar.gz` worked and the tar --list output looked like 0.26
18:37 ugexe why I had to --/wget I dont know lol... it just freezes up
18:42 ugexe nine: `wget http://niner.name/files/Inline-Perl5-0.27.tar.gz` doesnt work heh
18:42 ugexe everything else works with it from what i can tell though
18:43 ugexe probably an ip6 thing
18:45 ugexe yeah... `wget -4 http://niner.name/files/Inline-Perl5-0.27.tar.gz` works
18:52 dogbert17_ joined #perl6-dev
18:52 chansen_ joined #perl6-dev
18:52 ugexe 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:53 ugexe e.g. does the second .protect lock the first .protect?
18:53 nine yes
18:54 travis-ci joined #perl6-dev
18:54 travis-ci NQP build passed. pmurias 'Avoid manually numbering tests'
18:54 travis-ci https://travis-ci.org/perl6/nqp/builds/244019387 https://github.com/perl6/nqp/compare/6a5d316518bf...8132519655c4
18:54 travis-ci left #perl6-dev
18:54 nine So should I release an Inline::Perl5 0.28 with a fixed tar file?
18:54 ugexe awesome, i saw all the code in CUR that implied such but I didn't know it worked like that
18:55 nine Well src/core/Lock.pm is just 32 very readable lines :)
18:56 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:57 nine File successfully copied to '/home/ftp/incoming/Inline-Perl5-0.28.tar.gz'
19:00 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:01 nine ugexe: https://github.com/jnthn/oo-monitors
19:01 nine Ah, that's per method
19:02 ugexe I suppose a proxy would work
19:04 ugexe then again i remember proxy reads a bunch of times per access, which would probably make that super slow
19:04 ugexe ...or deadlock heh
19:06 ugexe I also probably need to expand that a bit to also allow a file lock type .protect
19:21 BenGoldberg joined #perl6-dev
19:32 lizmat eveo: good spot on the TRANSPOSE-ONE
19:32 lizmat turns out I wrote it a long time ago, but never used it internally
19:41 dogbert17 lizmat: just added this, https://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
19:41 lizmat *mo
19:42 dogbert17 moritz has already helped out but perhaps there are more differences
19:46 BenGoldberg It feels like all of those methods ought to be a single 'map' method, differentiated by :deep, :node, :duck
19:56 * lizmat is still trying to grok deep node and duck
19:58 lizmat TIL I learned the difference between map and nodemap: handling of slips
19:59 * dogbert17 quacks
19:59 ugexe https://gist.github.com/ugexe/50e9b6ec0a8db2f85339dc39fc63dd6d - heres a failing test, but not sure where to submit it since it will deadlock on rakudos prior to 2017.06
20:07 ugexe when its incorrect the total size ends up being a few different values but some repeat more than others (like 262144)
20:08 ugexe its always an even number
20:09 geekosaur is it always a *power* of 2?
20:10 geekosaur 262144 = 0x40000
20:16 dct joined #perl6-dev
20:17 ugexe no - although some other less-occuring values have been 131072, 700672, 591040
20:23 lucasb joined #perl6-dev
20:25 ugexe any idea how to at least tell if its the input or output thats getting lost?
20:32 geekosaur replace «cat -» with «dd»
20:32 geekosaur it will output summary statistics on stderr
20:32 lizmat m: for ^100000 { 42 ~~ /^ <[0..9]> / }; say now - INIT now
20:32 camelia rakudo-moar 9435c1: OUTPUT: «1.1948762␤»
20:32 lizmat m: for ^100000 { 42 ~~ m/^ <[0..9]> / }; say now - INIT now   # what a difference a letter maketh
20:32 geekosaur you may also want to experiment with the ibs and obs options, which might reveal buffering issues
20:33 camelia rakudo-moar 9435c1: OUTPUT: «9.173497␤»
20:33 lizmat m: say 9.173497 / 1.1948762
20:33 camelia rakudo-moar 9435c1: OUTPUT: «7.67736189␤»
20:37 lizmat looks like the m// version calls Str.match
20:53 lizmat .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].
20:55 jnthn Is there any reason we can't fix that in the compiler? :)
20:57 lizmat jnthn: there may be a subtle difference about $/ being set / not set
20:57 jnthn Hm, OK
20:57 lizmat lemme check
20:58 lizmat hmmm... no, that's not it
20:59 lizmat looks like // calls Regex.ACCEPTS directly, and m// goes through Str.match
20:59 lizmat anyways, keeping that until *after* the release for sure
20:59 * lizmat already got burnt once today with a "simple" optimization  :-(
20:59 jnthn :)
21:00 jnthn It's surprisingly easy to be fast and wrong.
21:00 travis-ci joined #perl6-dev
21:00 lizmat yeah
21:00 travis-ci Rakudo build failed. Zoffix Znet 'Fix copy-pastoed type name in error messages; dogbert17++'
21:00 travis-ci https://travis-ci.org/rakudo/rakudo/builds/243998340 https://github.com/rakudo/rakudo/compare/0331fb9d5046...e824266fd59f
21:00 travis-ci left #perl6-dev
21:00 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.
21:00 lizmat on that thought, /me is going to take some R&R
21:00 lizmat good night, #perl6-dev!
21:00 jnthn Enjoy :)
21:00 jnthn o/
21:16 dogbert17 if a method is declared as, e.g. 'method annotations()', does that mean there's an implied :D invocant?
21:19 ugexe geekosaur: thanks, with dd i see that all bytes are being written
21:25 jnthn dogbert17: No
21:40 mj41 joined #perl6-dev
21:44 dogbert17 m: callframe
21:44 camelia rakudo-moar 9435c1: ( no output )
21:44 dogbert17 m: say callframe
21:44 camelia rakudo-moar 9435c1: OUTPUT: «<tmp> at line 1␤»
21:44 dogbert17 m: say CallFrame.callframe
21:44 camelia rakudo-moar 9435c1: OUTPUT: «Callframe.callframe not yet implemented. Sorry.␤  in block <unit> at <tmp> line 1␤␤»
21:45 dogbert17 thx jnthn, this means I just commited an error, grr :)
22:23 eveo hm, wonder what's up with that 04-nativecall/06-struct.t test.
22:23 eveo Reproed it immediatelly locally, then removed .precomp dirs and now it's not failing anymore
22:25 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:33 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:42 eveo Also something makes tests in Concurrent::File::Find fail on HEAD, but not on 2017.05
22:43 eveo too bad it's gfldex-ware...
22:43 eveo "my &start = -> ( &c ) { c } if $no-thread;" really :/
22:43 Geth ¦ rakudo: ugexe++ created pull request #1104: Fix run/shell :merge
22:43 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/1104
22:46 Geth ¦ rakudo/nom: 06263e512b | (Nick Logan)++ | src/core/Proc.pm
22:46 Geth ¦ rakudo/nom: Fix run/shell :merge
22:46 Geth ¦ rakudo/nom:
22:46 Geth ¦ rakudo/nom: Previously this command would deadlock:
22:46 Geth ¦ rakudo/nom: `my $proc = run("ls", :merge).out.slurp.say`
22:46 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/06263e512b
22:46 Geth ¦ rakudo/nom: 807496671c | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Proc.pm
22:46 Geth ¦ rakudo/nom: Merge pull request #1104 from ugexe/proc-merge
22:46 Geth ¦ rakudo/nom:
22:46 Geth ¦ rakudo/nom: Fix run/shell :merge
22:46 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/807496671c
23:02 eveo something to do with .mapping on a Seq
23:04 eveo and for loops
23:07 eveo m: sub foo ($) { (1, 2).Seq.map: &say }; .&foo for 1
23:07 camelia rakudo-moar 807496: ( no output )
23:07 eveo c: 2017.05 sub foo ($) { (1, 2).Seq.map: &say }; .&foo for 1
23:07 committable6 eveo, ¦2017.05: «1␤2»
23:07 * eveo prays to FSM this isn't a change in MoarVM
23:07 eveo bisect: sub foo ($) { (1, 2).Seq.map: &say }; .&foo for 1
23:07 bisectable6 eveo, On both starting points (old=2015.12 new=8074966) the exit code is 0 and the output is identical as well
23:07 bisectable6 eveo, Output on both points: «»
23:07 eveo reaaaly
23:08 eveo 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
23:08 bisectable6 eveo, bisect log: https://gist.github.com/86d16f9097d2ce8c1b9ab8546b557fef
23:08 bisectable6 eveo, (2017-06-15) https://github.com/rakudo/rakudo/commit/9b0b9effe5fee1f35497cf97a5e7bda9bb083507
23:08 eveo That looks really fancy-pants.. :/
23:09 eveo Maybe it's not meant to sink that map?
23:10 eveo "megamorphic callsites" :o
23:11 eveo "¦«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 eveo ¦«2016.08.1,2016.09,2016.10,2016.11,2016.12,2017.01,2017.02,2017.03,2017.04.3,2017.05»: 1
23:11 eveo 2
23:11 eveo So it worked the new way for about a year
23:12 eveo Crap. Should've looked at this toaster burn before napping :) Now everyone's gone :)
23:12 * eveo lunches
23:21 AlexDaniel joined #perl6-dev
23:26 eveo hm
23:26 eveo c: 2017.05,HEAD sub foo($) { (1, 2).Seq.map: &say }; foo($_) for 1
23:26 committable6 eveo, ¦2017.05,HEAD(8074966): «»
23:26 eveo c: 2017.05,HEAD sub foo($) { (1, 2).Seq.map: &say }; .&foo for 1
23:26 committable6 eveo, ¦2017.05: «1␤2» ¦HEAD(8074966): «»
23:26 eveo looks like it working was somewhat accidentall
23:27 eveo c: 2017.05,HEAD sub foo($) { (1, 2).Seq.map: &say }; (.&foo for 1)
23:27 committable6 eveo, ¦2017.05,HEAD(8074966): «1␤2»
23:30 eveo Yeah. I guess I can leave it as is for release.
23:32 eveo Tho looking at it it really should get sunk in that case, and thus .map be evaluated
23:34 eveo 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
23:34 bisectable6 eveo, bisect log: https://gist.github.com/cdd0d8d7a3a2d9d3c12a02a13ec33042
23:34 bisectable6 eveo, (2016-08-11) https://github.com/rakudo/rakudo/commit/977797fa401856e5310155f13469b7e6ff5f620a
23:35 eveo ZOFFLOP: t/spec/S11-modules/nested.t
23:35 eveo ZOFFLOP: t/spec/S17-supply/interval.t
23:35 eveo ZOFFLOP: t/spec/S32-io/pipe.t
23:35 eveo Damn. That's off one run. Though pipe.t I know what it is and will be fixed next week
23:36 samcv eveo, what's ZOFFLOP?
23:36 Geth ¦ rakudo/nom: 932b10f6a9 | (Zoffix Znet)++ | 3 files
23:36 Geth ¦ rakudo/nom: Revert "Change the way we code-gen simple for loops."
23:36 Geth ¦ rakudo/nom:
23:36 Geth ¦ rakudo/nom: This reverts commit 9b0b9effe5fee1f35497cf97a5e7bda9bb083507.
23:36 Geth ¦ rakudo/nom:
23:36 Geth ¦ rakudo/nom: Reverting for release, as it causes a regression in .map sinkage in
23:36 Geth ¦ rakudo/nom: for loops:
23:36 Geth ¦ rakudo/nom:
23:36 Geth ¦ rakudo/nom: Zoffix__> c: 2017.05,HEAD sub foo($) { ^2 .map: &say }; .&foo for 1
23:36 Geth ¦ rakudo/nom: <committable6> Zoffix__, ¦2017.05: «0␤1» ¦HEAD(8074966): «»
23:36 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/932b10f6a9
23:36 eveo samcv: flopping tests when stresstesting
23:36 eveo the fail in the run, but then are OK when you run them again
23:36 samcv which ones? or just lots of them?
23:36 samcv yeah i know what flopping tests are.
23:36 eveo Just in that file
23:36 samcv ah you're just saying "these files have dflopping tests"
23:36 samcv gotcha
23:37 eveo k. that fixes the burn in Concurrent::File::Find
23:39 eveo the burn with Event::Emitter looks to be just its own tests being racy and floppy
23:41 eveo gonna run another toast run, just in case. The 2017.06 release is itching to be a lemon it seems :/
23:48 ugexe whats wrong with pipe.t?
23:49 * ugexe is still chasing https://gist.github.com/ugexe/50e9b6ec0a8db2f85339dc39fc63dd6d and wonder if it could be related
23:49 ugexe on osx it always seems to work, but on a linux vm it fails 10-20 tests every time
23:56 BenGoldberg joined #perl6-dev
23:57 eveo ugexe: https://irclog.perlgeek.de/perl6-dev/2017-06-17#i_14746057
23:58 eveo 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 eveo s/fudge/kludge/

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary