Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-04-23

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:47 ilbot3 joined #p6dev
01:47 Topic for #p6dev is now Perl 6 language and compiler development
01:51 geekosaur joined #p6dev
03:43 geekosaur joined #p6dev
05:45 dalek roast: 478881d | usev6++ | S06-advanced/wrap.t:
05:45 dalek roast: Unfudge passing test for rakudo-j
05:45 dalek roast: review: https://github.com/perl6/roast/commit/478881ddb8
06:27 astj joined #p6dev
06:29 [TuxCM] joined #p6dev
06:37 RabidGravy joined #p6dev
08:18 [TuxCM] This is Rakudo version 2016.04-15-gb3d8169 built on MoarVM version 2016.04
08:18 [TuxCM] test            21.991
08:18 [TuxCM] test-t          12.387
08:18 [TuxCM] csv-parser      23.721
08:39 lizmat joined #p6dev
08:53 dalek roast: 4b44fe5 | usev6++ | S06-advanced/wrap.t:
08:53 dalek roast: Add ticket number for skipped test (JVM)
08:53 dalek roast: review: https://github.com/perl6/roast/commit/4b44fe56cf
09:03 lizmat jnthn: agree https://github.com/rakudo/rakudo/pull/754 should be closed and RT'd ?
09:15 lizmat https://rt.perl.org/Ticket/Display.html?id=127968   # problem in sleepsort marcusramberg found yesterday
09:23 vendethiel joined #p6dev
09:23 timotimo another thing to think about is that with ropes we can in theory handle strings that big; adding individual parts together wouldn't result in the whole thing being allocated; just a little record of what got concatenated
09:24 timotimo however, if you've added two strings that add up to 2**32, you've got to have two 2**31 big strings :)
09:24 timotimo and we do force ropes to become one flattened string when we regex-match against them
09:40 lizmat joined #p6dev
09:42 lizmat timotimo: wouldn't that by itself cause a slowdown in the use of regexes?
09:43 lizmat other question: while looking at RT #127968
09:43 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=127968
09:43 lizmat is there a reason why Channel.list is not implemented as an Iterator ???
09:43 lizmat jnthn: ^^^
09:43 timotimo i'm not sure what you mean by that?
09:44 timotimo "that by itself"?
09:44 lizmat well, Channel.list would return a Seq with an Iterator class in which the pull-one would do an nqp::poll ?
09:44 lizmat rather than first creating a Supply and then taking a list off of that ?
09:45 timotimo sorry, i was refering to the previous topic still
09:45 lizmat timotimo: ah, I meant, creating the concatenated string might be already quite expensive
09:46 timotimo oh
09:46 timotimo well, at 2**32 characters, yeah
09:46 timotimo you'll be memcpying 2**32 * 4 bytes together
09:46 lizmat if it consisted of many ropes
09:46 timotimo that can't be fast :)
09:47 lizmat I assume nqp::readallfh already creates a single roped string, right ?
09:48 timotimo it should, yeah
09:51 lizmat ?>/|";.,/[plkm,./
09:52 lizmat (that was some chai tea on my keyboard)
09:54 timotimo uh oh!
09:55 lizmat yeah, probably ok
09:55 lizmat if I go up in a puff of smoke, you know what happened  :-)
09:57 timotimo probably makes the keys a bit sticky :|
10:05 lizmat it was sugarless chai (sweetener only), so not too sticky
10:05 lizmat and it was only the lower right corner of my keyboard that got hit
10:26 timotimo phew
10:36 dalek rakudo/nom: 48cc6b5 | lizmat++ | src/core/Channel.pm:
10:36 dalek rakudo/nom: Preliminary fix for RT #127968
10:36 dalek rakudo/nom:
10:36 dalek rakudo/nom: I'm not sure why a Channel would need to create a Supply first to be
10:36 dalek rakudo/nom: able to create a .list.  So I re-imagined Channel.list to be a Seq
10:36 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=127968
10:36 dalek rakudo/nom: with a simple Iterator that is polling the Channel.  This causes one
10:36 dalek rakudo/nom: Channel spectest to fail, but I feel the test is wrong as it apparently
10:36 dalek rakudo/nom: assumes there is a Supply underlying Channel.list.  Comments / Patches
10:36 dalek rakudo/nom: welcome!
10:36 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/48cc6b5f46
10:36 bartolin lizmat: RT #127968 was already reported as RT #127960 (which has a backtrace but no details otherwise). I could merge both tickets (and keep your subject) or I could reject the earlier report as a dup. do you have a preference?
10:36 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=127968
10:36 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=127960
10:36 timotimo have you looked closely at what the Supply method on Channel does, exactly?
10:38 lizmat timotimo: yes, and it is useful in and of itself
10:38 lizmat but I'm not sure we need it to create a .list
10:38 lizmat so you could argue I implemented a work-around yes  :-)
10:39 lizmat bartolin: argh, why didn't I see that in my mail ?
10:40 lizmat please merge the two tickets: the stack trace may be useful for someone like jnthn
10:40 bartolin will do
10:41 lizmat bartolin++
11:11 jnthn lizmat: Agree https://github.com/rakudo/rakudo/pull/754 is the wrong fix, yeah.
11:12 lizmat PR closed
11:12 timotimo there is no such PR as a bad PR :)
11:13 timotimo clearly, the user must have accidentally run into this problem?
11:13 jnthn yeah
11:13 jnthn Maybe we should just make our string length 64-bit :P
11:13 jnthn "Overflow *that*!"
11:29 tadzik . o O ( I had trouble reproducing this, my SSD was not big enough to put swap there, but... )
11:36 lizmat I'm confused now: shouldn't .list not return something listy and isn't a Seq a listy thing ?
11:38 jnthn Seq isn't really list-y enough
11:39 jnthn Doesn't bind to @ for one.
11:40 jnthn ooh, lunch time :) bbl
11:45 lizmat joined #p6dev
11:45 astj joined #p6dev
11:55 dalek rakudo/nom: 5a14162 | lizmat++ | src/core/Channel.pm:
11:55 dalek rakudo/nom: Fix test breakage caused by 48cc6b5f469e915333
11:55 dalek rakudo/nom:
11:55 dalek rakudo/nom: Implements:
11:55 dalek rakudo/nom: - Channel.receive-nil-on-close
11:55 dalek rakudo/nom: - Channel.iterator
11:55 dalek rakudo/nom: - Channel.Seq
11:55 dalek rakudo/nom: Re-Implements:
11:55 dalek rakudo/nom: - Channel.list
11:55 dalek rakudo/nom:
11:55 dalek rakudo/nom: Also: RT #127968 was a dup of RT #127960
11:55 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=127968
11:55 lizmat I'm not sure whether receive-nil-on-close shouldn't actually be the default behaviour of Channel.receive
12:08 [TuxCM] This is Rakudo version 2016.04-17-g5a14162 built on MoarVM version 2016.04
12:08 [TuxCM] test            21.864
12:08 [TuxCM] test-t          12.765
12:08 [TuxCM] csv-parser      23.775
12:10 lizmat_ joined #p6dev
12:38 nine_ MadcapJake: subcommands are something that can and should be explored in module space before support is added to core
13:24 MadcapJake nine_: that's true, I make take a stab at my proposed interface above.
13:24 MadcapJake s/make/might/
14:01 hankache joined #p6dev
15:04 lizmat m: class A { multi method a() {}; multi method a(42) {} }; say A.^find_method("a").package   # feels like a bug to me
15:04 camelia rakudo-moar 5a1416: OUTPUT«(Dummy)␤»
15:04 lizmat jnthn:  ^^^ expected to see (A) here, really
15:05 lizmat m: class A { method a() {} }; say A.^find_method("a").package   # works
15:05 camelia rakudo-moar 5a1416: OUTPUT«(A)␤»
15:06 jnthn m: class A { multi method a() {}; multi method a(42) {} }; say A.^lookup('a').candidates[0]>>.package
15:06 camelia rakudo-moar 5a1416: OUTPUT«((A))␤»
15:06 jnthn m: class A { multi method a() {}; multi method a(42) {} }; say A.^lookup('a').candidates>>.package
15:06 camelia rakudo-moar 5a1416: OUTPUT«((A) (A))␤»
15:06 jnthn The cands themselves are fine
15:06 jnthn Oh...
15:06 jnthn It's just the default proto is just cloned from a dummy one
15:07 jnthn We should tweak its package after cloning it. Probably a 1-line fix. :)
15:07 jnthn m: class A { proto method a(|) { * } multi method a() {}; multi method a(42) {} }; say A.^lookup('a').package
15:07 camelia rakudo-moar 5a1416: OUTPUT«===SORRY!=== Error while compiling /tmp/CwIQQ9RCxL␤Strange text after block (missing semicolon or comma?)␤at /tmp/CwIQQ9RCxL:1␤------> class A { proto method a(|) { * }⏏ multi method a() {}; multi method a(42)␤    expecting any of:…»
15:07 jnthn m: class A { proto method a(|) { * }; multi method a() {}; multi method a(42) {} }; say A.^lookup('a').package
15:07 camelia rakudo-moar 5a1416: OUTPUT«(A)␤»
15:07 jnthn Yeah, fine on an explicit proto too
15:08 jnthn Just the generated one
15:20 tadzik https://gist.github.com/tadzik/f2634cfac104760dc9bce1f376499e3c rakudobug?
15:20 tadzik I'd expect to get USAGE in both cases
15:43 masak tadzik: me too, I think
15:44 tadzik argh, that exception is X::AdHoc :|
15:45 tadzik https://gist.github.com/tadzik/3e32043c3c25456517cb33b57c642ac1
15:46 tadzik prolly since it's from the binder
16:03 tadzik proposed patch: https://gist.github.com/tadzik/2001b1f3ec464b0448e62f3655b58ab2
16:03 tadzik it can theoretically trigger from user error, is someone literally does "die 'Constraint type bla bla'" from their MAIN, but I'd argue that it does more good than harm
16:19 tadzik spectests pass, so I'm tempted to go ahead with it and ask for forgviness/mercy later
16:21 nine_ Could the .backtrace[0].subname fail somehow?
16:21 tadzik you mean: yield a false positive?
16:21 nine_ More like do we always have a backtrace and does the first element always have a .subname?
16:22 tadzik ah
16:22 tadzik Backtrace::Frame always has a .subname
16:23 tadzik and I don't think we can have a backtrace with 0 frames in any case
16:26 tadzik moritz?
16:28 moritz uhm
16:28 moritz there are filtered views on backtraces
16:28 moritz they can certainly be empty
16:29 moritz if you look at all the magic in AT-POS, it is certainly possible for it to not find anything
16:31 tadzik indeed
16:33 dalek rakudo/nom: adb2c8f | niner++ | src/ (4 files):
16:33 dalek rakudo/nom: Fix EVAL during precompilation
16:33 dalek rakudo/nom:
16:33 dalek rakudo/nom: EVALed code is considered an independent compilation unit that gets compiled
16:33 dalek rakudo/nom: using a new World which contains an independent serialization context. It also
16:33 dalek rakudo/nom: gets its own QAST compiler.
16:33 dalek rakudo/nom:
16:33 dalek rakudo/nom: When a BEGIN time EVAL is run during precompilation of a module, the
16:33 dalek rakudo/nom: independent SC would not be written into any file but would still be referenced
16:33 dalek rakudo/nom: from the outer compilation unit. We therefor use the outer world's
16:33 dalek rakudo/nom: CompilationContext which contains the SC. We also need to share a couple of
16:33 dalek rakudo/nom: other attributes that keep track of the compilation's state.
16:34 moritz nine_++ # months of work cummulating into a single commit
16:34 moritz oh, two commits actually; dalek swallowed one
16:36 nine_ Well the second one was a quite quick refactor, not even comparable to the work that went into the first :)
16:36 nine_ And it may well be that I have to re-visit this topic again as it's only an 80 % fix. It's enough to unblock the repository work though.
16:43 hankache joined #p6dev
16:43 lizmat nine++
16:49 timotimo that's the magical commit! \o/
17:24 vendethiel nine_: looks amazing :D
17:28 masak nine++!
17:29 masak does this mean something for slangs and/or other languages?
17:35 jnthn nine_++ # persistence
17:36 timotimo persistence is something i'm sorely lacking :S
17:50 lizmat joined #p6dev
17:51 vendethiel timotimo: yeah, hard stuff
17:51 lizmat joined #p6dev
18:07 nine_ masak: sorry, I've got much too little experience with slangs to answer that.
18:10 masak dang :)
18:10 masak so do I!
18:35 dalek roast: e732b37 | lizmat++ | integration/precompiled.t:
18:35 dalek roast: RT #124324 is fixed, nine++
18:35 dalek roast: review: https://github.com/perl6/roast/commit/e732b37a2e
18:35 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=124324
18:41 lizmat PSA: re https://github.com/rakudo/rakudo/pull/578
18:41 lizmat I've asked leont to adapt the PR in such a way that we can do a make spectest using prove6 by setting an environment variable
18:42 lizmat thus allowing easy switching between "production" spectesting, and "dogfood testing" spectesting
18:42 jnthn +1
18:42 lizmat as soon as that is the case, I plan to merge that PR
18:42 lizmat so that we can have more eyes on it more easily
18:42 jnthn *nod*
18:44 * jnthn wonders if working thorugh the treasure trove that is https://gist.github.com/jnthn/2996cce212da18720a0e4660e71fe5a5 next week might help with some of what it runs in to...
18:44 lizmat oooh  shiny!
18:45 jnthn It takes about 16 hours to do such a spectest run :)
18:50 lizmat fwiw, I recognize a lot of those test files as flappers
18:51 jnthn Yes, me too ;)
18:54 lizmat food! drink! girls!
18:54 lizmat .oO( Father Jack is everywhere )
18:54 lizmat &
18:57 jnthn enjoy :)
18:58 jnthn walk &
19:02 hankache joined #p6dev
21:53 dalek rakudo/relocateable-precomp: 899befd | niner++ | src/core/CompUnit/Repository/Installation.pm:
21:53 dalek rakudo/relocateable-precomp: Turn short-name lookup files into directories
21:53 dalek rakudo/relocateable-precomp:
21:53 dalek rakudo/relocateable-precomp: This may become part of CompUnit::Repository::Installation format v1.
21:53 dalek rakudo/relocateable-precomp: Having to change any already existing files on installation of a module makes
21:54 dalek joined #p6dev
21:56 cognominal joined #p6dev
21:57 tadzik oh yiss
22:46 lizmat joined #p6dev
22:55 astj joined #p6dev
23:11 lizmat so, is there a reason why we only have Version:D cmp Version:D, and not Version:D gt Version:D and friends? (ge eq ne lt le) ?
23:30 dalek rakudo/nom: 688ddee | lizmat++ | src/core/Version.pm:
23:30 dalek rakudo/nom: Add Version lt|le|eq|ne|ge|gt Version
23:30 dalek rakudo/nom:
23:30 dalek rakudo/nom: It would seem we need a richer set of operators for Version comparisons.
23:30 dalek rakudo/nom: This causes some (un-spectested) changes:
23:30 dalek rakudo/nom:
23:30 dalek rakudo/nom:   say v2.8 eq  v2.8.0;    # False before, now True
23:30 dalek rakudo/nom:   say v2.8 eqv v2.8.0;    # False before, still False
23:30 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/688ddee28b
23:57 tomboy64 joined #p6dev

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary