»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'p6: say 3;' or rakudo:, std:, or /msg camelia p6: ... | irclog: irc.perl6.org | UTF-8 is our friend!
Set by masak on 12 May 2015.
00:05 Possum joined 00:09 aborazmeh joined, aborazmeh left, aborazmeh joined 00:14 lizmat left, awwaiid left, lizmat joined
[Coke] m: my @a = "foo"; my @b = @a.reverse; use Test; isa-ok(@b, Iterable).say 00:18
camelia rakudo-moar f185e0: OUTPUT«ok 1 - The object is-a 'Iterable'␤True␤»
[Coke] (there's a glr change)
ShimmerFairy psch: we have floating point if you use :16 -> :16<4*16**2> (if I understand 'p' to raise to a power of 16) 00:31
And you can't use a radix point outside of :16<> because it can be ambiguous, e.g. 0xFA.CE (did you mean a fractional 0xCE/0x100, or a method call .CE ?) 00:32
psch ShimmerFairy: my reading re: the java format was a bit shallow, the format is e.g. 0x123.456p0F 00:35
ShimmerFairy: i don't see why we couldn't have the fractional decimal point for hex lits, if we can have it for dec lits 00:36
ShimmerFairy: the parser state should be similarly unambiguous, if i'm not missing something
oh wait 00:37
i do see it
we can't have methods that starts with a digit
but do have methods that starts with <[ABCDEabcde]>
"For example: 0x123.456 should be evaluated as 1*16*16 + 2*16 + 3 + 4/16 + 5/16/16 + 6/16/16. " from www.herongyang.com/Java/Primitive-T...Point.html for java again 00:38
i don't think we need fractional literals for hex (or oct or bin), in any case 00:39
m: say <0o1/0o2>; 00:41
camelia rakudo-moar f185e0: OUTPUT«Attempt to divide by zero using div␤ in block <unit> at /tmp/vYk24LVPvc:1␤␤Actually thrown at:␤ in block <unit> at /tmp/vYk24LVPvc:1␤␤»
psch nqp-m: say(~+"0o1")
camelia nqp-moarvm: OUTPUT«0␤»
psch that's the actual bug i've been looking at
j: say <0x01/0x02> # reported with this example
camelia rakudo-jvm f185e0: OUTPUT«Attempt to divide by zero using div␤ in block <unit> at /tmp/Cpk4_3Mg2a:1␤␤Actually thrown at:␤ in block <unit> at /tmp/Cpk4_3Mg2a:1␤␤»
psch and i'm thinking we're doing wrong in letting the backends handle that conversion 00:42
which is what i'm about to write into the ticket because i'm obviously getting a bit tired :)
ShimmerFairy psch: if there's something in the spec showing that (I'm sure there is), then that's just a bug in Rat literals for P6 :) 00:43
psch i think the bug is actually "we don't have &val yet" 00:45
ShimmerFairy Not really, since <1/2> is just a literal Rat, and I know there's a parsing rule for it
m: say <1/2>; say <1/2>.WHAT
camelia rakudo-moar f185e0: OUTPUT«0.5␤(Rat)␤»
psch right, but the parsing of nu and de relies on backends knowing the rakudo Int(Str) conversion rules 00:47
ShimmerFairy A quick look tells me there's nothing in the spec to suggest <0x1/0x2> should work, surprisingly
psch hm 00:49
ShimmerFairy Although the parser is set up to allow it :) 00:50
psch std: <0x1/0x2> 00:51
camelia std 28329a7: OUTPUT«ok 00:00 134m␤»
psch std: < 0x1/0x2 >
camelia std 28329a7: OUTPUT«ok 00:00 134m␤»
ShimmerFairy In reality it should be taking the ast of $<nu> and $<de>, not making its own constants out of numifying the matched strings 00:52
psch the bit with space next to the angle brackets is the one that could use val(), as i just read in S02... 00:54
i have to say i'm a bit stumped what exactly to understand under "constant folding" 00:57
...oh
thanks google
i'll go to bed :) 00:58
i'll try passing the AST when i find some more time, and i added this last bit of discussion to the ticket as well, g'night o/ 00:59
ShimmerFairy psch: ♞ o/ I worked on numeric-literal-related code recently, so there's a chance I'll add tests and fix it in the meantime :) 01:00
01:04 laouji joined 01:09 oetiker left 01:19 oetiker joined
TimToady okay, shinkansen tickets acquired for 京都 --> 東京. 01:21
yoleaux 16 Aug 2015 18:14Z <laben> TimToady: i would like to ask you what do you think of restricting (multi) methods definitions of a class with the (multi/proto) methods signature of composited roles
ShimmerFairy Well, my original question was about requirements, not restrictions :) 01:41
m: role R { method M($a, $b) {...} }; class C does R { method M($c) { say $c } }; C.M(42) 01:42
camelia rakudo-moar f185e0: OUTPUT«42␤»
ShimmerFairy If that's considered a bug in stubbed role methods, then I don't see how requiring specific multi method sigs would be much more effort :)
lizmat
.oO( biting the bullet from Kyoto To Tokyo: an anagramic journey )
 01:43
