01:58 vendethiel joined 02:59 astj joined 04:54 astj joined 06:05 vendethiel joined 06:40 ugexe joined 07:13 brrt joined
brrt re: reframe branch, i'm sorry for increasing the frame size again :-) 07:28
07:29 ugexe joined 07:33 RabidGravy joined
masak jnthn: "A frame becoming the default outer thanks to “auto-close” (rare)" -- is this one the "need more vodka" case with roles? 07:34
07:48 brrt joined 08:14 sno joined
[TuxCM] This is Rakudo version 2016.04-5-g463e758 built on MoarVM version 2016.04 08:30
test 22.579
test-t 12.573
csv-parser 24.805
dalek kudo/nom: a5d53e7 | azawawi++ | README.md:
Fix AppVeyor CI link
 08:49
kudo/nom: 9f9f0b2 | lizmat++ | README.md:
Merge pull request #753 from azawawi/nom

Fix AppVeyor CI link
masak I'd like to flag up rt.perl.org/Ticket/Display.html?id=127789 for discussion -- also, ping TimToady
first off, I think lizmat++ is perfectly right, that it is a slippery slope
Rakudo is to spec here, by the way -- S12:1903 has this: 08:53
synopsebot6 Link: design.perl6.org/S12.html#1903_has_this
masak CoinFace.enums.keys # ('Heads', 'Tails')
go home, synopsebot6 you're funny
S12:1903 08:54
synopsebot6 Link: design.perl6.org/S12.html#line_1903
masak 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
08:55 lizmat joined
masak I haven't had a use case where I needed to do that until last month 08:56
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
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:58
tl;rd: "I think this is a slippery slope we should go down, with a toboggan!" :P 08:59
RabidGravy I think I've used the current behaviour in a couple of tests but probably not in an actual module 09:00
masak RabidGravy: do you have a link to those tests? 09:02
RabidGravy just grepping all my modules to find which ones
masak fwiw, here's my use case: github.com/masak/nex/blob/master/l....pm#L7-L12 09:03
sorry, permalink: github.com/masak/nex/blob/ed4f5758....pm#L7-L12 09:04
and the declaration of the enum: github.com/masak/nex/blob/ed4f5758...x.pm#L4-L9
RabidGravy actually interestingly in github.com/jonathanstowe/Lumberjac...asic.t#L23 I am emulating the other behaviour 09:06
and I assume that wouldn't actually be broken by the proposed changed 09:07
the only other place is in github.com/jonathanstowe/Audio-Snd...le-convert 09:08
so somewhat false memory 09:11
nine_ Of not may be that Enums stringify to their full name, i.e. Stone::Vertical, not just the short name 10:09
10:28 DrForr joined 10:31 ugexe joined 10:33 tomboy64 joined
jnthn lizmat: hey, I've a new spectest record maybe! 11:01
Files=1098, Tests=51306, 88513 wallclock secs
:D
lizmat wow... progress! :-)
jnthn m: say 88513 / (60 * 60)
camelia rakudo-moar 9f9f0b: OUTPUT«24.586944␤»
jnthn :)
lizmat 13K nursery, I suppose ? 11:02
jnthn Yeah
tadzik rakudo on RPi now has a contender
jnthn What's interesting is that it's showed up various test files that I seem to recall us having heisenfails with
lizmat ah... that's good to know 11:04
so, would there be an easy way of running this type of test with an existing MoarVM ? 11:05
MVM_NURSERY=13 ?
m: say *.ACCEPTS(False) # shouldn't this be False ? 11:06
camelia rakudo-moar 9f9f0b: OUTPUT«{ ... }␤»
jnthn lizmat: Not yet
lizmat m: say Whatever.ACCEPTS(False) # shouldn't this be False ?
camelia rakudo-moar 9f9f0b: OUTPUT«False␤»
jnthn lizmat: You have to change a value in a header file and make install 11:07
lizmat huh?
jnthn *.ACCEPTS(False) is an auto-curry
m: say (*).ACCEPTS(False) 11:08
camelia rakudo-moar 9f9f0b: OUTPUT«{ ... }␤»
jnthn oh, so is that :)
But yeah, ti's like *.foo
m: say <o m g>.map(*.uc)
camelia rakudo-moar 9f9f0b: OUTPUT«(O M G)␤»
lizmat I was trying to figure out the difference between .grep(*) and .grep({$_})
m: say Whatever.new.ACCEPTS(False) 11:09
camelia rakudo-moar 9f9f0b: OUTPUT«True␤»
lizmat m: say Whatever.ACCEPTS(False)
camelia rakudo-moar 9f9f0b: OUTPUT«False␤»
jnthn Whatever.ACCEPTS(False) is a type test against Whatever
Just as Int.ACCEPTS(False) is
lizmat m: say Int.ACCEPTS(False) 11:10
camelia rakudo-moar 9f9f0b: OUTPUT«True␤»
jnthn m: say False.^mro # here's why True
camelia rakudo-moar 9f9f0b: OUTPUT«((Bool) (Int) (Cool) (Any) (Mu))␤»
lizmat m: say Whatever.ACCEPTS(False) # so this is wrong
camelia rakudo-moar 9f9f0b: OUTPUT«False␤»
jnthn No?
m: say Bool ~~ Whatever 11:11
camelia rakudo-moar 9f9f0b: OUTPUT«False␤»
jnthn You're confusing Whatever the type, and *, an instance of the type, I think?
lizmat m: say Int.ACCEPTS(False)
camelia rakudo-moar 9f9f0b: OUTPUT«True␤»
lizmat jnthn: isn't that a WhateverCode ?
jnthn No
WhateverCode is produced by the compiler after an auto-curry 11:12
But a plain old * is just an instance of Whatever
m: my $x = *; say $x.WHAT; say $x.defined
camelia rakudo-moar 9f9f0b: OUTPUT«(Whatever)␤True␤»
lizmat m: (Any,42,Any).grep(*).say # so this is correct ? 11:13
camelia rakudo-moar 9f9f0b: OUTPUT«((Any) 42 (Any))␤»
jnthn I'd except .grep(*) to just be the same as .grep(True)
Yes, looks correct to me
lizmat m: (Any,42,Any).grep({$_}).say # as opposed to this?
camelia rakudo-moar 9f9f0b: OUTPUT«(42)␤»
jnthn Also looks correct 11:14
lizmat ok, will tell tadzik :-)
jnthn Because in the code case we treat the result as a boolean
tadzik :(
jnthn Well, actually, more like, smart-match against a piece of code invokes it with the topic
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
tadzik 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"
jnthn We should maybe get better at explaining that the mechanism is the conjunction of * together with an operator that's whatever-curryable 11:16
Note that .grep(1..*) is different to .grep({1..$_}) also 11:17
dalek kudo/nom: cc4dd7c | lizmat++ | src/core/Version.pm:
Make Version comparisons abouut 2x as fast
 11:22
tomboy64 bpaste.net/show/fc1dc1224509 <--- this is my build output when trying to compile rakudo. 11:30
this is with rakudo.org/downloads/rakudo/rakudo-....03.tar.gz 11:31
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?
bpaste.net/show/e6960940e6d0 <--- these are the files my moarvm package installs 11:33
masak RabidGravy's github.com/jonathanstowe/Lumberjac...asic.t#L23 is yet another use case that would benefit from .enum keys being Enum, not Str 11:34
whereas in github.com/jonathanstowe/Audio-Snd...convert#L8 it sort of doesn't matter 11:35
12:29 tomboy64 joined 12:43 tomboy64 joined
[Coke] has a slight concern that moving more perl6 code into nqp:: calls is going to make porting to non-moar harder. 13:07
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)
[Coke] is so far away from code at this point that you should probably not listen to him, though. 13:08
lizmat m: LEAVE "say goodbye"; die 13:18
camelia 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 <unit> at /tmp/PgBu1K_e_v line 1␤␤»
lizmat m: LEAVE say "goodbye"; die
camelia rakudo-moar cc4dd7: OUTPUT«goodbye␤Died␤ in block <unit> at /tmp/NMYKDSlZC1 line 1␤␤»
lizmat surprising benchmark: 13:19
m: my @a = ^100; for ^1000 { my @b = @a; while @b { @b.shift } }; say now - INIT now'
camelia 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…»
lizmat m: my @a = ^100; for ^1000 { my @b = @a; while @b { @b.shift } }; say now - INIT now
camelia rakudo-moar cc4dd7: OUTPUT«0.4233799␤»
lizmat m: my @a = ^100; for ^1000 { my @b = @a; while +@b { @b.shift } }; say now - INIT now
camelia rakudo-moar cc4dd7: OUTPUT«0.59715891␤»
lizmat m: my @a = ^100; for ^1000 { my @b = @a; while +@b { @b.shift } }; say now - INIT now 13:20
camelia rakudo-moar cc4dd7: OUTPUT«0.55395872␤»
lizmat m: my @a = ^100; for ^1000 { my @b = @a; while ?@b { @b.shift } }; say now - INIT now
camelia rakudo-moar cc4dd7: OUTPUT«0.63726418␤»
lizmat huh?
I get different results locally
$ 6l 'my @a = ^100; for ^1000 { my @b = @a; while @b { @b.shift } }; say now - INIT now' 13:21
0.4222960
$ 6l 'my @a = ^100; for ^1000 { my @b = @a; while +@b { @b.shift } }; say now - INIT now'
0.3064966
$ 6l 'my @a = ^100; for ^1000 { my @b = @a; while ?@b { @b.shift } }; say now - INIT now'
0.28286319
tadzik I also get shorter times in the latter 2 cases 13:22
0.42348009, 0.3310363 and 0.3199181 13:23
timotimo well, camelia is a quite unreliable source for timing information
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
lizmat m: my @a = ^100; for ^1000 { my @b = @a; while ?@b { @b.shift } }; say now - INIT now
camelia rakudo-moar cc4dd7: OUTPUT«0.3149762␤»
lizmat m: my @a = ^100; for ^1000 { my @b = @a; while ?@b { @b.shift } }; say now - INIT now
camelia rakudo-moar cc4dd7: OUTPUT«0.3221899␤»
lizmat m: my @a = ^100; for ^1000 { my @b = @a; while @b { @b.shift } }; say now - INIT now
camelia rakudo-moar cc4dd7: OUTPUT«0.4029122␤»
jnthn lizmat: If you MVM_SPESH_DISABLE=1 and run them, how do they vary? 13:24
lizmat the ? and + case are within noise-level, the bare case is 10% slower 13:26
0.60365436 vs 0.677837
jnthn Innerestin' :) 13:27
timotimo clearly we're inlining that prefix operator very well, eh?
jnthn Yeah
timotimo impressive
jnthn And I imagine we might be inlining the .Bool call not at all
Because it's an invokish thunk thing because of the boolspec stuff.
timotimo ah, sounds sensible
jnthn We should be able to optimize that out and inline .Bool
But it's possible we're not doing so yet 13:28
timotimo i didn't see code for that yet
jnthn I thought we devirt'd istrue in some cases.
timotimo yeah, but not when the boolspec is "call method"
jnthn Ah, ok
timotimo only when it's "unbox an int" or "string-like istrue"
jnthn If we rewrote that into a normal call then the inliner could nom it I guess :)
timotimo in general we don't turn things that invoke via "a thing in some spec" into a bare invocation yet
13:29 skids joined
jnthn ah, ok 13:29
Probably not too hard, and would likely bring the while @b { } case in line with the others 13:30
14:03 perlpilot joined, tomboy64 joined 14:21 |Tux| joined
lizmat dalek dead ? 15:00
lizmat just pushed github.com/rakudo/rakudo/commit/af...47f6a4e64d 15:01
"Re-imagine MAIN parameter parsing"
- introduce $*MAIN-ALLOW-NAMED-ANYWHERE
- if set with True value, will allow named parameters anywhere
- should allow "panda install --foo" to work
- initialized from environment variable MAIN_ALLOW_NAMED_ANYWHERE
perlpilot lizmat++ 15:03
Once people get used to it, do you think that will become the default?
lizmat the majority of P6 people at QAH thinks so, yes :-)
necessary diff for that: 15:04
- %*ENV<MAIN_ALLOW_NAMED_ANYWHERE> // 0;
+ %*ENV<MAIN_ALLOW_NAMED_ANYWHERE> // 1;
tadzik perlpilot: I do hope so :}
perlpilot was hoping too, I just didn't know if there was any push back from anyone. 15:05
tadzik I'd go so far as to say 100% p6 people agree
(on the qah)
timotimo hm, wouldn't we want to have a "perl6" in the environment variable name?
lizmat afaik, TimToady wasn't in favour of this behaviour
perlpilot because of the deviation from normal signature processing for MAIN? 15:06
lizmat timotimo: if anything, I think it should be a RAKUDO_ prefix ?
perlpilot: I believe so 15:07
perlpilot +1 (RAKUDO_ prefix)
lizmat then that would also need to be done for DEFAULT_READ_ELEMS
timotimo oh, yeah 15:08
lizmat if the consensus here it should be both, I'll do that :-) 15:09
perlpilot aye. 15:10
15:20 dalek joined, synopsebot6 joined
dalek kudo/nom: 2b06f71 | lizmat++ | src/core/ (2 files):
Add RAKUDO_ prefix to environment vars

  - DEFAULT_READ_ELEMS
  - MAIN_ALLOW_NAMED_ANYWHERE
