[01:58] *** vendethiel joined [02:59] *** astj joined [04:54] *** astj joined [06:05] *** vendethiel joined [06:40] *** ugexe joined [07:13] *** brrt joined [07:28] re: reframe branch, i'm sorry for increasing the frame size again :-) [07:29] *** ugexe joined [07:33] *** RabidGravy joined [07:34] jnthn: "A frame becoming the default outer thanks to “auto-close” (rare)" -- is this one the "need more vodka" case with roles? [07:48] *** brrt joined [08:14] *** sno joined [08:30] <[TuxCM]> This is Rakudo version 2016.04-5-g463e758 built on MoarVM version 2016.04 [08:30] <[TuxCM]> test 22.579 [08:30] <[TuxCM]> test-t 12.573 [08:30] <[TuxCM]> csv-parser 24.805 [08:49] rakudo/nom: a5d53e7 | azawawi++ | README.md: [08:49] rakudo/nom: Fix AppVeyor CI link [08:49] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a5d53e73f0 [08:49] rakudo/nom: 9f9f0b2 | lizmat++ | README.md: [08:49] rakudo/nom: Merge pull request #753 from azawawi/nom [08:49] rakudo/nom: [08:49] rakudo/nom: Fix AppVeyor CI link [08:49] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/9f9f0b2873 [08:49] I'd like to flag up https://rt.perl.org/Ticket/Display.html?id=127789 for discussion -- also, ping TimToady [08:49] first off, I think lizmat++ is perfectly right, that it is a slippery slope [08:53] Rakudo is to spec here, by the way -- S12:1903 has this: [08:53] Link: http://design.perl6.org/S12.html#1903_has_this [08:53] CoinFace.enums.keys # ('Heads', 'Tails') [08:53] go home, synopsebot6 you're funny [08:54] S12:1903 [08:54] Link: http://design.perl6.org/S12.html#line_1903 [08:55] but... the reason we went with the .enums and .invert design in the first place is so that we could *look up the Enum objects from the values* [08:55] *** lizmat joined [08:56] I haven't had a use case where I needed to do that until last month [08:57] and my experience as a user of that API is that it'd be a whole lot more useful/sensible to get the Enum, not the Str representation [08:57] I am -- cautiously -- of the opinion that if fixing this requires a breaking change, we should do it [08:58] my caution comes from the fact that I haven't tested the ecosystem against such a change to see what falls out -- something we can, and should, do [08:59] tl;rd: "I think this is a slippery slope we should go down, with a toboggan!" :P [09:00] I think I've used the current behaviour in a couple of tests but probably not in an actual module [09:02] RabidGravy: do you have a link to those tests? [09:02] just grepping all my modules to find which ones [09:03] fwiw, here's my use case: https://github.com/masak/nex/blob/master/lib/Games/Nex/Test.pm#L7-L12 [09:04] sorry, permalink: https://github.com/masak/nex/blob/ed4f5758513b85c41d4ecb35af5cf24643a3829f/lib/Games/Nex/Test.pm#L7-L12 [09:04] and the declaration of the enum: https://github.com/masak/nex/blob/ed4f5758513b85c41d4ecb35af5cf24643a3829f/lib/Games/Nex.pm#L4-L9 [09:06] actually interestingly in https://github.com/jonathanstowe/Lumberjack/blob/master/t/040-dispatcher-basic.t#L23 I am emulating the other behaviour [09:07] and I assume that wouldn't actually be broken by the proposed changed [09:08] the only other place is in https://github.com/jonathanstowe/Audio-Sndfile/blob/master/examples/p6sndfile-convert [09:11] so somewhat false memory [10:09] Of not may be that Enums stringify to their full name, i.e. Stone::Vertical, not just the short name [10:28] *** DrForr joined [10:31] *** ugexe joined [10:33] *** tomboy64 joined [11:01] lizmat: hey, I've a new spectest record maybe! [11:01] Files=1098, Tests=51306, 88513 wallclock secs [11:01] :D [11:01] wow... progress! :-) [11:01] m: say 88513 / (60 * 60) [11:01] rakudo-moar 9f9f0b: OUTPUT«24.586944␤» [11:01] :) [11:02] 13K nursery, I suppose ? [11:02] Yeah [11:02] rakudo on RPi now has a contender [11:02] What's interesting is that it's showed up various test files that I seem to recall us having heisenfails with [11:04] ah... that's good to know [11:05] so, would there be an easy way of running this type of test with an existing MoarVM ? [11:05] MVM_NURSERY=13 ? [11:06] m: say *.ACCEPTS(False) # shouldn't this be False ? [11:06] rakudo-moar 9f9f0b: OUTPUT«{ ... }␤» [11:06] lizmat: Not yet [11:06] m: say Whatever.ACCEPTS(False) # shouldn't this be False ? [11:06] rakudo-moar 9f9f0b: OUTPUT«False␤» [11:07] lizmat: You have to change a value in a header file and make install [11:07] huh? [11:07] *.ACCEPTS(False) is an auto-curry [11:08] m: say (*).ACCEPTS(False) [11:08] rakudo-moar 9f9f0b: OUTPUT«{ ... }␤» [11:08] oh, so is that :) [11:08] But yeah, ti's like *.foo [11:08] m: say .map(*.uc) [11:08] rakudo-moar 9f9f0b: OUTPUT«(O M G)␤» [11:08] I was trying to figure out the difference between .grep(*) and .grep({$_}) [11:09] m: say Whatever.new.ACCEPTS(False) [11:09] rakudo-moar 9f9f0b: OUTPUT«True␤» [11:09] m: say Whatever.ACCEPTS(False) [11:09] rakudo-moar 9f9f0b: OUTPUT«False␤» [11:09] Whatever.ACCEPTS(False) is a type test against Whatever [11:09] Just as Int.ACCEPTS(False) is [11:10] m: say Int.ACCEPTS(False) [11:10] rakudo-moar 9f9f0b: OUTPUT«True␤» [11:10] m: say False.^mro # here's why True [11:10] rakudo-moar 9f9f0b: OUTPUT«((Bool) (Int) (Cool) (Any) (Mu))␤» [11:10] m: say Whatever.ACCEPTS(False) # so this is wrong [11:10] rakudo-moar 9f9f0b: OUTPUT«False␤» [11:10] No? [11:11] m: say Bool ~~ Whatever [11:11] rakudo-moar 9f9f0b: OUTPUT«False␤» [11:11] You're confusing Whatever the type, and *, an instance of the type, I think? [11:11] m: say Int.ACCEPTS(False) [11:11] rakudo-moar 9f9f0b: OUTPUT«True␤» [11:11] jnthn: isn't that a WhateverCode ? [11:11] No [11:12] WhateverCode is produced by the compiler after an auto-curry [11:12] But a plain old * is just an instance of Whatever [11:12] m: my $x = *; say $x.WHAT; say $x.defined [11:12] rakudo-moar 9f9f0b: OUTPUT«(Whatever)␤True␤» [11:13] m: (Any,42,Any).grep(*).say # so this is correct ? [11:13] rakudo-moar 9f9f0b: OUTPUT«((Any) 42 (Any))␤» [11:13] I'd except .grep(*) to just be the same as .grep(True) [11:13] Yes, looks correct to me [11:13] m: (Any,42,Any).grep({$_}).say # as opposed to this? [11:13] rakudo-moar 9f9f0b: OUTPUT«(42)␤» [11:14] Also looks correct [11:14] ok, will tell tadzik :-) [11:14] Because in the code case we treat the result as a boolean [11:14] :( [11:14] Well, actually, more like, smart-match against a piece of code invokes it with the topic [11:15] We probably optimize the closure path rather than actually calling ACCEPTS, but an implementation that didn't need to care about speed would be correct in just calling ACCEPTS [11:15] it just seems counterintuitive, when in every conf talk we say "you can use * instead of $_ in your grep/map and that saves you writing the block around it" [11:16] We should maybe get better at explaining that the mechanism is the conjunction of * together with an operator that's whatever-curryable [11:17] Note that .grep(1..*) is different to .grep({1..$_}) also [11:22] rakudo/nom: cc4dd7c | lizmat++ | src/core/Version.pm: [11:22] rakudo/nom: Make Version comparisons abouut 2x as fast [11:22] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/cc4dd7c2c9 [11:30] https://bpaste.net/show/fc1dc1224509 <--- this is my build output when trying to compile rakudo. [11:31] this is with http://rakudo.org/downloads/rakudo/rakudo-2016.03.tar.gz [11:32] what my build script (ebuild) does is, it calls `perl Configure.pl --prefix=/usr --sysroot=/usr --make-install --backends=moar,` [11:32] now, is that expected behavior, to rely on those includes? or is it trying to build its own moarvm? [11:33] https://bpaste.net/show/e6960940e6d0 <--- these are the files my moarvm package installs [11:34] RabidGravy's https://github.com/jonathanstowe/Lumberjack/blob/master/t/040-dispatcher-basic.t#L23 is yet another use case that would benefit from .enum keys being Enum, not Str [11:35] whereas in https://github.com/jonathanstowe/Audio-Sndfile/blob/master/examples/p6sndfile-convert#L8 it sort of doesn't matter [12:29] *** tomboy64 joined [12:43] *** tomboy64 joined [13:07] * [Coke] has a slight concern that moving more perl6 code into nqp:: calls is going to make porting to non-moar harder. [13:07] <[Coke]> since then there's more places we have to deal with the fact that the ops can perform differently on different backends (or even not be implemented) [13:08] * [Coke] is so far away from code at this point that you should probably not listen to him, though. [13:18] m: LEAVE "say goodbye"; die [13:18] rakudo-moar cc4dd7: OUTPUT«WARNINGS for /tmp/PgBu1K_e_v:␤Useless use of constant string "say goodbye" in sink context (line 1)␤Died␤ in block at /tmp/PgBu1K_e_v line 1␤␤» [13:18] m: LEAVE say "goodbye"; die [13:18] rakudo-moar cc4dd7: OUTPUT«goodbye␤Died␤ in block at /tmp/NMYKDSlZC1 line 1␤␤» [13:19] surprising benchmark: [13:19] m: my @a = ^100; for ^1000 { my @b = @a; while @b { @b.shift } }; say now - INIT now' [13:19] rakudo-moar cc4dd7: OUTPUT«===SORRY!=== Error while compiling /tmp/gayh0ZePtF␤Two terms in a row␤at /tmp/gayh0ZePtF:1␤------> le @b { @b.shift } }; say now - INIT now⏏'␤ expecting any of:␤ infix␤ infix stopper␤ postfix␤ s…» [13:19] m: my @a = ^100; for ^1000 { my @b = @a; while @b { @b.shift } }; say now - INIT now [13:19] rakudo-moar cc4dd7: OUTPUT«0.4233799␤» [13:19] m: my @a = ^100; for ^1000 { my @b = @a; while +@b { @b.shift } }; say now - INIT now [13:19] rakudo-moar cc4dd7: OUTPUT«0.59715891␤» [13:20] m: my @a = ^100; for ^1000 { my @b = @a; while +@b { @b.shift } }; say now - INIT now [13:20] rakudo-moar cc4dd7: OUTPUT«0.55395872␤» [13:20] m: my @a = ^100; for ^1000 { my @b = @a; while ?@b { @b.shift } }; say now - INIT now [13:20] rakudo-moar cc4dd7: OUTPUT«0.63726418␤» [13:20] huh? [13:20] I get different results locally [13:21] $ 6l 'my @a = ^100; for ^1000 { my @b = @a; while @b { @b.shift } }; say now - INIT now' [13:21] 0.4222960 [13:21] $ 6l 'my @a = ^100; for ^1000 { my @b = @a; while +@b { @b.shift } }; say now - INIT now' [13:21] 0.3064966 [13:21] $ 6l 'my @a = ^100; for ^1000 { my @b = @a; while ?@b { @b.shift } }; say now - INIT now' [13:21] 0.28286319 [13:22] I also get shorter times in the latter 2 cases [13:23] 0.42348009, 0.3310363 and 0.3199181 [13:23] well, camelia is a quite unreliable source for timing information [13:23] when the result is under a second, you're in quite a bit of danger of the rest of the system messing with your timings [13:23] m: my @a = ^100; for ^1000 { my @b = @a; while ?@b { @b.shift } }; say now - INIT now [13:23] rakudo-moar cc4dd7: OUTPUT«0.3149762␤» [13:23] m: my @a = ^100; for ^1000 { my @b = @a; while ?@b { @b.shift } }; say now - INIT now [13:23] rakudo-moar cc4dd7: OUTPUT«0.3221899␤» [13:23] m: my @a = ^100; for ^1000 { my @b = @a; while @b { @b.shift } }; say now - INIT now [13:23] rakudo-moar cc4dd7: OUTPUT«0.4029122␤» [13:24] lizmat: If you MVM_SPESH_DISABLE=1 and run them, how do they vary? [13:26] the ? and + case are within noise-level, the bare case is 10% slower [13:26] 0.60365436 vs 0.677837 [13:27] Innerestin' :) [13:27] clearly we're inlining that prefix operator very well, eh? [13:27] Yeah [13:27] impressive [13:27] And I imagine we might be inlining the .Bool call not at all [13:27] Because it's an invokish thunk thing because of the boolspec stuff. [13:27] ah, sounds sensible [13:27] We should be able to optimize that out and inline .Bool [13:28] But it's possible we're not doing so yet [13:28] i didn't see code for that yet [13:28] I thought we devirt'd istrue in some cases. [13:28] yeah, but not when the boolspec is "call method" [13:28] Ah, ok [13:28] only when it's "unbox an int" or "string-like istrue" [13:28] If we rewrote that into a normal call then the inliner could nom it I guess :) [13:28] in general we don't turn things that invoke via "a thing in some spec" into a bare invocation yet [13:29] *** skids joined [13:29] ah, ok [13:30] Probably not too hard, and would likely bring the while @b { } case in line with the others [14:03] *** perlpilot joined [14:03] *** tomboy64 joined [14:21] *** |Tux| joined [15:00] dalek dead ? [15:01] * lizmat just pushed https://github.com/rakudo/rakudo/commit/af145848bba81402f223758c933eba47f6a4e64d [15:01] "Re-imagine MAIN parameter parsing" [15:01] - introduce $*MAIN-ALLOW-NAMED-ANYWHERE [15:01] - if set with True value, will allow named parameters anywhere [15:01] - should allow "panda install --foo" to work [15:01] - initialized from environment variable MAIN_ALLOW_NAMED_ANYWHERE [15:03] lizmat++ [15:03] Once people get used to it, do you think that will become the default? [15:03] the majority of P6 people at QAH thinks so, yes :-) [15:04] necessary diff for that: [15:04] - %*ENV // 0; [15:04] + %*ENV // 1; [15:04] perlpilot: I do hope so :} [15:05] * perlpilot was hoping too, I just didn't know if there was any push back from anyone. [15:05] I'd go so far as to say 100% p6 people agree [15:05] (on the qah) [15:05] hm, wouldn't we want to have a "perl6" in the environment variable name? [15:05] afaik, TimToady wasn't in favour of this behaviour [15:06] because of the deviation from normal signature processing for MAIN? [15:06] timotimo: if anything, I think it should be a RAKUDO_ prefix ? [15:07] perlpilot: I believe so [15:07] +1 (RAKUDO_ prefix) [15:07] then that would also need to be done for DEFAULT_READ_ELEMS [15:08] oh, yeah [15:09] if the consensus here it should be both, I'll do that :-) [15:10] aye. [15:20] *** dalek joined [15:20] *** synopsebot6 joined [15:22] rakudo/nom: 2b06f71 | lizmat++ | src/core/ (2 files): [15:22] rakudo/nom: Add RAKUDO_ prefix to environment vars [15:22] rakudo/nom: [15:22] rakudo/nom: - DEFAULT_READ_ELEMS [15:22] rakudo/nom: - MAIN_ALLOW_NAMED_ANYWHERE [15:22] rakudo/nom: [15:22] rakudo/nom: As per http://irclog.perlgeek.de/p6dev/2016-04-22#i_12378252 [15:22] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/2b06f71409 [15:29] *** [Coke] joined [15:29] m: my $a := once 42; $a = 666; say $a # this feels wrong, note it's binding, not assigning [15:29] rakudo-moar af1458: OUTPUT«666␤» [15:29] <[Coke]> yup, still hate IRC and my client. [15:30] <[Coke]> anyone know what happened to hack? [15:30] <[Coke]> (I see timotimo had to reboot it...) [15:30] yeah, sorry about that [15:34] *** japhb joined [15:37] timotimo: I take your apology to imply that you broke hack somehow? [15:43] putting argument processing under the control of the user feels a bit wrong-peggy to me, but I'm not sure where the right peg is [15:45] env vars are a bit like Vise Grips®, the wrong tool for every job, but it'll do every job [15:46] *** masak joined [15:47] for instance, what if you call a subprocess that *isn't* expecting arg reordering, does it break? [15:49] this is the basic problem with any kind of dynamic scoping (of which env vars are a subset): they can change the API contract unexpectedly [15:53] so while I'm fine with making it easy for a given program to take named args anywhere, I suspect that this should be declared in the lexical scope of the callee (that is, where MAIN is), not the dynamic scope of the caller (that is, using env vars) [15:54] I'd also like to see a solution that allows nested command structures that are able to distinguish options on the whole command from options on the subcommand [15:55] merely mushing all the options together does not really accomplish this [15:55] *** astj joined [15:56] so more like a MAIN that can delegate to sub-MAIN processors [15:59] such that a sub-MAIN could delegate tertiary commands to a sub-sub-MAIN, and not get confused about which switch is going to which level [15:59] TimToady: wrt env variable: it felt more it was for debugging [16:00] TimToady, y'know that you only need three things to effect any repair - a hammer, gaffer tape and wd-40 :) [16:00] but you have a point about subprocesses :-) [16:00] dynamic scoping is always kind of an attractive nuisance [16:01] *** perlpilot joined [16:01] also why we end up with things like %*LANG when surely the "current language" should be defined by the current language object, that is, the cursor [16:03] rakudo/nom: 3ebf31e | lizmat++ | src/core/Main.pm: [16:03] rakudo/nom: No longer use env for $*MAIN-ALLOW-NAMED-ANYWHERE [16:03] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/3ebf31edcd [16:12] TimToady: but, what do you think about making arg reordering for MAIN the default? [16:14] in general, I don't like throwing away information by default [16:15] I'm fine with an explicit reorder-args() call though [16:16] but I think using reorder-args when you really want cascaded MAIN is going to make it difficult to detect the wrong switch on the wrong subcommand [16:17] perlpilot: it broke by itself, i'm afraid [16:26] *** M-tadzik joined [16:36] *** japhb joined [16:42] rakudo/nom: 8865365 | lizmat++ | lib/Test.pm6: [16:42] rakudo/nom: Fix '#' escaping [16:42] rakudo/nom: [16:42] rakudo/nom: As suggested as part of leont++ 's PR #578 [16:42] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8865365122 [16:45] rakudo/nom: 3ec6b36 | lizmat++ | lib/Test.pm6: [16:45] rakudo/nom: Update copyright date [16:45] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/3ec6b3636a [16:57] *** hankache joined [17:02] *** japhb joined [17:10] *** hankache joined [17:16] *** TimToady joined [17:23] rakudo/nom: 0b8e08a | lizmat++ | lib/Test.pm6: [17:23] rakudo/nom: Streamline Test.pm a bit [17:23] rakudo/nom: [17:23] rakudo/nom: Basically, lose scopes when we can. Unscientifically appears to save [17:23] rakudo/nom: me 10 seconds wallclock on a spectest. [17:23] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/0b8e08ad4b [17:36] *** brrt joined [17:49] *** sno joined [17:57] drink! & [18:29] *** FROGGS joined [18:30] TimToady: Hmm. All very good points. It's too bad we don't have some syntactic help to declare a cascaded MAIN (or any other routine) that would work well with MMD. It seems to me that something like that would also be useful in web frameworks to do chaining ala Catalyst. [18:33] The ++foo ... ++/foo style options (are those even implemented?) are close in that they can provide a bounded area for separate processing [18:34] perlpilot: the trick will be to turn an argument list into a sequence of Captures, I suspect [18:34] or to somehow do the Capture transformation lazily as we match signatures [18:35] it's a little bit like how map matches a signature to part of an argument list [18:36] but extended to named args [18:36] Lazy Capture transformation feels right. [18:39] lunch feels about right :) & [19:00] *** psch joined [19:01] perlpilot: i've recently revisited rakudo PR #324, which implements the ++ opts [19:02] so, no, it's not implemented in nom [19:02] moritz++ did voice a valid concern back then, and while i do have an idea how to fix it i couldn't make it work yet [19:04] it's also something that could/(was speculated to) handle what PR #752 tries to [19:05] the ++ opts that is [19:09] i was also thinking whether the Perl6::CommandLine in PR 324 couldn't hand something a bit more structured to the p6-level interpreter [19:10] although i haven't thought too much about how that would interact with post-program opt parsing [19:27] *** brrt joined [20:18] *** sortiz joined [20:57] *** cognominal joined [21:55] *** lizmat joined [21:57] What about something like `sub install (Str $name, Bool :$force) is subcommand
{ ... }` which would allow nested subcommands and each signature would be arguments before any deeper subcommand. [22:01] that sounds like the purview of a module [22:14] Perhaps. Also seems like something that could just be powerful/complete ootb. [23:04] rakudo/nom: b3d8169 | lizmat++ | lib/Test.pm6: [23:04] rakudo/nom: Nativy counter for a small speedup [23:04] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/b3d8169649 [23:23] good night, #p6dev! [23:24] 'night, lizmat++