ShimmerFairy lizmat: did you implement the $? restriction? 01:45
lizmat I think so 01:46
m: my constant $?FOO = 42
camelia rakudo-moar f185e0: OUTPUT«5===SORRY!5=== Error while compiling /tmp/VFeGxVNqlx␤Cannot use ? twigil on 'my' constant because it is reserved␤at /tmp/VFeGxVNqlx:1␤------> 3my constant $?FOO = 427⏏5<EOL>␤»
lizmat m: my $?FOO = 42
camelia rakudo-moar f185e0: OUTPUT«5===SORRY!5=== Error while compiling /tmp/lHYeppDipe␤Cannot use ? twigil on 'my' variable because it is reserved␤at /tmp/lHYeppDipe:1␤------> 3my $?FOO7⏏5 = 42␤»
01:46 llfourn joined
ShimmerFairy m: constant $?TABSTOP = 3; say $?TABSTOP; 01:46
camelia rakudo-moar f185e0: OUTPUT«5===SORRY!5=== Error while compiling /tmp/Z8v3rnnX7i␤Cannot use ? twigil on '' constant because it is reserved␤at /tmp/Z8v3rnnX7i:1␤------> 3constant $?TABSTOP = 37⏏5; say $?TABSTOP;␤»
lizmat ShimmerFairy: is tat wat you meant ? 01:47
*that
ShimmerFairy ^ that's spec'd to work (setting TABSTOP at compile-time). Either that's a bug in the impl, or it should be $*TABSTOP now.
lizmat well, good point
ShimmerFairy From S02: All C<$?> variables are considered constants, and may not be modified after being compiled in. The user is also allowed to define or (redefine) such constants: 01:48
the following code sample being constant $?TABSTOP = 4
lizmat it was such that { my constant $?TABSTOP = 42; say $?TABSTOP } would say 8 (because it would have gotten constant folded)
so it wasn't working as specced to begin with 01:49
01:51 llfourn left
ShimmerFairy So, should $?TABSTOP be $*TABSTOP (since you're supposed to be able to change it), or would it be better if $? were made to work more to spec? 01:51
I would suggest going more to spec, but then again I'm not sure about people being able to change things like $?LINE or %?META 01:54
lizmat I would like jnthn and TimToady's opinion on that 01:55
ShimmerFairy $?TABSTOP is admittedly the odd one out of $? vars, since it's designed to be user-set :) 01:56
lizmat yeahj...
so maybe it *should* be $*TABSTOP
ShimmerFairy If you are able to set $? at compile-time, I think I would prefer if you had to set them in BEGIN {} phasers, or something else to explicitly say "at compile time"
lizmat actually, thinking about this more: $? guarantees immutability
well, 'my constant' means compile time to me 01:57
ShimmerFairy Interesting, I don't think of the 'constant' keyword as inherently compile-time, though I see why :) 01:58
lizmat otoh, 'my constant $foo = $a + $b' may not fit that bill
m: my $a = 42; my $b; my constant $foo = $a + $b
camelia rakudo-moar f185e0: OUTPUT«Use of uninitialized value of type Any in numeric context in block at /tmp/QKgfj3Bdtm:1␤Use of uninitialized value of type Any in numeric context in block at /tmp/QKgfj3Bdtm:1␤»
lizmat m: my $a = 42; my $b; my constant $foo = $a + $b; say $foo
camelia rakudo-moar f185e0: OUTPUT«Use of uninitialized value of type Any in numeric context in block at /tmp/w9Q0j3yFw1:1␤Use of uninitialized value of type Any in numeric context in block at /tmp/w9Q0j3yFw1:1␤0␤»
lizmat m: my $a = BEGIN 42; my $b; my constant $foo = $a + $b; say $foo 01:59
camelia rakudo-moar f185e0: OUTPUT«Use of uninitialized value of type Any in numeric context in block at /tmp/QQGKV0xCAE:1␤Use of uninitialized value of type Any in numeric context in block at /tmp/QQGKV0xCAE:1␤0␤»
ShimmerFairy m: my $a = 42; my $b = 21; my constant $foo = $a + $b; say $foo;
camelia rakudo-moar f185e0: OUTPUT«Use of uninitialized value of type Any in numeric context in block at /tmp/ZiS5cxx64H:1␤Use of uninitialized value of type Any in numeric context in block at /tmp/ZiS5cxx64H:1␤0␤»
lizmat m: BEGIN my $a = 42; my $b; my constant $foo = $a + $b; say $foo
camelia rakudo-moar f185e0: OUTPUT«Use of uninitialized value of type Any in numeric context in block at /tmp/pO5ShfxLf8:1␤42␤»
ShimmerFairy m: BEGIN my $a = 42; BEGIN my $b = 21; my constant $foo = $a + $b; say $foo
camelia rakudo-moar f185e0: OUTPUT«63␤» 02:00
ShimmerFairy Again, it makes sense to me while 'constant' is compile-time, it just didn't occur to me immediately :)
Yeah, the more I think about it, the more $?TABSTOP seems to be spec'd to act like a $* variable. I can't think of a reason it needs to be a compile-time value off-hand 02:02
02:03 geekosaur left
lizmat yeah, actually deprecating $?TABSTOP in favour of $*TABSTOP now 02:05
02:05 geekosaur joined
ShimmerFairy cool :) 02:06
02:26 aindilis left 02:29 aindilis joined, aindilis left 02:30 aindilis joined, noganex_ joined
lizmat am having second thoughts... 02:30
after reading the spec again 02:31
would like the feedback of TimToady and jnthn about taking this further
02:31 aindilis left
lizmat feels like forbidding it, like I did, is the bug, *not* the way it was specced 02:31
02:32 aindilis joined
lizmat so before I start changing this, the spec should be changed :-) 02:32
ShimmerFairy lizmat: fair enough, though I still see TABSTOP as as *-y variable :)
02:33 noganex left
ShimmerFairy lizmat: Like I said, I'm not sure if I want people to be able to modify $?LINE and such, so I'm tempted to say that they're read-only compiler constants. 02:33
lizmat well, there are good reasons to be able to modify $?LINE
e.g. if you want to filter out the pod of a source file, but still want to retain the line numbers 02:35
ShimmerFairy Yeah, I can see that. And depending on how $?LINE works (I don't know), you could also set it to various ridiculous values as a form of finding the source of an issue :P 02:36
02:36 geekosaur left
ShimmerFairy lizmat: could there be a way to reset $? values, aside from lexical scoping? First thing that comes to mind is constant $?LINE = $?CORE::LINE or something. 02:37
02:37 geekosaur joined
ShimmerFairy (It's something that would be helpful if an inner scope wanted to be sure it had the compiler's value for a $? constant, for example) 02:39
lizmat the way World.add_constant works, is that it builds a compile time cache of values, and generates a Wval for it
02:40 cibs_ joined
ShimmerFairy Ah, so I'm guessing the compiler (at least currently) doesn't preserve its would-be-default values for $? things? 02:41
02:43 cibs left
ShimmerFairy m: say "ABC".match(/abc/, :i); say "ABC".match(/:i abc/) 02:43
camelia rakudo-moar f185e0: OUTPUT«Nil␤｢ABC｣␤»
ShimmerFairy Huh, I wonder if those two should be equivalent
dalek kudo/glr: b9000b8 | skids++ | src/core/Str.pm:
Reimplement :x and :nth regex modifiers on match, thus fixing comb
 02:45
kudo/glr: 88e439c | lizmat++ | src/core/Str.pm:
Merge pull request #498 from skids/glr

Reimplement :x and :nth regex modifiers on match, thus fixing comb
02:45 cibs joined
lizmat ShimmerFairy: :$i is not a named param of Str.match 02:46
ShimmerFairy lizmat: yeah, I was looking at subst-mutate and thought "hey, I see :ii here, but I didn't see :i in match. I wonder..." :) 02:47
lizmat perhaps an oversight, not sure
ShimmerFairy lizmat: My guess is that adverbs that can go in the regex (that is, /:i abc/ or /ab :r c/) aren't handled by .match 02:48
lizmat yeah, but that could still be a WAT for many?
ShimmerFairy I don't know if it should or not. (I'm writing a new version of S32::Str, as part of trying to improve strings and such in P6, so I'm bound to run into design stuff ☺) 02:49
02:49 cibs_ left
ShimmerFairy On the one hand, adverbs that can go inside are probably best left to handle stuff inside, without .match overriding behavior. On the other hand, you would think anything that can go m:HERE// could be passed to .match 02:50
lizmat m: my @a; @a.push: [1,2,3]; say @a.elems 02:52
camelia rakudo-moar f185e0: OUTPUT«1␤»
lizmat so, GLR is supposed to be less flattening
$ 6 'my @a; @a.push: [1,2,3]; say @a.elems'
3
I would argue it is flattening more... at least in this case...
ShimmerFairy for .push, that pretty clearly should be like in pre-GLR (pushing an Array into an Array) 02:53
lizmat m: sub a(*@a) { say @a.elems }; a [1,2,3] # underlying difference
camelia rakudo-moar f185e0: OUTPUT«1␤»
lizmat $
$ 6 'sub a(*@a) { say @a.elems }; a [1,2,3]'
3
so a slurpy will flatten no matter what ? 02:54
ShimmerFairy @a = [1,2,3] or @a = [1,2],[3,4]; @b = @a[0] are interesting and possibly related. (should @a in the first one be [1,2,3] or [[1,2,3]], should @b be [1,2] or [[1,2]])
lizmat m: sub a(*@a) { say @a.elems }; a (1,2,3) 02:57
camelia rakudo-moar f185e0: OUTPUT«3␤»
skids Well, :i is one of the adverbs that an implementation may require to be known at compile time, FWIW. 02:58
ShimmerFairy m: my $a = "a :i b"; say "aB" ~~ /<$a>/
camelia rakudo-moar f185e0: OUTPUT«｢aB｣␤»
lizmat hmmm.. so now that () is a List, and Array is a mutable List
I guess from that follows that [1,2,3] will flatten in the face of s slurpy 02:59
ShimmerFairy skids: ^ so that example shouldn't work, or shouldn't be expected to?
lizmat m: say Array.^mro
camelia rakudo-moar f185e0: OUTPUT«(Array) (List) (Iterable) (Cool) (Any) (Mu)␤»
skids It's optional for an implementation.
ShimmerFairy rakudo seems to show it's not impossible :) (and besides, an optional feature is new to me in P6, might as well require it) 03:00
ShimmerFairy afk for a bit
skids Well, depending on what "known at compile time" means to the implementation.
The spec language is An implementation may require 03:01
that their value is known at compile time, and give a compile-time error
message if that is not the case.
03:02 kaare_ joined
skids One could argue that "compile time" for /<$a>/ is formally defined as when the clone is made. 03:03
(or something)
But with .match you may have an rx from another compunit, and so cannot compile it in. 03:14
lizmat sightseeing& 03:15
03:16 ShimmerFairy left 03:27 aborazmeh left 03:28 ShimmerFairy joined 03:29 cognominal left
ShimmerFairy m: my $a = (0..1).pick; say "ABC" ~~ m:i($a)/abc/ 03:33
camelia rakudo-moar f185e0: OUTPUT«5===SORRY!5=== Error while compiling /tmp/WTvFeq097u␤Adverb i value must be known at compile time␤at /tmp/WTvFeq097u:1␤------> 3y $a = (0..1).pick; say "ABC" ~~ m:i($a)7⏏5/abc/␤»
ShimmerFairy huh
Well, considering non-deterministic parsing is explicitly possible, I don't see why the :i adverb and others like it have to be compile-time 03:34
m: my $a = "a {(":i","").pick} b"; say "aB" ~~ /<$a>/ 03:36
camelia rakudo-moar f185e0: OUTPUT«Nil␤»
ShimmerFairy m: my $a = "a {(":i","").pick} b"; say "aB" ~~ /<$a>/
camelia rakudo-moar f185e0: OUTPUT«｢aB｣␤»
ShimmerFairy seems to me rakudo complaining about :i($a) is perhaps unnecessary, considering the other randomized ways I've been able to introduce the :i adverb :)
03:40 cognominal joined
skids Whenever you use <$a> you're performing something akin to an EVAL, and that's got its own compile time. But if you have an rx from another file, there's no way to add :i o it -- it does not come with source code. 03:43
03:47 llfourn joined 03:52 skids left
ShimmerFairy skids: The way I see it, either we lift the compile-time restriction on :i and friends (since I still don't see how it's ~so impossible~ otherwise), or we disallow using them as m:i//, and force them in m/:i/ , so that the distinction between types of adverbs is clear. 03:52
03:52 llfourn left 03:53 ChoHag joined 03:55 Norelec joined
masak morning, #perl6 04:08
yoleaux 12 Aug 2015 08:42Z <laben> masak: could you please accept the two PR for masak/ufo? it would make my life much easier, thanks :)
ShimmerFairy o/ masak 04:09
masak laben: merged. 04:10
I gather I have some catching-up to do. 04:14
04:14 khw left 04:16 skids joined, llfourn joined 04:17 inokenty left
skids I don't see how whether soething goes inside or outside the // has a bearing on whether it is compile-time-only. 04:18
04:18 aborazmeh joined, aborazmeh left, aborazmeh joined, mr-foobar left
skids NM, I see that is the distinction in fact, rereading the specs. 04:19
But I don't think removing m:i does anyone any good. 04:20
ShimmerFairy skids: the issue is that not _everything_ that goes m:HERE// can be given as .match(:HERE), so if there's no way to make, say, .match(:i) work, I'd rather we had a more easily-understood usage of adverbs.
masak the technical problem is, I think, that the :i gets compiled into the regex. 04:21
(sorry if this is stating the obvious. I was backlogging what was on my screen.)
skids Well, I don't see the need for consistency there. 04:22
And m:i// is something P5 users are going to want.
ShimmerFairy I've never really had a good understanding of which adverbs can and can't go inside the regex, so perhaps forcing the ones that get compiled into the regex to be, well, in the regex would help others there :)
masak I do think there's some kind of difference between, say, :i and :g
ShimmerFairy skids: I think P5 users really want m//i though :P
masak :i talks about how to perform the string matching itself. :g only talks about how many times, which is a lot more external. 04:23
ShimmerFairy I just think it's very unfortunate that someone can use m:g:i// (for example), then discover the match method and then see that .match(//, :g, :i) doesn't work as expected. 04:24
skids I think people are more likely to do .match(rx:i//) anyway. 04:25
ChoHag :i determines what is matched with, :g what is matched against.
ShimmerFairy (and then you have to learn that you either need to do rx:i// or /:i / for the method form. Oh, but don't try rx:g// or /:g /)
masak ChoHag: yes, that's what I wanted to express.
ChoHag: kind of a client-server distinction, almost.
ShimmerFairy skids: I don't think so. I've never used rx myself, and whenever I see someone use it my first reaction is "that's not P6 enough", because of how much I don't see it :) 04:26
ChoHag Or: :i affects what the regex is, :g how to use it.
ShimmerFairy I don't disagree with the difference between :i adverbs and :g adverbs, just that if the difference cannot be reconciled enough to allow .match(..., :i), then I'd like it if they didn't act like it for the m// form either 04:27
04:27 shmibs_ is now known as shmibs
ShimmerFairy (in other words, since :i affects the regex itself, it should be inside the regex) 04:27
masak ShimmerFairy: I.. don't see how making things more inconvenient just for the sake of consistency is a good idea. 04:28
skids Well, we'll have to agree to disagree.
masak ShimmerFairy: m:i// in my mind is identical to m/ :i /
ShimmerFairy masak: yeah, I realize it wouldn't be a good move (I'd prefer making .match(:i) work if for consistency) :)
masak: then why shouldn't .match(/:i/) be identical to .match(//, :i) ? :P 04:29
masak ShimmerFairy: I would advise that at this point, you spend tuits on preparing a patch (in a branch or a PR) making things better in the way you envision.
ShimmerFairy: because the adverbs to a regex are different than the adverbs to a .match? 04:30
ShimmerFairy: seems pretty obvious to me.
ShimmerFairy masak: sure, but the distinction is muddled when it comes to adverbs m:HERE//
masak well, I don't.
think so*
ShimmerFairy Like I said, I've never had a clear understanding of what adverbs can go inside and which ones must go outside, and I surely can't/won't be the only one. 04:31
I just think it's supremely unfortunate that adverbs that can go m:HERE// can't automatically go .match(//, :HERE) 04:32
ChoHag Isn't m/.../ just a fancy way of saying match(compile-rx('...'))?
masak ShimmerFairy: I suspect you'll learn a lot about it in preparing the patch :)
ChoHag: I think so, yes.
ChoHag: and compile-rx('...') can be written /.../, unless you accidentally boolify the /.../ 04:33
ChoHag So adverbs m:HERE// affect match() and compile-rx(), the latter of which may ignore them if they don't make sense in its context?
ShimmerFairy masak: yeah, I'd likely want to make the fix myself sometime. :) If we were still in the early days, I'd seriously suggest disallowing m:i//, and only allowing m/:i /, so that the distinction between kinds of adverbs was clear
ChoHag So are there any adverbs which must be m/:HERE/ but can't be m:HERE//? 04:34
04:34 BenGoldberg left
skids Well, .match(//,:i) might be doable as a macro :-) 04:34
04:34 inokenty joined
ShimmerFairy ChoHag: more an issue for m:HERE// not always possible rx:HERE// 04:35
ChoHag rx// being the 'compile-rx' part?
ShimmerFairy (some adverbs like :g can't be applied to the regex, so rx:HERE// or /:HERE / will complain) 04:36
My issues stems from the fact that e.g. m:i/<stuff>/ is an alternate form of m/:i <stuff>/, but .match(/<stuff>/, :i) doesn't do the same. 04:37
skids Really that adverb slot on match is there for |%thistime use. 04:38
There's no other reason to even have it. 04:40
ShimmerFairy which adverb slot?
skids The whole reason for accepting adverbs on .match at all.
ShimmerFairy skids: but if you got rid of that, how can .match be passed :g ? 04:41
skids It wouldn't. But it's not a necessary method to even have.
(unless you want |%thistime type stuff) 04:42
masak ShimmerFairy: from my point of view, disallowing m:i// is weird because it's just a convenient shorthand for m/ :i /
ShimmerFairy I would very much disagree. How else would you match a generic my Regex $rx ?
(disagree to skids)
skids "string" ~~ $rx
ShimmerFairy Sure, there's m:g/<$rx>/ , but that has got to be inefficient 04:43
masak: yeah, like I said I wouldn't seriously suggest it by now :) My issue lies more with letting .match accept more adverbs that can show up m:HERE// , if feasible :) 04:44
04:45 cognominal left
skids Well, if we want to support "is parsed" on method arglists maybe someday. 04:48
but then you would need to know the invocant type at compile time. 04:50
(and it still would not work on $rx) 04:54
ShimmerFairy Well, .match and friends certainly won't be going away, they're useful alternatives to topicalizing the string you want to match :) (and, for me, .trans makes infinitely more sense as a method than whatever tr/// syntax is like) 04:56
skids I don't want .match to go away, it's a useful convenience.
just don't see the big deal when theres the recourse of .match(rx:i//, :g) 04:58
ShimmerFairy skids: of course, I'm just saying that I'd like it if stuff that goes m:HERE// could always go .match(//, :HERE) :) 04:59
skids I know you've said it several times already :-)
ShimmerFairy If things like :i can't be reasonably supported in .match, then I'd be fine. I'd just appreciate a bit more of a straightforward conversion from m// to .match if possible :) 05:01
And if support is not possible, then warnings/errors in .match for impossible adverbs would be nice :) (in fact, that might be a reasonable thing to implement now, regardless) 05:03
skids BTW, when $rx is of Regex there's no real reason for /<$rx>/ to be especially inefficient, it's when $rx is Str that chews things up. 05:05
I don't think there will be much support for hacking off m:i// 05:06
m: my Regex $r = rx/Ab/; { say $_ ~~ m:i/<$r>/ } for "Ab", "ab"; # because the :i is lexical to the rx. 05:13
camelia rakudo-moar f185e0: OUTPUT«｢Ab｣␤False␤»
05:16 Norelec left 05:17 [Sno] left
ShimmerFairy skids: on the one hand that's surprising, since in that example I kinda expected :i to persist through subrule calls (like it were setting state), but I can immediately see why regex rules need control over their operating conditions :) 05:19
skids Anyway, I have dieseled on way past my bedtime. 05:21
05:22 skids left
ShimmerFairy masak: btw, I think the most interesting to happen since you were last here was the beginning of rakudo/glr :) 05:25
05:28 baest_ is now known as baest
Sgeo Does information only go from regex -> action, or can there be action -> back to same regex communication? 05:53
ShimmerFairy I think dynamic variables may allow communication the other way 05:54
Sgeo I think I'd need to see an example 05:55
05:56 diana_olhovik joined
Sgeo Hmm I think the way Racket does dynamic variables is interesting: docs.racket-lang.org/guide/parameterize.html 05:57
A dynamic variable cell, so to speak, gets stored in a lexically scoped variable, so functions that refer to it always refer to the correct cell, rather than it being name based 05:58
So less of a risk of false positives as described perl6advent.wordpress.com/2012/12/...mment-2054
"(i.e. someone else declares a dynamical with the same name, causing the inner sub to think it’s in the outer when it isn’t). But this risk is inherent in this use of dynamicals, not in the error munging."
ShimmerFairy m: grammar G { token TOP { :my $*A = 1; <subrule> [<?{$*A}> <subrule>||b] }; token subrule { a } }; class C { method subrule($/) { $*A = 0 } }; say G.parse("aa", :actions(C)); say G.parse("ab", :actions(C)) 05:59
camelia rakudo-moar f185e0: OUTPUT«(Any)␤｢ab｣␤ subrule => ｢a｣␤»
Sgeo I don't think I understand enough to actually process that, but the gist of it is a regex defines a dynamic variable, then the action gets run in the dynamic scope of that regex and so can set that same dynamic variable, then the regex proceeds to continue to use it? 06:03
ShimmerFairy yep 06:04
It's the dynamic equivalent of my $a = 42; { $a = 5 }; say $a (says 5) 06:05
06:09 rurban joined
arnsholt my $*a 06:11
m: sub foo { my $*a; bar; say $*a }; sub bar { $*a = 5 }; foo # Should do the trick 06:12
camelia rakudo-moar f185e0: OUTPUT«5␤»
06:12 jack_rabbit_ joined, telex left
arnsholt Sgeo: There's a fair number of examples of that pattern in the NQP and Rakudo grammars 06:13
That's NQP code, so slightly different in that it uses := instead of = and such, but the pattern is the same
06:14 jack_rabbit_ left, telex joined, rurban_ joined
ShimmerFairy Yeah, the NQP and Rakudo grammars show the real utility of dynamic variables :) (because those declared variables are local to their declaration (so, they aren't global vars), but can be accessed by subrules and their associated action methods) 06:16
Sgeo I kind of want to make a unit that consists of a grammer+action, composable ala monadic parsing 06:17
Which is mostly my main point of reference
But I should learn more about grammars and actions first
raydiak I was always confused by the extensive use of dynamics in rakudo...isn't it bad practice to be passing stuff around "invisibly" in the dynamic scope instead of directly as arguments? seems like the same design smell you get from over-using globals 06:21
ShimmerFairy you can't really call action methods from the grammar, unless you were willing to do it for every rule yourself (AFAIK) 06:22
and also, arguments means you have to be conscious of everything a subrule/action method wants all the time, which would add a lot of noise to language grammars. (A lot of scalar dynvars are just "if I exist" type things, which would at best be replaced with nameds) 06:24
06:26 laben joined
raydiak I was given to understand that the usual way to pass data to the action was via the Match object (which also feels weird to me), but could just be an artifact of my usual confusion :) 06:26
laben hello p6'ers
raydiak \o
ShimmerFairy Finally, the main problem with globals, as I understand, is when they pollute the space of used variable names and make all kinds of code fragile. In a contained space I don't think they're so bad (and even end up being one of the nicest solutions). So even if dynvars are global-like in some cases, in the contained space of a grammar it's quite alright by me :)
laben masak: thanks for updating ufo, i really appreciate that. btw, if you are interested, i got a patch to fix Text::Markdown breakage 06:28
raydiak thanks ShimmerFairy, I at least have a better grasp on the reasoning now
masak laben: I'm interested. 06:30
laben: though I'm also working on a brand new lineage of Text::Markdown.
ShimmerFairy raydiak: it took me a while to really understand dynamic vars, but once I understood what they did and everything, they suddenly become really useful where you need them :) 06:31
laben masak: here it is, gist.github.com/ac0b788fac4e35f178be
ShimmerFairy raydiak: another example of "constrained globals" I can think of would be 'static' variables in C and C++ (where they're limited to the current translation unit). Static globals are more convenient than insistently passing things around as args in some cases, I'd imagine :) 06:32
raydiak sure 06:36
I guess I'm just recalling how much harder it made it to read and learn those parts of rakudo's internals 06:37
ShimmerFairy raydiak: like I said, it took me a long time to understand what dynamic scoping was, so for some time I had some trouble understanding why the * twigil was necessary (since for all I could tell they were practically the same as $normal vars (they aren't)) :) 06:38
06:39 hurricane left
raydiak I have, or at least feel like I have, a pretty decent understaind of their semantics...but until you know what $*W actually *is*, it's clear as mud, and the way I'd usually try to figure that out is by looking at where it's declared, but that can be very far removed from where it is being used 06:42
is that a problem unique to dynamics? no, not really...they just kinda make it worse
06:48 virtualsue joined
raydiak anyway, I'm certainly not advocating for a change...just educating myself :) it definitely does save some typing 06:48
06:50 espadrine joined
raydiak also nice that we have the * twigil so dynamics don't trample ordinary vars, and the reader gets a warning that something unusual is going on even if they don't know what it means 06:51
06:52 zakharyas joined 06:56 RabidGravy joined, virtualsue left
raydiak well I just dropped in to chat for a minute since I don't have the time I used to...I still miss you, #perl6! g'night \o 06:59
ShimmerFairy ♞ raydiak o/ 07:01
raydiak: and yes, I agree that it's nice to have a visual indicator of something special. Even when I thought they were "basically just lexicals", I knew there had to be _something_ different about them I wasn't getting :)
07:06 rindolf joined, domidumont joined 07:07 cognominal joined
masak I find a nice way to think of *-twigil variables is that instead of a certain lexical scope, they are tied to a *process*. 07:08
like, when I traverse a nested data structure, there might be several subs/methods involved to traverse it, each with its own lexical scope. 07:09
but if I want to share data between those, a contextual will do that for me.
it can always be replaced by painstakingly passing the same data in as parameters... but somehow those parameters tend to feel "secondary" or "auxiliary" to the call. 07:10
07:11 domidumont left
ShimmerFairy Now that I think about it, I wonder if my typical use of a $level parameter in a recursive function (for debugging and such) could be nicely done as a dynvar :) 07:11
07:11 domidumont joined
ShimmerFairy masak: whenever parameters are being passed around purely for the sake of keeping things local, I tend to think of that as a bit of a design smell (and inconvenient). I think Perl 6's dynvars let you avoid having to jump immediately to global variables in that situation. 07:12
I think the fact that they're also known as "contextual" variables reveals what their purpose is: to be an easy way of providing the appropriate context for things during execution. 07:14
07:16 brrt joined 07:19 baest left, baest joined 07:22 [Sno] joined 07:34 FROGGS joined
masak all that is correct, but note that dynvars/contextuals also introduce a potential contamination risk from third-party routines (such as callbacks) in the call chain. 07:49
either accidental or malicious/deliberately hacky. 07:50
ShimmerFairy I suppose in that case you would want to save the important values in some local vars before using a callback, and then restore them if necessary. 07:52
07:52 AlexDaniel joined
masak yes, but any such manual handling defeats the original savings of having a contextual in the first place. 07:54
also, it's suddenly something you have to remember to do.
07:54 rindolf left
ShimmerFairy Yeah, I think some nice way of isolating a callback would be nice. .oO( sub foo(&callback is quarantined) { ... } ) 07:56
masak easier just to "assume that third-party doesn't know about the contextuals" (security through obscurity) or "implicitly trust third party" (this mistake doesn't have a name, but it can definitely bite you)
m: sub traverse($root) { my $*level = 0; handle($root) }; sub handle($node) { say "handling node at level $*level"; $*level++; handle($_) for @$node; $*level-- }; traverse [ [[], []], [] ]
camelia rakudo-moar f185e0: OUTPUT«handling node at level 0␤handling node at level 1␤handling node at level 2␤handling node at level 2␤handling node at level 1␤»
ShimmerFairy Certainly would be something for S23 to cover, methinks :) 07:57
07:58 abraxxa joined
masak m: sub traverse($root, &*cb) { my $*level = 0; handle($root) }; sub handle($node) { &*cb($node); $*level++; handle($_) for @$node; $*level-- }; traverse [ [[], []], [] ], sub ($node) { say "handling node at level $*level" } 07:58
camelia rakudo-moar f185e0: OUTPUT«handling node at level 0␤handling node at level 1␤handling node at level 2␤handling node at level 2␤handling node at level 1␤»
masak m: sub traverse($root, &*cb) { my $*level = 0; handle($root) }; sub handle($node) { &*cb($node); $*level++; handle($_) for @$node; $*level-- }; traverse [ [[], []], [] ], sub ($node) { say "handling node at level $*level"; $*level = 47 } 07:59
camelia rakudo-moar f185e0: OUTPUT«handling node at level 0␤handling node at level 48␤handling node at level 48␤handling node at level 47␤handling node at level 46␤»
masak silly example, but shows the possibility. 08:00
08:06 aborazmeh left
masak I can see two solutions. one is to namespace your contextuals. 08:07
08:08 notch left
TimToady setting $*TABSTOP makes no sense for something that has to be known at compile time to handle heredocs 08:08
RabidGravy sends mail to p5p for the first time in about a year 08:09
masak m: sub traverse($root, &*Traversal::cb) { my $*Traversal::level = 0; handle($root) }; sub handle($node) { &*Traversal::cb($node); $*Traversal::level++; handle($_) for @$node; $*Traversal::level-- }; traverse [ [[], []], [] ], sub ($node) { say "handling node at level $*Traversal::level" }
camelia rakudo-moar f185e0: OUTPUT«Dynamic variable $*level not found␤ in sub traverse at /tmp/0plceBjwdu:1␤ in block <unit> at /tmp/0plceBjwdu:1␤␤Actually thrown at:␤ in any at src/gen/m-Metamodel.nqp:2867␤ in sub traverse at /tmp/0plceBjwdu:1␤ in block <unit> at /tmp/0…»
TimToady and I see no reason to forbid setting $?LINE or $?FILE either, since a preprocessor might well want to set those
masak it seems to parse just fine, but then it doesn't work at runtime. and it doesn't preserve the namespace in the error message either.
08:09 domidumont left
TimToady we just got soaked to the skin in a cloudburst here in Kyoto, -Ofun :) 08:10
masak TimToady: would `$?LINE = 42;` and `BEGIN { $?LINE = 42 }` both work but behave differently?
TimToady the latter would be scoped to the BEGIN 08:11
masak why? I'm not declaring it.
TimToady well, except they should really be declared constant
or my constant
masak ok.
ShimmerFairy yeah, the spec example shows constant $?TABSTOP = 4
08:11 espadrine left
masak the other solution I could think of to get safe, encapsulated dynamicals: symbols, a la Lisp and ES6. 08:12
TimToady well, that was before we decided to treat constants like other typish things
masak I think we're likely-ish to end up with symbols anyway, due to macros...
ShimmerFairy So $? vars should be compile-time assignable, instead of changing the usefully modifiable ones to $* :)
masak std: constant FOO = 5
camelia std 28329a7: OUTPUT«ok 00:00 135m␤»
TimToady std: constant $?LINE = 42 08:13
camelia std 28329a7: OUTPUT«ok 00:00 136m␤»
laben m: role R { method M($a, $b) {...} }; class C does R { method M($c) { say $c } }; C.M(42)
camelia rakudo-moar f185e0: OUTPUT«42␤»
ShimmerFairy masak: my understanding of macros nowadays is that (in one sense) they're meant to eliminate repetitious syntax, like how functions eliminate repetitious execution. Is that a correct view? 08:14
masak ShimmerFairy: yes, I like that view.
ShimmerFairy really hopes Perl 6 macros will eventually let her finally understand exactly what good macros are for :)
masak ShimmerFairy: it's not the whole story, but it's a fair part of it.
laben ShimmerFairy: the problem here is that role composition is after class methods definitions and during composition it checks if a method with that name is installed
08:14 domidumont joined
masak macros provide syntactic relief. 08:14
laben ShimmerFairy: since it's already there, it just skips to the next 08:15
masak laben: arguably, since they are both onlys, some kind of signature mismatch should be flagged up.
ShimmerFairy masak: that view comes from using "lexical" macros in C++ because I didn't want to copy-and-paste a wall of text that was just slightly-changing syntax each time
laben masak: i agree, it would be useful, but what you say is not specced nor implemented 08:16
ShimmerFairy The original question comes from me wanting to stub multi methods in a role so that those specific multis are required, just like stubbed only methods require their implementation. 08:17
masak laben: that is correct.
laben: and "contextual contamination" is so far only a hypothetical worry.
laben masak: now yesterday i was wondering if it's interesting/useful to spec and implement
masak: what do you mean by "contextual contamination"? 08:18
ShimmerFairy (I get the feeling that macros in any language are where the language says "we can't by-default implement what you want, you have to do it now") 08:19
masak laben: Text::Markdown patch applied. thank you.
ShimmerFairy Ideally the RoleToClassApplier would check signatures when it comes to stubbed things, and implement the support for multi method stubbing too, perhaps
masak laben: I mean the thing I just demonstrated above, with the callback. 08:20
ShimmerFairy m: role R { method M($a, $b) { } }; class C does R { method M($c) { } }; say C.M(1,2) # this is almost certainly wrong 08:21
camelia rakudo-moar f185e0: OUTPUT«Too many positionals passed; expected 2 arguments but got 3␤ in method M at /tmp/rzC29XHd8E:1␤ in block <unit> at /tmp/rzC29XHd8E:1␤␤»
ShimmerFairy m: class C { method M($a, $b) { }; method M($c) { } }; say C.M(1,2)
camelia rakudo-moar f185e0: OUTPUT«5===SORRY!5=== Error while compiling /tmp/9j7Kqzzv8t␤Package 'C' already has a method 'M' (did you mean to declare a multi-method?)␤at /tmp/9j7Kqzzv8t:1␤» 08:22
ShimmerFairy I'm starting to get the feeling that the RoleToClass applier (and perhaps RoleToRole too) need some improvements :)
laben ShimmerFairy: as i was saying, no checking of signatures is done for either the only case or the multi case. just the name is checked when composing a role, which is done after a class is defined. since you define the method in the class, it finds the method ans skips to the next 08:26
ShimmerFairy: maybe this part should be considered NYI instead of vaguely not specced 08:27
ShimmerFairy yeah, RoleToClass seems to be avoiding handling dispatcher-stuff (at least for multis), so it seems it tries to deal with as little as possible. That's clearly not sufficient, though :)
laben ShimmerFairy: the trouble consists basically in the amount of code you would need to check signatures there 08:28
ShimmerFairy: the code in Signature that does that in BOOTSTRAP is *ginourmous* 08:29
it would be much easier if we could reuse somethign from there
there's even an ad hoc implementation of toposort 08:30
ShimmerFairy laben: do you mean Routine? (where I looked at find_best_dispatchee last night)
laben ShimmerFairy: yeah right, it's not signature
08:31 inokenty left
ShimmerFairy laben: if we were interested in code reuse, then I'm fairly confident it would have to go Metamodel -> BOOTSTRAP, I'm not sure code can be called the other way :) (could be wrong, though) 08:31
laben ShimmerFairy: sorry, can you explain a bit more? i'm a noob at this, just started yesterday 08:32
you mean BOOSTRAP includes Metamodel?
ShimmerFairy I don't know if the Metamodel stuff would ever be able to access things defined in BOOTSTRAP, so the code to be reused would have to live in Metamodel and be called by BOOTSTRAP, not the other way. 08:33
laben: the metamodel defines how Perl 6 objects work underneath, while BOOTSTRAP makes Perl 6 objects as much as is necessary for the earliest stages of the compiler 08:34
laben ShimmerFairy: we dont need to call it in BOOTSTRAP, but in Metamodel
suppose we add a method to Routine which compares signatures
we just need to call it in RoleToClass composer to make that feature work 08:35
maybe it could stay in Signature, but alas, that's not the problem
it's that the code to compare compatibility and narrowedness (?) between signatures is splat inside analize_dispatch, find_best_dispatchee and !sort_dispatchees_internal (not sure of last name) 08:37
ShimmerFairy I think the biggest hurdle in comparison is that 'eqv' is too strict, and ~~ is too permissive:
m: sub foo($a, $b) { }; sub bar($c, $d) { }; say &foo.signature eqv &bar.signature; # too strict
camelia rakudo-moar f185e0: OUTPUT«False␤»
ShimmerFairy m: sub foo($a, $b) { }; sub bar($c, $d?) { }; say &foo.signature ~~ &bar.signature; # too permissive
camelia rakudo-moar f185e0: OUTPUT«True␤»
laben m: sub foo($a, $b) { }; sub bar($c, $d?, $e?) { }; say &foo.signature ~~ &bar.signature; 08:38
camelia rakudo-moar f185e0: OUTPUT«True␤»
laben can we even use smartmatch inside RoleToClass.nqp?
ShimmerFairy I don't think we need all the multi dispatcher code anyway; in this case we want exact signature matches, not the best, which is likely easier to go for :) 08:39
08:39 bjz joined
ShimmerFairy wow, I suspect ~~ isn't defined for Signatures at all. 08:40
laben m: sub rolesub(Int $a, Int $b) {}; sub classsub($a, $b) {}; say &rolesub.signature ~~ &bar.signature;
camelia rakudo-moar f185e0: OUTPUT«5===SORRY!5=== Error while compiling /tmp/HQ_4JLQ5rf␤Undeclared routine:␤ &bar used at line 1. Did you mean '&bag'?␤␤»
laben m: sub rolesub(Int $a, Int $b) {}; sub classsub($a, $b) {}; say &rolesub.signature ~~ &classsub.signature;
camelia rakudo-moar f185e0: OUTPUT«True␤»
08:41 darutoko joined
laben ShimmerFairy: i dont think we must go for exact, but for equal-narrow or narrower 08:41
ShimmerFairy oh, it is, it's just really, really permissive I think
laben ShimmerFairy: consider a role method with ($a, $b) and the role class with (Int $a, Int $b) 08:42
ShimmerFairy For stubbed methods at least, you want to be sure you're implementing the right thing. method foo(Int $a) { } might cover some cases of method foo(Num $a) { ... } , but not all of them
And in the inverse, the non-stubbed would be covering too much
laben but what if the class doing the implementation is not interested in the other Num-but-not-Int cases? 08:44
ShimmerFairy too bad, the point of an interface is to guarantee behavior. If an interface guarantees you can use Num arguments with something, the class doing the interface has to use them. 08:49
You can't implement half of a standard and still claim you're standards-compliant, after all :) 08:50
laben mh, ok, i guess it sound reasonable
TimToady m: sub foo($a, $b) { }; sub bar($c, $d?, $e?) { }; say &foo.signature ~~ &bar.signature && &bar.signature ~~ &foo.signature 08:51
camelia rakudo-moar f185e0: OUTPUT«False␤»
laben ~~ not commutative?
ShimmerFairy nope
laben how is it even done?
ShimmerFairy laben: LHS ~~ RHS is sugar for RHS.ACCEPTS(LHS)
(or more accurately { $_ = LHS; RHS.ACCEPTS($_) } ) 08:52
In the example I gave, the class could always check if the Num args can't be considered Ints, and die on that for whatever reason, but I don't think the language should let you get away with that without extra work :)
In my mind, roles should generally consist of "replaceable" (non-stubbed) and "required" (stubbed) methods. In either case, only providing the same signature would be sufficient to replace or implement the method, since exact signature is the closest you can get to the doing class/role promising the right behavior. 08:56
In a sense, you could probably think of non-stubbed role methods as stubbed roles with a default value, à la parameters with a default. I wonder if that's a sufficiently useful viewpoint. 08:58
08:58 cibs_ joined
laben that is with only methods. with multis, if a role has method(Num, Num), i should be able to define a class with method(Int,Int) and method(Num,Num) to cover the rest 08:59
09:00 espadrine joined
laben btw if i understand correctly, even if a role defines a only method, in a class i can always force it to be multi by defining a proto 09:00
ShimmerFairy laben: that's the nice thing about theoretical multi stubs, to me: it says "I need at least these, but you can of course do more" :) 09:01
09:02 cibs left
ShimmerFairy The only place I see the "exact signature" demand being impossible to meet off-hand would be 'where' constraints; I personally would be fine with trusting the overriding method to be using an equivalent where clause, instead of trying to analyze code :) 09:03
(and if an interface role wanted to ensure that those where constraints are exact, they should be using reusable subset types or equivalent anyway) 09:05
laben let's leave alone the forcing multi-ness stuff for now. we cant accept only strictly equal for multi methods as you could be leaving out intended behaviour from the class
let's say the role has method(Num, Num) and class has method(Int, Int), method(Num, Num) and method(Str, Str). iiuc, the Str one is to be rejected (possibly warning at compile time), but the Num and Int ones are to be accepted 09:08
ShimmerFairy if you're talking multi methods, then in my idea the (Num, Num) multi is required to satisfy the interface requirements, and the others are allowed as extra 09:09
laben: when I'm talking about stubbed methods and such, I'm talking about them as requirements, not restrictions :) 09:10
e.g. role R { method A { ... }; method B { ... }; method C { A() + B() } } needs A and B to be implemented so that C can do something useful. By no means does role R limit what methods a class can have, it only requires certain things upon saying you want to do the role. 09:14
laben m: role R { method m($a, $b) {*} }; class C does R { }; C.m(1,2) 09:17
camelia ( no output )
laben m: role R { method m($a, $b) {...} }; class C does R { }; C.m(1,2) 09:18
camelia rakudo-moar f185e0: OUTPUT«===SORRY!===␤Method 'm' must be implemented by C because it is required by a role␤»
laben ShimmerFairy: basically in my example, you would accept even the Str one, but error out if there was no Num one, right? 09:21
ShimmerFairy yes
In a world of only 'only' methods, you're allow to declare more 'only' methods past the ones the role requires by stubbing them 09:22
When you start considering 'multi' methods, I think it's logical that you're allowed to declare more multis on a name past the multis the role requires :)
09:23 pragma- joined
pragma- Why is CATCH uppercased? try { ... } CATCH { ... } 09:23
laben isnt CATCH a phaser instead of a keyword? 09:24
pragma- er, try { ... CATCH { ... } } # even more unothordox
arnsholt Yup. It's a phaser like BEGIN and END 09:25
pragma- I don't know if I can move from Perl5 to Perl6... it's all so weird and different and seemingly wonky at times.
ShimmerFairy pragma-: It's a phaser, whose names are traditionally uppercased. Phasers are blocks of code executed at specific times. The CATCH phaser, for example, executes when an exception occurs. 09:26
laben pragma-: let me tell you that i dont know if i can move from Python to Perl5... it's all so weird and different and seemingly wonky at times.
jnthn Note that, as a block trait, CATCH can go in any block, not just try. 09:27
yoleaux 16 Aug 2015 14:35Z <lizmat> jnthn: could you look at the sanity of github.com/rakudo/rakudo/commit/9c5d5da13f ? :-)
16 Aug 2015 15:15Z <lizmat> jnthn: would it be possible to stick in a flag in the opcode loop that would cause an immediate abort (with stacktrace) if set? then we could set that from e.g. signal(SIGINT).tap{...} and have a control-C cause a stacktrace on where it is stuck in a loop
16 Aug 2015 15:20Z <lizmat> jnthn: I notice you're using anonymous classes to build iterators. With SupplyOperations you chose to use named classes. Is there a particular reason for either, or is this a case of progressing insight?
ShimmerFairy pragma-: another particularly nice example of phasers is using the BEGIN phaser in calculating how long something takes: 09:28
brrt lizmat: that would be a huge, fascinating pain for the JIT
ShimmerFairy m: for ^1000 { $_ * $_ }; say now - BEGIN { now }
camelia rakudo-moar f185e0: OUTPUT«0.01463968␤»
brrt .tell lizmat an immediate abort flag would be a huge pain for JIT compilation 09:29
yoleaux brrt: I'll pass your message to lizmat.
JimmyZ I guess just ctrl+c and use MVM_dump_backstrace(tc) is OK ?
in GDB
I meant MVM_dump_backtrace(tc) 09:33
jnthn .tell lizmat Re 9c5d5da1, I'm not sure if that deserves an extra entry in the interator API or not; after all, you could just do push-all and pass an object that, when you call .push on it, increments a counter...
yoleaux jnthn: I'll pass your message to lizmat.
jnthn .tell lizmat It really hinges on if there are more use cases than Seq.elems really 09:37
yoleaux jnthn: I'll pass your message to lizmat.
09:37 dayangkun left
RabidGravy Hmm, if I'm over-riding add_method in some MOP shenanigans, I need to do similar to add_multi_method as well I guess 09:45
09:46 FROGGS_ joined 09:49 FROGGS left 09:54 brrt left 10:03 laouji left 10:04 nowan left 10:06 rindolf joined, lviatlantis joined 10:07 nowan joined, |Tux| left 10:09 lviatlantis left 10:12 laouji joined 10:13 |Tux| joined 10:33 TEttinger left 10:49 rurban left 10:50 RabidGravy left, inokenty joined 10:51 LonelyGM joined 10:52 laouji left, LonelyGM left, LonelyGM joined, LonelyGM left, LonelyGM joined 10:53 laouji joined 10:54 LonelyGM left 10:55 mls_ is now known as mls 10:57 rurban_ left 10:58 virtualsue joined 11:10 rurban_ joined 11:11 rurban joined 11:17 RabidGravy joined
lizmat computer, messages! 11:26
yoleaux 09:29Z <brrt> lizmat: an immediate abort flag would be a huge pain for JIT compilation
09:33Z <jnthn> lizmat: Re 9c5d5da1, I'm not sure if that deserves an extra entry in the interator API or not; after all, you could just do push-all and pass an object that, when you call .push on it, increments a counter...
09:37Z <jnthn> lizmat: It really hinges on if there are more use cases than Seq.elems really
lizmat brrt jnthn: what I want to achieve, is a way from a signal tap to have all threads abort with a stack trace
if there's another way to do that, then yes! :-) 11:27
tadzik :) 11:28
jnthn lizmat: You really need VM co-operation for such things. 11:30
And it's not quite trivial :)
But certainly do-able
lizmat yeah, I figured, hence my suggestion :-)
jnthn On Moar, signals are received by a dedicated event loop thread that is never tied up with code execution. 11:31
Provided there's a free thread pool thread, it can then have a signal handler run there 11:32
(And most hangs won't tie up the whole thread pool, and even if we have *that* issue we can create a 1-thread pool that is simply dedicated to this handler)
All that we can do already
So the only really interesting missing piece is a way to ask for stack traces for all running threads. 11:33
11:33 andreoss joined
lizmat :-) 11:34
confess(:all)
11:35 dayangkun joined
jnthn That'll take a little care to implement 'cus I can imagine a few different data races already if you do it the naive way :) 11:37
11:38 Ven joined 11:39 dayangkun left 11:40 awwaiid joined 11:46 inokenty left 11:53 Ven left 11:55 bioexpress joined
bioexpress Hi, could the unexpected behavior described in stackoverflow.com/questions/3195889...n-raw-mode be due to a bug in `getc`? 12:00
12:01 Ven joined
JimmyZ bioexpress: It'd be nice to file a bug to RT 12:04
12:06 bioexpress left 12:07 bioexpress joined 12:08 bioexpress left 12:11 domidumont left 12:12 domidumont joined
tadzik hmm, closing github issues has an icon that looks like I rejected the report 12:21
(github.com/tadzik/panda/issues/195)
very weird 12:22
DrForr It's marked as 'closed' in the interface which is all that really matters :)
12:22 abraxxa left 12:23 abraxxa joined 12:25 domidumont left 12:26 rurban left, laouji left
tadzik yeah, but I saw the red screaming icon and thought "oh, now it looks like it's not being fixed at all" 12:27
12:28 mr-foobar joined, domidumont joined 12:30 brrt joined 12:33 rurban joined
tadzik hoelzro: ping 12:34
hoelzro: remind me to talk to you about 26bc9022e470ac2d18396b3ce8e5e3dc45a23b5e :)
12:35 luiz_lha joined
brrt yeah, what jnthn said was basically my intuition too. quite a few runtime already provide this, btw 12:35
e.g go 12:36
java
[Coke] reminder, if you're going to the swiss perl workshop, put your name on this list: act.perl-workshop.ch/spw2015/wiki?n...nAttendees 12:39
DrForr Hrm, I'll be in Switzerland for a few hours :) 12:44
hoelzro tadzik: pong 12:45
also, good morning #perl6
DrForr Just before YAPC::EU? That would ordinarily be great timing for me...
12:48 smls joined
laben what will be the focus of this hackaton? glr, general bugfixing, ecosystem population effort? 12:50
12:51 andreoss left
tadzik hoelzro: so, I gave Panda a CONTRIBUTING.md in the meantime, but tl;dr: don't bother with backwards compat, just tag a previous panda release with a last rakudo release that doesn't have the required feature :) 12:51
12:51 zakharyas left, zakharyas joined
hoelzro tadzik: ah, thanks for the heads-up! 12:52
tadzik thanks for the patches! 12:53
I'm happy every time I look at my code only to realize that it's not just my code anymore :)
12:55 Ven left
jdv79 lizmat: did you do "japan's steepest funicular"? 12:56
12:57 llfourn left
[Coke] m: say so multi pass {} 12:59
camelia rakudo-moar f185e0: OUTPUT«True␤»
hoelzro =) 13:00
13:00 llfourn joined
nine laben: all of the above? ;) 13:00
laben nine: i take it glr will not be a branch for much longer, right? 13:03
[Coke] laben: I think there's a chance it will land in time for the august compiler release. I think it'll be in by september for sure. 13:07
laben cool, i will need to get up to speed to the behaviour changes quite fast, it seems :) 13:09
smls A 6.0beta in September (as planned by TimToady in January) is probably unrealistric then?
jnthn I'd like glr in the August release, but the August release doesn't have to be on the X thursday before the Y Tuesday of whatever the rule is. 13:10
smls To be fair, in January it was also planned that the GLR would be finished by April... :P
[Coke] jnthn: right, that's just historical reasons.
nine I'd like to see the glr merged in time for the hackathon, but that may be a bit optimistic :) 13:11
jnthn Well, it depends what our merge criteria are, doesn't it? :) 13:12
[Coke] we already know there will be downstream breakage, so I imagine that lightens our requirements slightly.
nine My module works, I dont see any obstacles to a merge ;)
laben nine: arent there something like 10 days? a bit too short of a time, unless our core devs can churn out miracles XD 13:13
13:13 rmgk_ joined, rmgk is now known as Guest82090, Guest82090 left, rmgk_ is now known as rmgk
jnthn nine: If we could add "panda works" to the list, that'd be fairly serious amunition to the "go for it" 13:13
[Coke] ... they are in the habit of doing so, yes.
jnthn Anyway, I'll probably look for ecosystem indicators over spectest indicators, because if Inline::Perl5 can run with 270 spectest files having breakage, well... :) 13:14
nine jnthn: well I wanted to have a look at the meta ops anyway, since that seems to be the first blocker for panda :)
jnthn nine: Yeah, they are the Next Big Thing really
nine jnthn: I think Inline::Perl5 works mostly because I just didn't know enough advanced Perl6 features when writing it ;) 13:15
tony-o lol
tadzik I can work on panda-glr later today probably
gotta run now though &
jnthn nine: That's probably why it performs OK too :P 13:16
_itz_ that "Method gimme not found..." error is that due to that method just not existing in rakudo-glr anymore or is there a deeper reason? 13:18
JimmyZ Not existing anymore 13:19
tony-o no deprecation warnings?
_itz_ so at some point that method gets added rather than the method being replaced by something else?
jnthn That method isn't coming back 13:22
It was never intended as public API anyway
So no deprecation note
jnthn bbl & 13:24
13:25 virtualsue_ joined
jdv79 so the last spectest breakages are the worst? 13:26
13:27 virtualsue_ left
tony-o so judgemental 13:28
13:30 virtualsue_ joined
nine jdv79: we already fixed all the hangs. I would consider those the worst ;) 13:31
jdv79 so /s/worst/hardest/ is more what i meant 13:32
nine Well I'm definitely not looking for easiest fixes when picking the next target. Don't know about the others 13:34
ShimmerFairy I think the order tends to go from most general to most specific functionality for these sorts of things :) 13:36
13:38 lizmat left, lizmat_ joined
nine Or just in order of failing spec tests 13:39
13:42 lizmat_ is now known as lizmat
RabidGravy anyone got any hints as to why the add_multi_method doesn't quite work as expected here: 13:44
m: gist.github.com/jonathanstowe/7bba...23b9caa5b9
camelia rakudo-moar f185e0: OUTPUT«adding bar with bar␤adding multi zub with zub␤adding multi zub with zub␤adding zub with zub␤bar!␤Method 'zub' not found for invocant of class 'Foo'␤ in block <unit> at /tmp/Y_adFKuyQk:32␤␤»
13:45 Ven joined
Ven .tell Sgeo wrt irclog.perlgeek.de/perl6/2015-08-17#i_11067252 - I like clojure's namespaced dynamics, what do you think? 13:46
yoleaux Ven: I'll pass your message to Sgeo.
dalek kudo/nom: 22c8517 | lizmat++ | t/01-sanity/55-use-trace.t:
Fix test now we don't have an extra NL anymore