As per irclog.perlgeek.de/p6dev/2016-04-22#i_12378252		 15:22
15:29 [Coke] joined
lizmat m: my $a := once 42; $a = 666; say $a # this feels wrong, note it's binding, not assigning 15:29
camelia rakudo-moar af1458: OUTPUT«666␤»
[Coke] yup, still hate IRC and my client.
anyone know what happened to hack? 15:30
(I see timotimo had to reboot it...)
timotimo yeah, sorry about that
15:34 japhb joined
perlpilot timotimo: I take your apology to imply that you broke hack somehow? 15:37
TimToady 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:43
env vars are a bit like Vise Grips®, the wrong tool for every job, but it'll do every job 15:45
15:46 masak joined
TimToady for instance, what if you call a subprocess that *isn't* expecting arg reordering, does it break? 15:47
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:49
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:53
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:54
merely mushing all the options together does not really accomplish this 15:55
15:55 astj joined
TimToady so more like a MAIN that can delegate to sub-MAIN processors 15:56
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
lizmat TimToady: wrt env variable: it felt more it was for debugging
RabidGravy TimToady, y'know that you only need three things to effect any repair - a hammer, gaffer tape and wd-40 :) 16:00
lizmat but you have a point about subprocesses :-)
TimToady dynamic scoping is always kind of an attractive nuisance
16:01 perlpilot joined
TimToady 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:01
dalek kudo/nom: 3ebf31e | lizmat++ | src/core/Main.pm:
No longer use env for $*MAIN-ALLOW-NAMED-ANYWHERE
 16:03