Which I think FROGGS fixed recently		 13:48
laben interesting, you can even point camelia to a gist! 13:49
dalek kudo/nom: bbcda84 | lizmat++ | t/01-sanity/55-use-trace.t:
Make sure it also works on CRLF systems
laben RabidGravy: what is class Test that is inherited by Foo in your gist?
RabidGravy laben, it isn't it's a trait 13:50
laben RabidGravy: oops you're right, and it's even right there
RabidGravy this is part of the reason why I was asking about alternative trait words the other day because it is a little confusing :) 13:51
13:52 skids joined
_itz_ is there a GLR bot? 13:53
RabidGravy but the weird thing there is that it works for add_method but not add_multi_method
laben RabidGravy: did you check the proto auto generation or try to add it manually? 13:54
13:55 Ven left
RabidGravy if I add a proto method zub(|) { * } there it only installs one of the multis 13:57
13:58 pmurias joined
nine _itz_: we can have one as soon as someone tells me how to set it up 14:00
ShimmerFairy We just need someone with access to add a glr: target for camelia :) 14:03
nine I'd rather spen my time implementing glr than figuring out how to set up the bot
I do have access
_itz_ nine: that's probably a better use of time TBH
14:05 khw joined
_itz_ I could probably fire up a quick unofficial one 14:05
in fact I shall look now 14:06
ShimmerFairy nine: here's its code, with instructions in the README: github.com/perl6/evalbot
pyrimidine _itz_: was gonna say moritz set up the bot but ShimmerFairy beat me to it :) 14:07
ugexe zef works on glr. its glr branch almost works on both nom and glr, and by later today it should
_itz_ oh cool
pyrimidine was panda working w/ glr? only problem I had w/bioperl6 was File::Temp 14:08
tried testing using panda but it seemed broken as well
14:09 Ven joined
_itz_ I tried ufo but the for [\~] <1 2 3> {.say} construct is broken 14:09
ugexe does json::tiny work on glr yet? i figured that would be the big stopper there 14:11
masak m: .say for [\~] <1 2 3>
camelia rakudo-moar f185e0: OUTPUT«1␤12␤123␤»
masak _itz_: don't look borken to me
_itz_ I mean on GLR
masak oh
masak should backlog more :)
_itz_ > for [\~] <1 2 3> {.say}
Method 'gimme' not found for invocant of class 'Array'
I prolly wasn't clear :)
masak I just finished backlogging p6u. I think we should fix .perl before Christmas. 14:12
ShimmerFairy What's wrong with .perl? 14:13
14:13 brrt left
masak m: my $a = []; $a.push($a); say $a.perl 14:14
that's what's wrong with .perl
_itz_ it hangs on many structures
camelia rakudo-moar f185e0: OUTPUT«(timeout)»
masak we can't both say "yeah, so Data::Dumper is *built in*, whoa"
and have simple cycles fail.
now, it's trivial to detect and name cyclical references. I've written code like that in the past weeks. 14:15
the bigger challenge is to decide how the .perl output should look in such cases.
I don't recall ever hearing a good solution to that.
ShimmerFairy masak: well, in GLR circular structures are generally discouraged. (IIRC they hang when created, and aren't likely do otherwise) 14:16
masak it needs to be something that, when EVAL'd, yields something that's eqv to the original structure
ShimmerFairy: I don't know what that means, but that's either wrong on the face of it or it needs to change. 14:17
ShimmerFairy stuff like my @a = 1, @a; or @a = @a, @a , for example
masak in particular, this problem won't go away just because we say "GLR discourages that"
ShimmerFairy: that's different.
arnsholt masak: For a second I misparsed that as "That's what's wrong with Perl" =) 14:18
masak arnsholt: :P
arnsholt Kind of surprised to see you with that kind of negativity, yeah =) 14:19
ShimmerFairy masak: I don't think so, in all those cases you're trying to put the variable inside itself :) 14:20
masak arnsholt: it started in 2008. I wanted to /join #python, but I mistyped. haven't been able to /leave since. :P
arnsholt =D
masak ShimmerFairy: I am not good at arguing from the viewpoint of GLR, because I haven't internalized it yet. but in *this* universe, `@a = @a, @a` doesn't create any cycles. 14:21
14:21 GLRelia joined
masak ShimmerFairy: it just evaluates the contents of @a, twice, and stuffs the resulting list back into @a 14:21
tadzik mystyped, right. Just admit it, you saw "NO LOL" and ran away :P
masak m: my @a = 1, 2, 3; @a = @a, @a; say @a.perl
14:21 GLRelia left
camelia rakudo-moar f185e0: OUTPUT«[1, 2, 3, 1, 2, 3]<>␤» 14:21
masak ShimmerFairy: like that.
tadzik: NO PROJECT EULER 14:22
tadzik "hello #python, I have a project euler ta... oh, lol, nvm"
ShimmerFairy masak: all I know is that there was discussion of how @a = @a, @a is silly and of course it's gonna loop, and how TimToady mentioned that @a = 1, @a could possibly create an infinite list of 1s :P
masak man, it's like the #python channel removed my two major joys in life. a good laugh, and math problems.
laben ShimmerFairy: i think they referred to @a as a lazy (infinite in non-GLR) list 14:23
ShimmerFairy I've never been to #python, and now it sounds like I don't want to :P
masak ShimmerFairy: fair enough. even if that's the new semantics, it doesn't mean self-references *go away* post-GLR. if anything, it sounds like they'll be easier to create :P
arnsholt masak: No fun allowed! You must realize that programming is serious business! =p 14:24
masak ShimmerFairy: you'll be fine on #python, just as long as you don't laugh out loud, or mention 18th-century mathematicians.
ShimmerFairy masak: sure, but it's also easier to hang on them (rather than only at .perl) :P
masak arnsholt: there's only one way to do it, and it's joyless, goddammit!
ShimmerFairy: so let's get back to .perl? :) 14:25
ShimmerFairy masak: you should see the question on what the .perl of a Seq is :) (since a Seq goes through its values once and only once. IIUC the solution is for Seq to clone itself and burn through the clone in making the output string)
masak sounds fair to me. 14:26
laben fades away in the shadow while GLR takes over the world
smls ➜ ~ perl -e 'use Data::Dump; my @a; @a = (1, \@a); dd @a;'
do {
my $a = 1;
my $b = [$a, 'fix'];
$b->[1] = $b;
($a, $b); 14:27
}
^^ masak
though yeah, not exactly pretty.
masak "pretty" is bonus.
ShimmerFairy I really want to get to fixing the Pod parser in rakudo, I can't be the only one who finds confusing and messy to try and follow. I just discovered a fun bug where =item1 -> Pod::Item{:level("1")}<> , but =item -> Pod::Item . Welp.
masak I'd settle for "doesn't hang" and "reproduces the right data structure"
smls: anyway, smls++ for the constructive contribution. 14:28
I guess the next question is "what in that bit can't we do?"
ShimmerFairy: the Pos parser certainly needs some more love, yes.
jnthn
.oO( Piece of s... parser??? )
 14:29
masak Pod* 14:30
ShimmerFairy masak: after fixing Pod::To::HTML so that it did multi-level lists correctly (but didn't know the =item1/=item thing), I wanted to add ordered list support, but the Pod parser is tangled/compressed enough that making initial # lead to a :numbered config would be more interesting than it should be.
flussence that bit was written back in the day when rakudo took hours to build and minutes to start up... I can see why it wasn't fully completed :)
14:31 virtualsue_ left
smls ShimmerFairy: Since we have =table blocks for nice ASCII tables, why not =list blocks for nice ASCII lists (akin to markdown)? 14:32
ShimmerFairy Yeah, some time soon I want to just start a new branch and toss the existing Pod parser, in favor of something more comprehensible :)
masak might be a good idea to get the Pod parser to work correctly outside of Rakudo first, and then put it back into the big praser. 14:33
I tend to like to work that way (though admittedly with outside/inside core setting rather than the parser)
pmurias masak: re project euler I would assume that if I was working through project euler having people spoil problems on #perl6 would be pretty annoying
ShimmerFairy smls: I actually like that idea. Seems sensible for structures beyond paragraphs to have an abbreviated syntax thing
masak pmurias: yes, that might actually be the reason that ended up in the #python /topic 14:34
ShimmerFairy masak: at 90s of parsing per run of CORE, I'm definitely not going to start off in rakudo/src :P
dalek p/js: 7682c9f | (Pawel Murias)++ | src/vm/js/nqp-runtime/runtime.js:
When we don't know how to convert to ints/number call Int/Num
p/js: 53a034a | (Pawel Murias)++ | src/vm/js/QAST/Compiler.nqp:
Implement the cclass regex type
smls ShimmerFairy: Also, do you know if parsing formatting codes inside table cells is gonna be supported? I missed it several times while writing p6doc and other stuff.
masak pmurias: still, it feels like such a difference in attitude somehow.
14:34 mr-foobar left
masak smls: is it permitted by S26? 14:35
ShimmerFairy smls: I looked at that code once, wanting to support it, and the issue is that you'd have to do Perl6::Grammar.parse($para, :rule<the_right_rule>) for them, or re-implement the grammar.
masak: table cells are implicit C<=para>s, according to spec
pmurias masak: #perl6 seems to be a much smaller channel so we can get away with tolerating much more things 14:36
masak jnthn: re gist.github.com/jnthn/a56fd4a22e7c43080078 -- if you grep for `= whenever`, I think I would like that case to have to be written `= do whenever`.
14:36 mr-foobar joined
masak jnthn: in analogy with other loop constructs, like `for` and `given`. 14:36
ShimmerFairy The only sane way (I think) would be for the table parsing to happen in the parser (and not in Pod.nqp), but that would involve fun.
masak pmurias: yes, but why would tolerating "lol" be something that scales badly? 14:37
(note: I long ago made the observation that people who enter the channel and have a high "lol" density in their speech, generally don't stick around long. I don't know what to make of that, lol) 14:38
laben ShimmerFairy: if you have recently commited to Pod::To::HTML, could you check the failures in t/04-lists.t? it fails all 3 subtests
ShimmerFairy masak: it's a damn shame I purged all my old repos recently, resurrecting my old old old SUPERNOVA now won't look like a resurrection in the git history :<
laben: I noticed that, and it's the earlier issue I mentioned, the fact that =item doesn't set the :level adverb. For some reason. o_e 14:39
14:39 GLRelia joined
_itz_ m: say 2+2 14:40
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«4␤»
camelia rakudo-moar bbcda8: OUTPUT«4␤»
_itz_ m: for [\~] <1 2 3> {.say}
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«Method 'gimme' not found for invocant of class 'Array'␤ in block <unit> at /tmp/9YsYo9yvsL:1␤␤»
camelia rakudo-moar bbcda8: OUTPUT«1␤12␤123␤»
_itz_ OK GLRelia isn't currently updated via cron and is a stop gap
laben m: my @a = [1, 2]; @a.push: @a; @a.say; 14:41
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«1 2 1 2␤»
camelia rakudo-moar bbcda8: OUTPUT«1 2 1 2␤»
laben m: my @a = [1, 2]; @a.push: [3,4]; @a.say;
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«1 2 3 4␤»
camelia rakudo-moar bbcda8: OUTPUT«1 2 3 4␤»
RabidGravy _itz_++ # JFDI
masak _itz_++
now we have to rename the nom branch, "cam", though :P 14:42
laben m: my @a = [1, @a]; @a.say;
Woodi_ hi #perl6 :)
camelia rakudo-moar bbcda8: OUTPUT«1␤»
laben _itz_: sorry ;P
Woodi_ m: my @a = [0,0,0]; say "1Hi!" if so @a[0]; say "2Hi!" if so @a[1]; say "3Hi!" if so @a[2];
camelia rakudo-moar bbcda8: OUTPUT«1Hi!␤»
Woodi_ is it ok ?
ShimmerFairy masak: the other day jnthn mentioned the possibility that "glr" becomes "master", and "new object model" finally gets retired for the fact that the OM isn't so N :P
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«(timeout)»
( no output )
masak ShimmerFairy: ah. 14:43
ShimmerFairy masak: it was a joking suggestion, I don't think it'd happen (unless glr really does become such a big overhaul of the codebase, maybe) 14:44
masak ShimmerFairy: I'd hate to be the one to mention that that's what happened in the b -> ng/nom transition, and it hurt quite a lot.
it hurt quite a lot because the branches had essentially diverged, and nom, even though it was clearly superior, wasn't up to feature-parity with b.
dalek kudo/nom: af61bb2 | lizmat++ | src/Perl6/Actions.nqp:
Allow my constant $?FOO again