perlpilot TimToady: but, what do you think about making arg reordering for MAIN the default? 16:12
TimToady in general, I don't like throwing away information by default 16:14
I'm fine with an explicit reorder-args() call though 16:15
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:16
timotimo perlpilot: it broke by itself, i'm afraid 16:17
16:26 M-tadzik joined 16:36 japhb joined
dalek kudo/nom: 8865365 | lizmat++ | lib/Test.pm6:
Fix '#' escaping

As suggested as part of leont++ 's PR #578		 16:42
kudo/nom: 3ec6b36 | lizmat++ | lib/Test.pm6:
Update copyright date
 16:45
16:57 hankache joined 17:02 japhb joined 17:10 hankache joined 17:16 TimToady joined
dalek kudo/nom: 0b8e08a | lizmat++ | lib/Test.pm6:
Streamline Test.pm a bit

Basically, lose scopes when we can. Unscientifically appears to save me 10 seconds wallclock on a spectest.		 17:23
17:36 brrt joined 17:49 sno joined
lizmat drink! & 17:57
18:29 FROGGS joined
perlpilot 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:30
The ++foo ... ++/foo style options (are those even implemented?) are close in that they can provide a bounded area for separate processing 18:33
TimToady 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
it's a little bit like how map matches a signature to part of an argument list 18:35
but extended to named args 18:36
perlpilot Lazy Capture transformation feels right.
TimToady lunch feels about right :) & 18:39
19:00 psch joined
psch perlpilot: i've recently revisited rakudo PR #324, which implements the ++ opts 19:01
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
it's also something that could/(was speculated to) handle what PR #752 tries to 19:04
the ++ opts that is 19:05
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:09
although i haven't thought too much about how that would interact with post-program opt parsing 19:10
19:27 brrt joined 20:18 sortiz joined 20:57 cognominal joined 21:55 lizmat joined
MadcapJake What about something like `sub install (Str $name, Bool :$force) is subcommand<MAIN> { ... }` which would allow nested subcommands and each signature would be arguments before any deeper subcommand. 21:57
hoelzro that sounds like the purview of a module 22:01
MadcapJake Perhaps. Also seems like something that could just be powerful/complete ootb. 22:14
dalek kudo/nom: b3d8169 | lizmat++ | lib/Test.pm6:
Nativy counter for a small speedup
 23:04
lizmat good night, #p6dev! 23:23
masak 'night, lizmat++ 23:24

Powered by Cro and the Raku® Programming Language.

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

Thank you!