As per irclog.perlgeek.de/perl6/2015-08-17#i_11067616
14:45 sjn_phone_ joined, sjn_phone_ left
jnthn masak: Given we're "only" re-working lists in glr, I don't think that's so likely to be an issue 14:45
ShimmerFairy masak: yeah, I've had some flashback to back when nom was featureless (one of the repos I purged even mentioned "doesn't work on nom yet" in part of the README). Kinda surreal considering where nom is now :)
14:46 colomon left
lizmat alas, the above juste exposes the brokennes of this; 14:46
$ 6 'my constant $?FILE = "huh"; say $?FILE'
-e
jnthn lizmat: *sigh* yes, the correct answer is "OK, eventually we'd like that to work, for now we're better of NOT allowing declaring $?FILE to avoid the confusion"
lizmat but: do you want that for any $?FOO or just for the $?ONES that are in the core ? 14:47
masak maybe allow it, but parsefail with a NYI message?
jnthn I don't know that's worth the code complexity... 14:48
14:49 sjn_phone_ joined
jnthn I'd rather just say "no" for now and worry about it after 6.christmas. 14:49
masak oki 14:50
jnthn It's easy to make stuff work that was a parse/compile fail in the future
ShimmerFairy It would most directly affect $?TABSTOP, I think, since a couple things in Perl 6 use that, and you're supposed to be able to set it yourself.
jnthn Anything we're not usre about should resort to that.
tadzik nom: [&&] <a> >>~~<< <a b> 14:52
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«Lists on either side of non-dwimmy hyperop of infix:<~~> are not of the same length␤left: 1 elements, right: 2 elements␤ in block <unit> at /tmp/tmpfile:1␤␤»
camelia rakudo-moar bbcda8: OUTPUT«Lists on either side of non-dwimmy hyperop of infix:<~~> are not of the same length␤left: 1 elements, right: 2 elements␤ in block <unit> at /tmp/tmpfile:1␤␤»
lizmat $ 6 'my constant $?FILE = "huh"'
===SORRY!=== Error while compiling -e
Cannot use ? twigil on 'my' constant because we cannot make it work properly yet
at -e:1
tadzik ohh, GLRelia <3
lizmat ^^^ better ?
dalek kudo/nom: 82ea784 | lizmat++ | src/Perl6/Actions.nqp:
Do NOT allow my constant $?FOO again

As discussed at: irclog.perlgeek.de/perl6/2015-08-17#i_11069370		 14:53
jnthn lizmat: *sigh* for fucks sake
&
14:55 darutoko left
tadzik hah 14:56
masak "I think I speak for everyone here when I say, we just cannot make it work properly yet" :P 14:58
tadzik nom: [&&] ['5'] >>~~<< <5>
camelia ( no output )
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«Type check failed in binding; expected 'Positional' but got 'Seq'␤ in block <unit> at /tmp/tmpfile:1␤␤»
tadzik different, but breakage
this makes File::Find fail tests, is it intentional?
laben ShimmerFairy: about that role methods requirements, if the role implements the method, but the class has alredy defined one (with possibly a different signature), should we error out or what? 14:59
tadzik locally I get Lists on either side of non-dwimmy hyperop of infix:<~~> are not of the same length
14:59 darutoko joined
tadzik (because locally they are) 14:59
well, not
but one is [] and other is ()
masak m: [5] >>~~<< <5>
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«Type check failed in binding; expected 'Positional' but got 'Seq'␤ in block <unit> at /tmp/lZAWsAOfPO:1␤␤»
camelia ( no output )
masak slightly simpler.
tadzik Array and List
ShimmerFairy laben: role R { method M($a) { stuff } }; class C does R { method M($b, $c) { stuff } } ? yeah, that'd be like declaring two 'only' methods with the same name in the class body
tadzik which one is Seq? :f 15:00
m: <5>.WHAT
camelia ( no output )
GLRelia ( no output )
tadzik m: say <5>.WHAT
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«(Str)␤»
camelia rakudo-moar bbcda8: OUTPUT«(Str)␤»
nine masak: the GLR equivalent is: my @a = 1, 2, 3; @a = flat @a, @a; say @a.perl
tadzik nom: [&&] ['5', '6'] >>~~<< <5 6>
camelia ( no output )
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«Method 'gimme' not found for invocant of class 'Array'␤ in block <unit> at /tmp/tmpfile:1␤␤»
dalek kudo/nom: f58a726 | lizmat++ | src/Perl6/Actions.nqp:
Make 'my constant $?FOO' a NYI
 15:01
nine m: my @a = 1, 2, 3; @a = flat @a, @a; say @a.perl
camelia rakudo-moar bbcda8: OUTPUT«[1, 2, 3, 1, 2, 3]<>␤»
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«[1, 2, 3, 1, 2, 3]␤»
tadzik (╯°д°）╯︵ɹןb
ShimmerFairy tadzik: the issue is that nothing should be calling 'gimme', in that last one 15:02
tadzik it still spurts different errors from the ones I get locally :)
ShimmerFairy m: [5].list >>~~<< <5>
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«Type check failed in binding; expected 'Positional' but got 'Seq'␤ in block <unit> at /tmp/Cff6nT_0og:1␤␤»
camelia ( no output )
tadzik I only hope that they have a common root cause
ShimmerFairy m: [5].list >>~~<< <5>.list
camelia ( no output )
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«Method 'gimme' not found for invocant of class 'Array'␤ in block <unit> at /tmp/cjPK0N8fSI:1␤␤»
laben ShimmerFairy: so you mean, if the class already has the method, check if its sig matches or die out "Contract not respected"? 15:05
15:05 luiz_lha left
ShimmerFairy laben: no, because the role provides an implementation, the class doesn't have to provide anything for that method name. The role's methods will become part of the class' methods in composition, so if you have conflicting only methods, it's the usual conflict 15:06
laben m: role R{method m($a){...}};class C{method m($a,$b){}}; C.m(1,2) 15:07
camelia ( no output )
GLRelia ( no output )
15:07 diana_olhovik left
laben m: role R{method m($a){...}};class C{method m($a,$b){}}; C.m(1) 15:07
camelia rakudo-moar bbcda8: OUTPUT«Too few positionals passed; expected 3 arguments but got 2␤ in method m at /tmp/FKzMCksAk6:1␤ in block <unit> at /tmp/FKzMCksAk6:1␤␤»
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«Too few positionals passed; expected 3 arguments but got 2␤ in method m at /tmp/_6ZGoeU6ca:1␤ in block <unit> at /tmp/_6ZGoeU6ca:1␤␤»
ShimmerFairy m: class C { method foo($a) { }; method foo($b, $c) { } } # composing a role with a conflicting implemented method would do this
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«5===SORRY!5=== Error while compiling /tmp/ZrWnwxOT_n␤Package 'C' already has a method 'foo' (did you mean to declare a multi-method?)␤at /tmp/ZrWnwxOT_n:1␤»
camelia rakudo-moar bbcda8: OUTPUT«5===SORRY!5=== Error while compiling /tmp/4M7v7YDInk␤Package 'C' already has a method 'foo' (did you mean to declare a multi-method?)␤at /tmp/4M7v7YDInk:1␤»
laben m: role R{method m($a){say "ROLE"}};class C{method m($a,$b){say "CLASS"}}; C.m(1,2) 15:08
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«CLASS␤»
camelia rakudo-moar bbcda8: OUTPUT«CLASS␤»
laben m: role R{method m($a){say "ROLE"}};class C{method m($a,$b){say "CLASS"}}; C.m(1)
camelia rakudo-moar bbcda8: OUTPUT«Too few positionals passed; expected 3 arguments but got 2␤ in method m at /tmp/fox_hIjq3Z:1␤ in block <unit> at /tmp/fox_hIjq3Z:1␤␤»
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«Too few positionals passed; expected 3 arguments but got 2␤ in method m at /tmp/4zWBWApVVd:1␤ in block <unit> at /tmp/4zWBWApVVd:1␤␤»
15:08 bioexpress joined
laben ShimmerFairy: it does not conflict, it just gets skipped althogether while composing 15:08
ShimmerFairy laben: you forgot to 'does R' :) 15:09
15:09 bioexpress left
laben oops 15:09
m: role R{method m($a){...}};class C does R{method m($a,$b){}}; C.m(1)
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«Too few positionals passed; expected 3 arguments but got 2␤ in method m at /tmp/nspatc18YJ:1␤ in block <unit> at /tmp/nspatc18YJ:1␤␤»
camelia rakudo-moar bbcda8: OUTPUT«Too few positionals passed; expected 3 arguments but got 2␤ in method m at /tmp/d5XPfd_GdF:1␤ in block <unit> at /tmp/d5XPfd_GdF:1␤␤»
laben m: role R{method m($a){...}};class C does R{method m($a,$b){}}; C.m(1,2)
GLRelia ( no output )
camelia ( no output )
laben m: role R{method m($a){say "ROLE"}};class C does R{method m($a,$b){say "CLASS"}}; C.m(1)
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«Too few positionals passed; expected 3 arguments but got 2␤ in method m at /tmp/RzWgXIXo0v:1␤ in block <unit> at /tmp/RzWgXIXo0v:1␤␤»
camelia rakudo-moar bbcda8: OUTPUT«Too few positionals passed; expected 3 arguments but got 2␤ in method m at /tmp/jBoryEh_X7:1␤ in block <unit> at /tmp/jBoryEh_X7:1␤␤»
laben m: role R{method m($a){say "ROLE"}};class C does R{method m($a,$b){say "CLASS"}}; C.m(1,2) 15:10
camelia rakudo-moar bbcda8: OUTPUT«CLASS␤»
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«CLASS␤»
ShimmerFairy And that's where I say the current implementation is lacking. The RoleToClassApplier currently only considers method name, not signatures, when considering overriding a role method.
laben correct result would be to error out "required signature not matching" in both cases, iiuc? 15:12
15:13 brrt joined
ShimmerFairy laben: no, in that case it would be a simple method name conflict, like so: 15:13
m: class C { method foo($a) { }; method foo($b, $c) { } }
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«5===SORRY!5=== Error while compiling /tmp/g_R7unvJGR␤Package 'C' already has a method 'foo' (did you mean to declare a multi-method?)␤at /tmp/g_R7unvJGR:1␤»
camelia rakudo-moar bbcda8: OUTPUT«5===SORRY!5=== Error while compiling /tmp/700Nyg6PYM␤Package 'C' already has a method 'foo' (did you mean to declare a multi-method?)␤at /tmp/700Nyg6PYM:1␤»
laben but doesnt that happen at parse time instead of at compose time? 15:14
i mean, while defining the class? 15:15
ShimmerFairy Well, the error wouldn't have to be the exact same one, but the issue in this case is more one of trying to define the same name twice with different signatures when they aren't "multi"s :) 15:16
15:17 Ven left
laben turns out i'm wrong and that error happens inside add_method, which is totally our territory during composition 15:18
[Coke] drowns in bot output. 15:19
laben it would be enough to call add_method anyway and let that error out when it find a conflict, but this way wouldnt tell the class writer he overwrote the role method, mh 15:20
15:22 Ven joined
ShimmerFairy laben: this is certainly an interesting topic. I think it'd help if I wrote out a gist demonstrating my thoughts on the matter tomorrow :) 15:22
15:24 Ven left 15:26 leont joined
RabidGravy speaking of which I have concluded that wrapping all the methods in a class is better done in compose when all the multis have been resolved 15:27
15:28 brrt left
laben RabidGravy: multis dont get resolved, just added to dispatch list so that MMD can then decide later on 15:29
RabidGravy well that's what I meant really 15:30
for my purposes is it's only necessary to wrap the proto so it's easiest to do it after the real compose 15:32
dalek kudo/nom: 5ca1bcc | ShimmerFairy++ | src/Perl6/Pod.nqp:
Make sure =item blocks act like =item1

This means attaching the info that it's at level 1 to the Pod::Item object.
RabidGravy and the side benefit of doing it at that point is that the methods from roles get wrapped :) 15:35
dalek ast: b4780f5 | ShimmerFairy++ | S26-documentation/06-lists.t:
Fix pod test that was backwards.
15:37 FROGGS_ is now known as FROGGS
FROGGS o/ 15:37
RabidGravy Boom!
15:37 zakharyas left
lizmat FROGGS o/ 15:38
hoelzro o/ FROGGS 15:41
ShimmerFairy++ # POD work
15:41 Ven joined 15:42 rindolf left
ShimmerFairy I'll try to start working on a replacement parser tomorrow, it's about time :) And in the process I'll get to surprisingly resurrect the old SUPERNOVA name :3 15:42
15:43 telex left 15:44 telex joined
hoelzro ShimmerFairy: you're writing a new POD parser? 15:45
ShimmerFairy hoelzro: I will, because the one currently in rakudo is not good. I find it incredibly and needlessly difficult to comprehend. It looks like someone tried to compress the parsing as cleverly as possible, as opposed to something more readable. 15:46
15:46 sjn_phone_ left
smls ShimmerFairy: For parsing tables, would it help to implement that rule in Perl 6 (rather than the regex lang)? 15:46
gobble a complete table block, split it, call the normal para rule for each cell. 15:47
ShimmerFairy And I'll be writing it outside of CORE at first, so I don't have to wait 90s for each change I want to test :)
smls (provided Perl 6 rules are properly supported by now.)
Ven m: say q|a|
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«a␤»
camelia rakudo-moar f58a72: OUTPUT«a␤»
15:47 sjn_phone_ joined
hoelzro ShimmerFairy++ 15:48
geekosaur keeps trying to read GLRelia as GHRelin >.>
ShimmerFairy smls: The problem (as I see it) is that it _doesn't_ use the regex lang to parse the table, and pawns it off on a Pod.nqp method. I don't know if you can access the grammar at that point, or how much of a headache it would be if you had to invoke a second copy with .parse
smls isn't the idea of "rules as methods" that you can mix regex and Perl 6 methods that call each other within a single .parse? 15:49
Ven I have a case where `@foo.map(&git-list);` isn't the same as `for @foo { git-list($_) }`. (literally "@foo"). any idea what might be going on? 15:50
ShimmerFairy smls: Yeah, I'd be surprised if it had to be another .parse, but I'm not familiar with the interaction (and besides, calling back into the grammar from the actions side feels like you're doing something wrong to me)
Ven the code is here: github.com/vendethiel/deepgitstatu...status#L25 I just moved the `$dir.dir.grep(Dir)` to `@foo` in my local code 15:51
smls ShimmerFairy: No, I don't mean an action method. I mean a Perl 6 method inside the grammar.
15:52 sjn_phone_ left
hoelzro ShimmerFairy: are you talking about the POD parsing that happens in Perl6::Grammar? 15:52
ShimmerFairy hoelzro: yes, that one (not aware of any other place) :)
smls: Of course, several of Perl6::Grammar's rules are actually called 'method's specifically because they do more code-like things than regex-like things :) 15:53
15:53 rurban_ left, sjn_phone_ joined
ShimmerFairy And, as a personal matter, I prefer leaving the parsing to the Grammar when at all feasible, so I don't like that the table parsing happens over in Pod.nqp 15:53
15:54 domidumont left
hoelzro ShimmerFairy: let me know if you would like some help with that; I dug into that stuff this time last year for the S26 stuff 15:54
there are some nasty hacks that I myself added =/
ShimmerFairy (As an example of this, look at the $<ohradix> capture I added to the Grammar a couple days ago. That was me moving some action-side string munching to the grammar ☺)
15:54 Loren joined
ShimmerFairy hoelzro: Thanks. I'll be starting off on a clean slate away from the rakudo code, so I'll probably run into issues when it comes time to moving the code into rakudo 15:55
15:55 abraxxa left
hoelzro sounds good =) 15:56
laben Ven: sorry i cant get deep into your code, but afaik .dir doesnt guarantee much order-ness
ShimmerFairy hoelzro: And don't worry, that fix I added to rakudo just now kinda felt like a quick hack to me, specifically because I plan on replacing it sometime soon :P
hoelzro please post updates on your branch as you're working; I'm very intrigued
ShimmerFairy hoelzro: well, it'll be separate repo, that's how removed from CORE it'll be at the start (though I'll try to remember to use := everywhere :P) 15:57
15:57 sjn_phone_ left, MilkmanDan joined
ShimmerFairy I'll make sure the stuff that has to change between in-rakudo and out-of-rakudo will be easy to substitute :) 15:58
smls m: say (grammar { token TOP { <a> }; method a { self.ident } }).parse("aaa");
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«｢aaa｣␤ a => ｢aaa｣␤»
camelia rakudo-moar 5ca1bc: OUTPUT«｢aaa｣␤ a => ｢aaa｣␤»
smls \o/
"methods in grammars" works even without NQP, it seems
ShimmerFairy smls: NQP's grammars are one of the few areas that are less "not quite" and more "exactly" :) 15:59
smls I see. 16:00
ShimmerFairy (so grammars are fortunately easily transferable between nqp and p6. Actions, however...)
Ven laben: it has no impact on my code.
ShimmerFairy smls: and it's specifically because NQP's regexes have to be good enough to parse Perl 6, so wouldn't you know it has to be just like it's specified in Perl 6? :P
16:01 MadcapJake joined
RabidGravy speaking of which where do the $~MAIN and so forth get defined? 16:02
ShimmerFairy RabidGravy: as of now? Nowhere, really. 16:03
m: say $~MAIN
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«Slang.new(:grammar(Perl6::Grammar), :actions(Perl6::Actions))␤»
camelia rakudo-moar 5ca1bc: OUTPUT«Slang.new(:grammar(Perl6::Grammar), :actions(Perl6::Actions))␤»
ShimmerFairy welp, guess I haven't been keeping up to speed with slangs :P
RabidGravy yeah, where does that happen
Ven deep in the compiler, probably? 16:04
16:04 grondilu joined
ShimmerFairy RabidGravy: seems to be generated on-the-fly in make_variable_from_parts in Actions.nqp 16:05
smls: I'll definitely keep =list in mind. I was toying with that name being used to group =items (like <ul></ul> and so on), but I do like the idea of specifying "ASCII" lists with them. 16:07
dalek kudo/glr: ff60b61 | (Stefan Seifert)++ | src/core/metaops.pm:
GLRify METAOP_REDUCE_LEFT(\op, \triangle)

Fixes Shell::Command		 16:09
16:10 Loren left
hoelzro ShimmerFairy: just make sure to post a link to the repo if you want so some of us can follow along =) 16:12
ShimmerFairy hoelzro: but of course :)
nine 269/1047 test files failing 16:13
ShimmerFairy (though I have a habit of working on a repo for at least a little bit before going public; I won't push to github as soon as I add a README :P)
hoelzro fair enough 16:14
ShimmerFairy good ♘, #perl6 o/
16:14 brrt joined
lizmat good night, ShimmerFairy 16:14
16:14 rindolf joined
lizmat calls it a night as well 16:14
hoelzro o/ you two
JimmyZ too :) 16:15
16:39 yqt joined 16:46 inokenty joined
dalek rl6-most-wanted: c4d4050 | (Steve Mynott)++ | most-wanted/modules.md:
AE256 handled in openssl, adding other cyphers fairly easy
 16:50
kudo/glr: 0868b9f | (Stefan Seifert)++ | src/core/metaops.pm:
GLRify METAOP_ZIP

We can now use iterators instead of copying the input lists.		 16:54
nine 267/1047 test files failing
Ven nine++ 16:57
skids Ooh, how's panda fairing after that I wonder. 16:59
nine m: for [\~] <1 2 3> {.say}
GLRelia rakudo-moar GLR 20150817ish: OUTPUT«Method 'gimme' not found for invocant of class 'Array'␤ in block <unit> at /tmp/FYmZHpfFpY:1␤␤»
camelia rakudo-moar 5ca1bc: OUTPUT«1␤12␤123␤»
nine _itz_: GLRelia is hopelessly out of date :) 17:00
skids: panda is two fails further. Now crashing due to @params is rw being a List and thus immutable. 17:01
_itz_ hmmm maybe I should try and add a cron
17:03 Loren joined
geekosaur every 5 minutes? :) 17:04
_itz_ I'm not sure that would keep up with nine :) 17:06
smls just do a loop; once compilation is finished, compile again... :P
17:08 ilogger2 joined, ChanServ sets mode: +v ilogger2
smls btw, I wonder if the zip version of gist.github.com/smls/a1f6033c142202bddc4d will run at reasonable performance post-GLR. 17:08
nine smls: only benchmarks can tell 17:09
smls: it should already be a bit faster, I'd guess
smls pre-GLR: 810 sec for the naive zip-based version, 19 sec with a 'loop' using native int counter...
;)
nine Oh it's now super fast........at printing Range iterator NYI 17:10
smls heh 17:11
Ven [@a, @b][0].push: 1 will DWIM later, right? (admittedly, that's a pretty weird way to write that...) 17:13
nine m: my @a; my @b; [@a, @b][0].push: 1; say @a.perl; say @b.perl; 17:14
camelia rakudo-moar 5ca1bc: OUTPUT«[]<>␤[]<>␤»
GLRelia rakudo-moar 0868b9: OUTPUT«[1]␤[]␤»
nine I'd say yes :)
smls m: my @a = 1, 3; my @b = 2, 4; (@a, @b)[0].push: 5; dd @a
GLRelia rakudo-moar 0868b9: OUTPUT«@a = [1, 3, 5]␤»
camelia rakudo-moar 5ca1bc: OUTPUT«@a = [1, 3, 5]<>␤»
smls ^^ works with Parcel already, pre-GLR 17:15
nine Parcel? Parcel! Who the fuck is Parcel?!
smls :P 17:16
Ven smls: I didn't even think about that, haha. Thanks :).
smls though *technically* that's not pre-GLR, since making postcircumfix on parcels non-flattening, was one of the early changes made a few months ago in preparation for the GLR I believe. 17:17
anyway, yes, let's forget about Parcel now...
17:38 __blackcat joined 17:40 lizmat joined 17:42 domidumont joined
nine Ah rakudo guts, where clear names make documentation unnecessary. Like "p6bindattrinvres" 17:43
A sentence that will extend the Google results for this word by 16 %. 17:44
DrForr n/ick qrstuvwxyz 17:49
skids Though the "Parcel" name was very nicely punny. 17:51
jnthn nine: bind the attribute, give me the invocant as the result (instead of the bound value as is the default) :) 17:54
nine jnthn: oh thanks!
jnthn It's right there in the name! ;)
nine And now that's documented in Google :)
m: my @a; @a[0] := 1; 17:55
camelia ( no output )
GLRelia rakudo-moar 0868b9: OUTPUT«This type does not support positional operations␤ in block <unit> at /tmp/OxJChAPymI:1␤␤»
nine jnthn: ^^^ that's what I currently try to fix
jnthn nine: I'll bet BIND-POS doesn't called that self!ensure-allocated thingy
*call
17:56 spider-mario joined
nine Ah, stupid me. I could have thought of that. 17:57
ugexe is there an obvious way to do the following that would result in the same structure for nom and glr?
m: my @r = eager gather for 1,2,3,4 { my %x; %x{$_} = $_; take %x }; say @r.perl
camelia rakudo-moar 5ca1bc: OUTPUT«["1" => 1, "2" => 2, "3" => 3, "4" => 4]<>␤»
GLRelia rakudo-moar 0868b9: OUTPUT«[${"1" => 1}, ${"2" => 2}, ${"3" => 3}, ${"4" => 4}]␤»
17:57 n0tjack joined 17:58 n0tjack left
dalek kudo/glr: 15719e0 | (Stefan Seifert)++ | src/core/Array.pm:
Fix binding slots of not yet allocated arrays.

Fixes my @a; @a[0] := 1; Thanks to jnthn++ for reminding me of the obvious!		 17:58
ugexe i want the glr version, just trying to shim something as to not maintain 2 forks
jnthn Apparently last week's intense GLR hacking combined with afk issues has exhausted me. :/
jnthn will be flying to Japan tomorrow 17:59
Hopefully I'll rest well after the flight, and be back in decent shape again... 18:00
nine 263/1047 test files failing
[Coke] jnthn: conserve health!
18:00 rurban_ joined
jnthn Anyway, apologies for how testy I've been here the last few days. It's my extreme tiredness/stress failure mode. :( 18:00
[Coke]: Yes, am trying :) 18:01
skids honestly hadn't noticed any testiness. 18:02
18:03 __blackcat left
nine m: my @a = 1, 2, 3; my @b = @a X=> "foo"; say @b.perl; 18:04
camelia rakudo-moar 5ca1bc: OUTPUT«[1 => "foo", 2 => "foo", 3 => "foo"]<>␤»
GLRelia rakudo-moar 0868b9: OUTPUT«Method 'gimme' not found for invocant of class 'Seq'␤ in block <unit> at /tmp/0f_2VYpJaL:1␤␤»
nine m: my @a = 1, 2, 3; my @b = flat @a X=> "foo"; say @b.perl; 18:05
camelia rakudo-moar 5ca1bc: OUTPUT«[1 => "foo", 2 => "foo", 3 => "foo"]<>␤»
GLRelia rakudo-moar 0868b9: OUTPUT«Method 'gimme' not found for invocant of class 'Seq'␤ in block <unit> at /tmp/J2YOqJwSoS:1␤␤»
nine _itz_: already out of date again :)
jnthn I suspect X meta-op will need a going through
nine jnthn: already done ;)
jnthn Oh :)
nine++
Did you re-work it in terms of iterators, ooc?
nine jnthn: but flat @a X=> 'foo' gives me a "This Seq has already been iterated, and its values consumed" now
jnthn: yes
jnthn: though I guess the comment is no longer true: "my \elem = lol[$i]; # can't use mapping here, mustn't flatten" 18:06
jnthn: so there may be more possibility for optimization
jnthn Indeed, now we can do it
Right
The stack trace of the second attempt to consume is often telling enough 18:07
If not then you could always do some hack in method iterator in Seq that makes a Backtrace and stashes it away, then can report it the second time 18:08
jnthn hopes that made some sense :)
skids Failure should stash backtraces now.
jnthn Maybe I should write a Seq::UsageDebugger module at some point to help hunt such things :) 18:10
nine It's in Iterator.flat called by pull-one of the Iterator returned by Iterator.flat() 18:11
18:14 colomon joined
nine s/Iterator/Iterable/g 18:14
jnthn 'fraid I don't have any immediate guesses 18:18
18:19 bin_005 joined, zakharyas joined
nine Well I guess that just happens when you fix code where you only really understand half of it ;) 18:19
I'm already very proud that when I started fixing METAOP_REDUCE_LEFT(\op, \triangle), I wrote code that's very similar to yours, before I discovered, that you already did METAOP_REDUCE_LEFT(\op) and I could use that as a template :) 18:22
jnthn :) 18:24
I'm happy the iterator design is such that it led both of us to a similar solution :)
time for noms & 18:25
nine Yes, it's really straight forward to use
18:26 sjn_phone_ joined 18:38 lizmat left 18:49 sjn_phone_ left 18:52 diana_olhovik joined
nine jnthn: I should just have gone ahead and refactored the lol loop as well. It's the (elem,).flat.item thingy that returns a Seq. And that Seq gets iterated over too often. 18:55
m: <1 2>.flat.item.perl.say; 18:56
GLRelia rakudo-moar 15719e: OUTPUT«Seq.new␤»
camelia rakudo-moar 5ca1bc: OUTPUT«$("1", "2")␤»
18:56 yqt joined
jnthn nine: The .item is extremely superstitious now too 18:58
nine: I think that can just be (elem,) :)
18:59 zakharyas left
nine m: my \elem = <1 2>; (elem,).flat.list.item.perl.say; (elem,).perl.say; 18:59
GLRelia rakudo-moar 15719e: OUTPUT«$("1", "2")␤(("1", "2"))␤»
camelia rakudo-moar 5ca1bc: OUTPUT«$("1", "2")␤(("1", "2"),)␤»
jnthn And yeah, folks expecting .flat to return a list also will be "interesting" :)
nine I don't even know what this code is supposed to do: if nqp::iscont(elem) { (elem,).list.item } else { (elem,).flat.list.item } 19:00
19:00 lizmat joined
jnthn "If it's a Scalar, always treat it as a 1-item list, otherwise treat it as a flattened list 19:02
"
Didn't I refactor that bit in the one you're using as a "template" too? :) 19:03
nine Oh yes, that's the Iterable type check now
jnthn Right :)
nine Ok, I can work with that :)
And again highly obscur code gets replaced by very straight forward one. I like that :) 19:05
FROGGS nice, I implemented an exception that is raised when the initializer of a variable declaration contains said variable, and I find bugs in the setting :o) 19:08
smls FROGGS: I thought that was allowed? 19:09
FROGGS m: sub foo { my %ENV := $%ENV; }; foo
GLRelia rakudo-moar 15719e: OUTPUT«Cannot call method 'item' on a null object␤ in sub foo at /tmp/aB9okfvRRE:1␤ in block <unit> at /tmp/aB9okfvRRE:1␤␤»
camelia rakudo-moar 5ca1bc: OUTPUT«Cannot call method 'item' on a null object␤ in sub foo at /tmp/Fgum6bhO5P:1␤ in block <unit> at /tmp/Fgum6bhO5P:1␤␤»
FROGGS $ perl6-m -e 'm: sub foo { my %ENV := $%ENV; }; foo' 19:10
===SORRY!=== Error while compiling -e
Cannot use variable %ENV to initialize itself
smls: if it survives a spectest I'll push and you can try to break it :o) 19:11
dalek kudo/nom: 45644ed | FROGGS++ | src/core/IO/Spec/ (2 files):
fix indentation
 19:13
kudo/nom: ccfb5fb | FROGGS++ | src/core/IO/Spec/Cygwin.pm:
fix typo about %*ENV in IO::Spec::Cygwin.tmpdir
 19:14
skids dammit why do I keep typing "Interable"
FROGGS that's.... iteresting 19:16
skids m: Iterable but 1; 19:18
camelia ( no output )
GLRelia rakudo-moar 15719e: OUTPUT«Method 'iterator' must be implemented by Iterable because it is required by a role␤ in any compose_method_table at src/gen/m-Metamodel.nqp:2664␤ in any apply at src/gen/m-Metamodel.nqp:2674␤ in any compose at src/gen/m-Metamodel.nqp:2810␤ in an…»
skids Oh, right. It's a role. 19:19
timotimo on a very long drive and having a bad headache... no weekly from me tonight 19:20
FROGGS timotimo: :o/
19:21 brrt joined 19:23 domidumont left 19:25 llfourn joined 19:30 llfourn left
dalek kudo/glr: 19fad47 | (Stefan Seifert)++ | src/core/List.pm:
Fix some forms of infix:<X>

We can now check for Iterable to differentiate between listy things and scalars. the gather {}.list is necessary to avoid iterating over the same Seq multiple times, e.g. when actually trying to assign the result of X to an @array.		 19:31
kudo/glr: 5543e5f | (Stefan Seifert)++ | src/core/metaops.pm:
GLRify METAOP_CROSS
 19:32
kudo/glr: 117b998 | (Stefan Seifert)++ | src/core/List.pm:
Fix infix:<X> for 3 dimensions
 19:36
nine I fear the gather {}.list fix is responsible for 1..* X* 1..* hanging :/ 19:39
FROGGS there might be more than one way to fix things 19:40
nine At times like this I wish I actually new what I was doing :/ I don't even have an idea what 1..* X* 1..* is supposed to mean. 19:43
_itz_ m: my @a; @a[0] := 1; 19:44
GLRelia ( no output )
camelia ( no output )
colomon nine: it’s just a silly complicated way of writing 1…*, isn’t it?
[Coke] m: my @a = 1..* X* 1..*; say @a[0..4]; 19:45
GLRelia rakudo-moar 117b99: OUTPUT«1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 8…»
camelia rakudo-moar 5ca1bc: OUTPUT«(timeout)»
nine Wait, WHAT?
colomon like I said…. ;)
FROGGS nine: it cross-multiplies two infinite lists
nine Why is GLRelia giving uns the result while nom is hanging?! 19:46
[Coke] m: constant @a := 1..* X* 1..*; say @a[4];
GLRelia rakudo-moar 117b99: OUTPUT«Nil␤»
camelia rakudo-moar 5ca1bc: OUTPUT«5␤»
skids gist.github.com/skids/ccb89f60bb57b95e0e01 # Now I feel like I need a shower
[Coke] the bind probably helps there.
colomon is one of those rakudo-moar’s a GLR build? 19:47
19:47 xinming joined
FROGGS colomon: GLRelia, aye 19:47
geekosaur GLRelia's hash matches the most recent glr commit
skids itz's iz
colomon how do you tell which output it is?
FROGGS colomon: look at the botname 19:48
colomon oh!
FROGGS :o)
colomon is not observant
leont is surprised by that output too
FROGGS m: constant @a := (1..* X* 1..*).flat; say @a[4];
GLRelia rakudo-moar 117b99: OUTPUT«5␤»
camelia rakudo-moar 5ca1bc: OUTPUT«5␤»
jnthn skids: It's nice for debugging, but too costly really to have as the default.
skids Oh yeah, I know. 19:49
FROGGS that was needed since a few months
jnthn skids: But nice :)
skids I just had to see if it would work at all.
19:52 yqt left
nine m: my @a = 1..* X* 1..*; say @a[0..4]; 19:53
GLRelia rakudo-moar 117b99: OUTPUT«1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 8…»
FROGGS nine: the first dimension already is infinite
nine Isn't this output actually wrong?
camelia rakudo-moar ccfb5f: OUTPUT«(timeout)»
FROGGS no, it is correct
[Coke] m: constant @a := 1..* X* 1..*; say @a[0][4]; 19:54
GLRelia rakudo-moar 117b99: OUTPUT«5␤»
camelia rakudo-moar ccfb5f: OUTPUT«Index out of range. Is: 4, should be in 0..0␤ in block <unit> at /tmp/Wbi_RRvpMJ:1␤␤Actually thrown at:␤ in block <unit> at /tmp/Wbi_RRvpMJ:1␤␤»
nine Shouldn't it return something like 1 1 2 2? 19:55
Oh, no, that would be 1..* X 1..*
dalek kudo/nom: 3754356 | FROGGS++ | src/ (2 files):
forbid to put variable in initializer of its declaration

This fixes RT #125371. Variables in initializers in subsequent blocks are allowed though.		 19:57
synbot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=125371
FROGGS smls: ^^
19:58 lsm-desktop joined
nine (1..* X* 1..*)[0..4] should give 1 4 9 16 25 if you ask me 19:58
m: (1..10 X* 1..10)[0..4].perl
GLRelia ( no output )
camelia ( no output )
nine m: (1..10 X* 1..10)[0..4].perl.say
GLRelia rakudo-moar 117b99: OUTPUT«(1, 2, 3, 4, 5)␤»
camelia rakudo-moar ccfb5f: OUTPUT«(1, 2, 3, 4, 5)␤»
colomon nine: that’s Z* you’re thinking of 19:59
[Coke] FROGGS: didn't timtoady just say he wanted my @a = 1, @a to work?
colomon but I don’t see why [0..4] is apparently infinite instead of 5 long?
m
[Coke] colomon: because the first thing is an infinite list.
colomon you mean [0] is an infinite list? 20:00
FROGGS [Coke]: would is the reason to allow that?
[Coke] (and then the second thing would also be an infinite list..)
FROGGS [Coke]: my @a = 1, @a is probably like my @a = 1, ()
[Coke] The desire was that it be more like 1, 1, 1, ... IIRC.
FROGGS or... no, perhaps like my @a = 1
[Coke] doesn't work yet, but was proposed by TimToady - hard to search for in the logs. 20:01
nine So this test can actually never work: is (1..* X* 1..*)[^3], (1, 2, 3), 'cross handles lazy lists';
Am I right?
[Coke] nine: well, before, you probably got a flat list.
FROGGS [Coke]: I'll go ahead and drop him a note... would just be two commits to revert
[Coke] post glr, looks like you get N lists...
smls FROGGS: Self-reference can make sense in cases like my %a = foo => 42, bar => sub { say %a<foo> } 20:02
FROGGS smls: that will continue to work, as the commit comment states
nine [Coke]: if I get N lists, that's my fault, since I'm the one who tries implement METAOP_CROSS in glr 20:03
[Coke] nine: I have no idea what the right answer is there. :)
smls ah, that's what you mean by 'subsequent blocks'
FROGGS aye
nine [Coke]: neither have I *g* That's what makes implementing this so hard ;)
skids Well if the answer is that it should be flat, just returning N Slips should work, right? 20:04
colomon m: my @a = 1..* X* 1..*; say @a[0][0..4];
GLRelia rakudo-moar 117b99: OUTPUT«1 2 3 4 5␤»
camelia rakudo-moar ccfb5f: OUTPUT«(timeout)» 20:05
AlexDaniel GLRelia :))) 20:08
FROGGS GameLiaRrrr! 20:09
smls FROGGS: The popular my Type $x .= new; idiom still works though, right? 20:13
FROGGS smls: yes, since the exception is about the $x 20:14
so you cannot use the name when it is not yet initialized... at least that's the idea 20:15
smls So you couldn't write it as my Type $x = $x.new; anymore, right? (Not that I think anyone did that.) 20:16
dalek ast: cddf3a2 | FROGGS++ | S (4 files):
RT #125371, catch variable use in its own initializer
 20:17
synbot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=125371
smls Though it makes it a little harder to explain why .= new works. 20:18
FROGGS smls: you are right in all charges
TimToady: I changed the handling of "my $a = $a", if you don't like it revert rakudo/3754356d8e and roast/cddf3a26a4 20:21
m: my Int $x = $x.new; # smls 20:22
GLRelia ( no output )
camelia rakudo-moar 375435: OUTPUT«5===SORRY!5=== Error while compiling /tmp/J0MRojclBk␤Cannot use variable $x in declaration to initialize itself␤at /tmp/J0MRojclBk:1␤------> 3my Int $x = $7⏏5x.new; # smls␤ expecting any of:␤ term␤»
FROGGS m: my Int $x .= new;
GLRelia ( no output )
camelia ( no output )
20:22 smls joined
FROGGS m: my Buf $x = $x.new(42); say $x 20:23
GLRelia rakudo-moar 117b99: OUTPUT«Buf:0x<2a>␤»
camelia rakudo-moar 375435: OUTPUT«5===SORRY!5=== Error while compiling /tmp/nS7dwXX72V␤Cannot use variable $x in declaration to initialize itself␤at /tmp/nS7dwXX72V:1␤------> 3my Buf $x = $7⏏5x.new(42); say $x␤ expecting any of:␤ term␤»
20:24 [Sno] joined
Ulti `gotty -w perl6 --setting=RESTRICTED` using github.com/yudai/gotty is fun 20:25
FROGGS we could potentially tweak it so methods calls would turn off that exception, but I like simple rules
20:25 rurban_ left 20:26 llfourn joined 20:27 cognominal joined
smls The previous rule (variable is initialized to the appropriate type object before executing the initializer) was also simple enough. Though I understand the desire for extra safety that may help to spot typos/thinkos. 20:27
20:28 rurban_ joined
smls I guess it could always be re-allowed once someone finds a good use for it... :P 20:28
20:30 llfourn left 20:31 captain-adequate joined, Averna joined 20:32 bin_005 left 20:33 espadrine joined
FROGGS problem was this simple thing: 20:33
m: say my $a = $a
GLRelia rakudo-moar 117b99: OUTPUT«(Any)␤»
camelia rakudo-moar 375435: OUTPUT«5===SORRY!5=== Error while compiling /tmp/NNghgCgL0A␤Cannot use variable $a in declaration to initialize itself␤at /tmp/NNghgCgL0A:1␤------> 3say my $a = $7⏏5a␤ expecting any of:␤ term␤»
FROGGS m: my $a = $a; say $a
GLRelia rakudo-moar 117b99: OUTPUT«(Any)␤»
camelia rakudo-moar 375435: OUTPUT«5===SORRY!5=== Error while compiling /tmp/uBiBWohdeL␤Cannot use variable $a in declaration to initialize itself␤at /tmp/uBiBWohdeL:1␤------> 3my $a = $7⏏5a; say $a␤ expecting any of:␤ term␤»
20:33 bin_005 joined
FROGGS err 20:34
m: my $a := $a; say $a
GLRelia rakudo-moar 117b99: OUTPUT«(signal SEGV)»
camelia rakudo-moar 375435: OUTPUT«5===SORRY!5=== Error while compiling /tmp/7ZFOXxu8Vf␤Cannot use variable $a in declaration to initialize itself␤at /tmp/7ZFOXxu8Vf:1␤------> 3my $a := $7⏏5a; say $a␤ expecting any of:␤ term␤»
FROGGS this
jnthn We should really fix the SEGV down in the VM too, though I know about why that one happens... 20:36
Time to rest up ahead of tomorrow's long trip... 20:39
'night, #perl6
nine m: (1, 2, 3 X** 2, 4).perl.say
GLRelia rakudo-moar 117b99: OUTPUT«((1, 1, 4, 16, 9, 81))␤»
camelia rakudo-moar 375435: OUTPUT«(1, 1, 4, 16, 9, 81)␤»
20:42 virtualsue joined, breinbaas joined 20:46 espadrine left
nine Oh, when I just return gather { ... } instead of $policy(gather { ... }) with $policy being &list, the infinit list case works! And so do the other use cases I understand. Just 4 spec tests failing. 20:47
20:49 virtualsue left 20:50 virtualsue joined
dalek kudo/glr: bf657a1 | (Stefan Seifert)++ | src/core/metaops.pm:
Fix "This Seq has already been iterated" on METAOP_CROSS results

Frankly, I don't know why, but without wrapping the results in the &list call many more tests pass and neither infinite loops nor "This Seq has already been iterated" messages occur.		 20:53
TimToady woke up at 5 this morning, but maybe that means he can actually backlog a little... 20:56
nine And the remaining spec test failures may actually be due to desired semantics changes 20:57
m: (1,2 X ( <a b> X "x")).perl.say 20:58
GLRelia rakudo-moar bf657a: OUTPUT«(((1, (("a", "x"), ("b", "x"))), (2, (("a", "x"), ("b", "x")))))␤»
camelia rakudo-moar 375435: OUTPUT«((1, "a"), (1, "x"), (1, "b"), (1, "x"), (2, "a"), (2, "x"), (2, "b"), (2, "x"))␤»
nine m: (1,2 X ( <a b> X "x").flat).perl.say 20:59
camelia rakudo-moar 375435: OUTPUT«((1, "a"), (1, "x"), (1, "b"), (1, "x"), (2, "a"), (2, "x"), (2, "b"), (2, "x"))␤»
GLRelia rakudo-moar bf657a: OUTPUT«(((1, "a"), (1, "x"), (1, "b"), (1, "x"), (2, "a"), (2, "x"), (2, "b"), (2, "x")))␤»
TimToady we may end up with some metaops to help with flattening on X and Z and such
maybe one for flattening args, and maybe another for slipping the result 21:00
so like |X might slip the result, and _X or X_ might flatten the args 21:01
or F, or whatever the bikeshed colors itself
AlexDaniel m: say split(';', "a;b;c", :all).perl; 21:02
GLRelia rakudo-moar bf657a: OUTPUT«Seq.new␤»
camelia rakudo-moar 375435: OUTPUT«(("a", ";"), ("b", ";"), "c")␤»
AlexDaniel hmmm
TimToady arguably could be ("c",Nil) for the final
AlexDaniel it really should be 21:03
dalek ast/glr: 1ac5df1 | (Stefan Seifert)++ | S03-metaops/cross.t:
Adopt GLR semantics in S03-metaops/cross.t
nine PLEASE if you have any love at all for Perl 6 review this patch ^^^
vendethiel nine: wouldn't "$policy(...)" be kinda hard to optimize anywya?
nine: why is it "flat @()" and not "flat ()"? 21:04
nine vendethiel: I don't even know what it's for. I removed it and all spec tests for cross pass. And two more spec test files.
vendethiel nine: I gather it used to be for flattening
21:04 bin_005 left
vendethiel m: say @(1, 2, (3, (4,))).elems; say (1, 2, (3, (4,))).elems 21:04
camelia rakudo-moar 375435: OUTPUT«3␤3␤»
GLRelia rakudo-moar bf657a: OUTPUT«3␤3␤»
vendethiel nope!
nine vendethiel: indeed, flat is enough, no need for @() 21:05
vendethiel m: say (1..3 X 'a'..'b') #is that itemized for some reason? hence the need for @()
camelia rakudo-moar 375435: OUTPUT«1 a 1 b 2 a 2 b 3 a 3 b␤»
GLRelia rakudo-moar bf657a: OUTPUT«1 a 1 b 2 a 2 b 3 a 3 b␤»
TimToady yes list infixes are tighter than list prefixes
vendethiel m: say (1..3 X 'a'..'b').perl
GLRelia rakudo-moar bf657a: OUTPUT«Seq.new␤»
camelia rakudo-moar 375435: OUTPUT«(1, "a", 1, "b", 2, "a", 2, "b", 3, "a", 3, "b")␤»
dalek ast/glr: c97a3a5 | (Stefan Seifert)++ | S03-metaops/cross.t:
Remove no longer needed @() in S03-metaops/cross.t

Thanks to vendethiel++ for pointing that out		 21:06
TimToady m: say (1..3 X 'a'..'b').gist
camelia rakudo-moar 375435: OUTPUT«1 a 1 b 2 a 2 b 3 a 3 b␤»
GLRelia rakudo-moar bf657a: OUTPUT«1 a 1 b 2 a 2 b 3 a 3 b␤»
vendethiel nine: well, the commit goes way back: github.com/perl6/roast/commit/c876...3d61d3e7db might've been cargo culting
TimToady I think gist should be glrized a bit to show some parens 21:07
either that, or .perl needs a mod/variant that forces eval of the front of a list 21:08
currently .gist and .perl are tuned for non-glr flattening 21:09
nine Ok, I'm going to remove all the $policy code from X and Meta X. I don't understand it and it seems to be hurting more than helping and if something is missing afterwards, we can maybe find a better solution anyway.
AlexDaniel m: $_.perl.say for split(';', "aa;bb;cc", :all); 21:10
GLRelia rakudo-moar bf657a: OUTPUT«("aa", ";")␤("bb", ";")␤"cc"␤»
camelia rakudo-moar 375435: OUTPUT«("aa", ";")␤("bb", ";")␤"cc"␤»
AlexDaniel m: $_[0].say for split(';', "aa;bb;cc", :all);
GLRelia rakudo-moar bf657a: OUTPUT«aa␤bb␤cc␤»
camelia rakudo-moar 375435: OUTPUT«aa␤bb␤cc␤»
AlexDaniel wow
so [0] does nothing in this case
I've never thought about it 21:11
m: say 'test'[0][0][0][0];
GLRelia rakudo-moar bf657a: OUTPUT«test␤»
camelia rakudo-moar 375435: OUTPUT«test␤»
vendethiel nine: nice! 21:12
TimToady: I read the backlog a bit, but I'm not sure I read the answer to this question: do you want "my @a = 1, @a" to be (1, 1, 1 ...) (à la haskell)?
21:13 virtualsue left 21:14 bin_005 joined
TimToady not sure it makes sense with 'my' due to assignment semantic, but would certainly be nice if 'constant' could be self referential 21:14
dalek kudo-star-daily: d5ed494 | coke++ | log/MoarVM- (4 files):
today (automated commit)
TimToady and we might intuit a lazy if we see the same symbol on the left and right
haskell obviously never needs to have explicit lazy, since everything already is... 21:15
dalek kudo/glr: 44cb3de | (Stefan Seifert)++ | src/core/ (2 files):
Remove dubious $policy from X and Meta-X.

It seems to be hurting more than helping and if something is missing afterwards, we can maybe find a better solution anyway		 21:17
nine 261/1047 spec test files failing in glr
The only test failing in cross.t now is not ok 27 - [] does not flatten
is ([1,2] X~ <a b>), '1 2a 1 2b', '[] does not flatten'; 21:18
21:19 araujo joined
AlexDaniel TimToady: half way through reporting it I'm realizing that ("c", Nil) is not really better 21:19
TimToady okay, was just an idle thought 21:20
nine jnthn: is ([1,2] X~ <a b>), '1 2a 1 2b', '[] does not flatten'; cannot work with the nqp::istype(elem, Iterable) distinction between item and list because no matter how much you itemize [1,2], it will stay Iterable and thus be iterated over. 21:21
ugexe ===> Install OK for: XML # xml already works glr
vendethiel nine: I think jnthn has gone to sleep
nine .tell jnthn is ([1,2] X~ <a b>), '1 2a 1 2b', '[] does not flatten'; cannot work with the nqp::istype(elem, Iterable) distinction between item and list because no matter how much you itemize [1,2], it will stay Iterable and thus be iterated over.
yoleaux nine: I'll pass your message to jnthn.
nine vendethiel: thanks
nine should do the same 21:22
TimToady right, by the one-arg rule
AlexDaniel if you shove Nil there, then any code that is using delimiters should always check for Nil. But without Nil, you can sometimes just forget about it (e.g. iterate over every even element or something)
21:22 virtualsue joined
AlexDaniel I could be wrong but that's not a problem for me, at least 21:22
TimToady well, probably is bound to an optional at some point, so can be missing 21:23
nine TimToady: so, should I just remove the test as bogus? 21:24
TimToady or put $[1,2] there
nine TimToady: that doesn't help with the current implementation, because $[1,2] is still iterable.
TimToady ah, right
nine TimToady: and nqp::istype(elem, Iterable) is the way jnthn++ showed me how to do it 21:25
TimToady so it'd have to be ([1,2],) or so
we probably need a prefix form of that
nine ([1,2],) would give the desired result
TimToady not sure prefix:<,> would be a good idea though
21:26 vike joined
smls isn't that what &list does? 21:27
TimToady m: say @$[1,2] X~ <a b>
GLRelia rakudo-moar 44cb3d: OUTPUT«1a 1b 2a 2b␤»
camelia rakudo-moar 375435: OUTPUT«Use of Nil in string context in block <unit> at /tmp/PQSmh1z8P4:1␤Use of Nil in string context in block <unit> at /tmp/PQSmh1z8P4:1␤Use of Nil in string context in block <unit> at /tmp/PQSmh1z8P4:1␤Use of Nil in string context in block <unit> at …»
dalek ast/glr: 3ad246c | (Stefan Seifert)++ | S03-metaops/cross.t:
Fix remaining S03-metaops/cross.t test

According to the one-arg rule, [1,2] passed to meta-X has to flatten. Have to use ([1,2],) to avoid that.
nine Now only 260/1047 spec test files failing :)
21:28 rurban_ left, vike left 21:29 brrt left 21:31 Averna left 21:32 Averna joined
pyrimidine nine++ # glr fixes 21:36
21:39 MadcapJake joined, bin_005 left 21:40 virtualsue_ joined 21:42 bin_005 joined, virtualsue left, virtualsue_ is now known as virtualsue 21:44 yqt joined 21:48 diana_olhovik left 21:51 MadcapJake left 21:52 bin_005 left 22:13 TEttinger joined 22:17 bbkr joined, breinbaas left 22:18 skids joined 22:19 MadcapJake joined 22:22 Zoffix joined 22:26 Woodi joined
smls Looks like Pod::To::HTML fails a test on nom. Can anyone confirm? 22:26
bbkr I was processing nested data structures in parallel and I encountered interesting deadlock. Here is the gist: gist.github.com/bbkr/78e048b94f9fb622e3a6 . Basically it is recursive "do await for { start { } }" construct. It works fine for small data structures, but if it wants to spawn more Promises at the same time than available threads this code never ends. Is my approach faulty or is it Rakudo bug?
22:27 llfourn joined 22:30 telex joined 22:31 llfourn left, smls_ joined 22:32 smls left 22:35 Averna left
smls_ bbkr: I think that's to be expected with a thread pool scheduler 22:38
not sure though
22:39 smls_ is now known as smls 22:41 virtualsue left
skids m: my $a = (1,).iterator; while $a.pull-one -> $it { say join " ", $it.WHICH, IterationEnd.WHICH, ($it.WHICH =:= IterationEnd.WHICH) ; last if $++ == 1; } 23:01
GLRelia rakudo-moar 44cb3d: OUTPUT«Int|1 Mu|39768080 False␤Mu|39768080 Mu|39768080 False␤»
camelia rakudo-moar 375435: OUTPUT«5===SORRY!5=== Error while compiling /tmp/DkOLOdv2uD␤Undeclared name:␤ IterationEnd used at line 1␤␤»
skids Ah, binding. 23:02
23:02 captain-adequate left
skids m: my $a = (1,).iterator; while $a.pull-one -> $it { say join " ", $it.WHICH, IterationEnd.WHICH, ($it =:= IterationEnd) ; last if $++ == 1; } 23:05
GLRelia rakudo-moar 44cb3d: OUTPUT«Int|1 Mu|52600704 False␤Mu|52600704 Mu|52600704 False␤»
camelia rakudo-moar 375435: OUTPUT«5===SORRY!5=== Error while compiling /tmp/nSv1WVu7BU␤Undeclared name:␤ IterationEnd used at line 1␤␤»
skids Aha. -e you bastard. 23:06
That's what I thought from the start.
bbkr smls: I think I understand this Promise deadlock now. Promises are created for first and second level of recursion in parallel. And when first level manage to create 16 of them there is no free thread to process promises on second level required by first level. 23:12
23:12 yqt left
bbkr smls: but I still don't know what is the best pattern for parallel recursive processing. gotta dig through the smarter "no pictures of cats here" part of the internet 23:16
timotimo has reached home safely 23:19
23:25 spider-mario left
japhb smls: Please consider turning gist.github.com/smls/a1f6033c142202bddc4d into benchmarks in github.com/japhb/perl6-bench 23:27
smls: This would probably give me good incentive to implement easier comparison of results between related tests. 23:28
timotimo i would like that feature
japhb Yeah, you've been wanting that for quite a while. It's just never quite risen enough in priority. 23:29
smls bbkr: Sounds about right. Not sure about the best solution. Maybe you can factor out the recursion and feed a flat list to the loop that calls 'start'? 23:30
japhb: I alrerady did, back in June... :P It's the rc-perfect-shuffle benchmark. 23:31
japhb: Or did you mean having multiple benchmarks for the different variants?
timotimo japhb: right; no worries, though
japhb smls: Yes, that (multiple benchmarks for different variants). Right now there's no easy way to templatize variants (if this gets to be a major demand, I would consider it), so they need to be created as multiple separate tests. 23:32
timotimo i'm going to bed now. 23:38
dalek pan style="color: #395be5">perl6-examples: fc16c64 | (Flavio Poletti)++ | categories/euler/prob025-polettix.pl:
bigints are now available... yay!
 23:40
23:58 aborazmeh joined, aborazmeh left, aborazmeh joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!