»ö« 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.
dalek kudo/allomorphs: f0c5b49 | ShimmerFairy++ | src/Perl6/ (2 files):
Implement a compile-time version of val() in World

This is called to help streamline val() processing on strings with compile_time_values. This version, unlike the one in src/core, calls on the Perl 6 grammar to do the work (something val() might like to do someday). It also has three possible return values: an allomorphic constant, if possible, the original string QAST if we know it can't be a value, or a call to val() where we're unsure of the string.
This takes my sorting benchmark from ≈27.7s to ≈16.2s average, compared to nom's 12.4s average. This seems to me to be sufficiently close to pre-val() speeds that this could be merged into nom whenever appropriate.
This test passes all spectests the previous commit did (that is, those tests relying on a stricter val() definition still fail, pending decisions about allomorphic types in this area).		 00:14
timotimo why does the benchmark get slower, ooc? 00:18
Cannot find method '5'
that's fun
ShimmerFairy timotimo: the initial speed decrease was about 90s on a smaller sort, because my initial val() was horribly inefficient. I found that val() was optimized as much as could reasonably be, so the compile-time version eliminates run-time calls for things like %hash<foo> and such 00:20
timotimo: the specific sort line is 0.^methods(:all).sort (the smaller version lacking the :all), and that generates warnings about stringification. That warning ends up calling an AT-POS with a ton of %hash<foo> accesses, hence the slowdown :) 00:21
timotimo i'd not expect <foo> as a postcircumfix to invoke val semantics 00:22
ShimmerFairy timotimo: well, the spec says that <> is eqv. to q:w:v// and «» is eqv. to qq:ww:v// , with no qualifiers or exceptions, so that's what I did :)
timotimo hmm 00:23
and what does %hash<foo> actually compile to? at the qast level?
and with --target=optimize, does it turn into a WVal? as in: a pre-created object to be loaded from the serialized blob? 00:24
i feel like i'm about to fall over sideways and fall asleep 00:25
ShimmerFairy timotimo: before that commit, it turned into an Op('&val', Want(WVal(Str), Ss, SVal(foo)), to use an abbreviated invalid format :)
optimize on that shows no change, and trying to use 'is pure' on val earlier did nothing to help
timotimo mhm
ShimmerFairy (just realized I forgot a ) on my invalid format above :P) 00:26
timotimo and before your branch? 00:27
ShimmerFairy not sure, I'd have to recompile it (but it'd be without a val call, like it is for compile_time_values now) 00:28
timotimo ah
and after your commit, in that branch?
"an allomorphic constant" being a WVal-ref'd object?
ShimmerFairy yes, I used $*W.add_constant to add the allomorphic type, if it exists (otherwise fallback on a runtime &val call) 00:29
That could possibly be fixed by making the allomorphic types BOOTSTRAPed ones, but I'm not sure that's necessary as of yet
timotimo i'm still surprised it's become that slow :( 00:30
anyway, i'll go to bed now
have a good one! 00:31
ShimmerFairy timotimo: it's not that bad anymore, just about 4s for that one benchmark :)
♞! o/
timotimo "just 4s", but that's a quarter of what it was before
ShimmerFairy timotimo: true, but that sort emits a ton of warnings that each use a bunch of <> constructs, so small differences add up. At this point I think the slowdown will be usually imperceptible (even this would be, I think, if I weren't timing it closely ☺) 00:32
I think there could perhaps be optimization in CORE to be had by using {'...'} instead of <...> -- sure, it's weird, but as long as <> is _always_ val()'d, that's the kind of optimization I'd expect to find in CORE code :) 00:34
(also, we've been without val() for far too long, so a lot of the new nits, like using {'...'} to ensure string-only, will seem less awesome than if it had been implemented earlier. In other words, we're too used to <> and «» not doing anything val()-ish ☺) 00:35
paralaxia p6: [+] 1//6 00:44
camelia ( no output )
ShimmerFairy Just did some checking, and Backtrace.AT-POS() is where the offending subscripts were. At 12376 subscripts total from that method (for the :all version), that 4s increase is about .0003s more per subscript, or .3ms. I don't think that turns out to be so bad :)
dalek kudo-star-daily: d5c2dcf | coke++ | log/ (7 files):
today (automated commit)
 01:18
rl6-roast-data: 06a44a7 | coke++ | / (10 files):
today (automated commit)
dalek rl6-roast-data: 0ebb5c8 | coke++ | / (4 files):
glr has been merged back to nom
 01:23
AlexDaniel m: my Int $x = 5; my Str $x = 'hello'; say $x; 03:44
camelia rakudo-moar 5e1b08: OUTPUT«Potential difficulties:␤ Redeclaration of symbol $x␤ at /tmp/KeKcvEXWd2:1␤ ------> 3my Int $x = 5; my Str $x7⏏5 = 'hello'; say $x;␤Type check failed in assignment to '$x'; expected 'Str' but got 'Int'␤ in block <unit> at /tmp/KeKc…»
AlexDaniel “less LTA”, heh 03:59
tokuhiro_ how do i write a test case to support before this commit github.com/rakudo/rakudo/commit/26...9e2d3b1bc9 and after this commit? 04:28
tokuhiro_ In perl5, i can write a code like `__PACKAGE__->can(‘done-testing’) or eval “sub done-testing { done }”` for workaround. 04:35
FROGGS m: use Test; say &::('done-testing') # tokuhiro_: check for its existence..., but don't check for &done, because that exists anyway 06:16
camelia rakudo-moar 5e1b08: OUTPUT«sub done-testing () { #`(Sub|48978944) ... }␤»
FROGGS m: use Test; &::('done-testing') ?? &::('done-testing')() !! &::('done')() 06:18
camelia rakudo-moar 5e1b08: OUTPUT«1..0␤»
FROGGS star-m: use Test; &::('done-testing') ?? &::('done-testing')() !! &::('done')()
camelia star-m 2015.03: OUTPUT«1..0␤»
tokuhiro_ FROGGS: thanks! 06:21
FROGGS tokuhiro_: you're welcome 06:22
TimToady I'm not sure there's actually a use case for val()-based subscripts, since you can always write .{1/2} rather than .<1/2> and rely on constant folding, since you always have the brackets to prevent precedence accidents 06:49
breakfast &
jnthn I could happily live without .<...> doing val(...) but if it *does* then there should be zero runtime performance cost 06:54
yoleaux 6 Sep 2015 02:36Z <ShimmerFairy> jnthn: I put japhb's code in val(), with minimum modification to make it work properly, and got marginal improvements (null program startup decreased by about .01s, profiling sorting line shows it went down ≈1.2s). It's of course better (so I'll keep it in ☺), but val()'s implementation seems to be a non-issue now
6 Sep 2015 02:39Z <ShimmerFairy> jnthn: I suspect having a version of val() in World.nqp, or perhaps even in NQP itself, for strings with compile_time_values would be the most helpful, considering how many constant strings in quotewords there are in CORE and such :)
jnthn Because in $foo<bar> we can prove that bar is just going to be a Str at compile time and produce exactly what we do now. 06:55
.tell ShimmerFairy I think $foo<bar> style things really do need resolving to strings at compile time, yes. But...why make another version of val()? Why not just look up $*W.find_symbol(['&val']) from the setting and call it? And if it's not defined yet, then just assume a Str is fine as a fallback. 06:56
yoleaux jnthn: I'll pass your message to ShimmerFairy.
jnthn .tell bbkr Saw your post; I think the deadlock will go away once I implement the smarter version of await that makes thread pool threads available to do other work while they're awaiting. 06:58
yoleaux jnthn: I'll pass your message to bbkr.
st_iron hi 07:02
jnthn meeting & 07:04
moritz Hi st_iron; even though nobody greeted you for 20 minutes, you're not alone :-) 07:23
masak hi st_iron -- Europe is still waking up, methinks :) 07:33
masak m: say "hi, ", OUR::.^name.substr(0, 2).lc, "_", :a.^name.substr(2), (1|2).^name.substr(*-2) 07:36
camelia rakudo-moar 5e1b08: OUTPUT«hi, st_iron␤»
masak Just Another Perl 6 Greeting :P
FROGGS masak++ 07:40
test__ p6; say 3 07:41
masak m: say 3
camelia rakudo-moar 5e1b08: OUTPUT«3␤»
mrf morning 07:42
masak mrf! \o/ 07:43
st_iron moritz: thanks for reassuring :) 07:48
masak: hi 2u2 :)
it's is still morning, but this part of the world wakes up around 5am nowadays
I like to play a bit with languages (spoken and not spoken) in the early morning 07:49
TimToady --> Málaga & 07:50
cdc m: say OUR::.^name 07:52
camelia rakudo-moar 5e1b08: OUTPUT«Stash␤»
masak st_iron: nice to hear that. 07:53
st_iron: so, what (if anything) brings you to #perl6?
st_iron is playing with Rakudo Star before the Christmas release
and where else could I read more info than on the IRC channel of #perl6 07:54
masak so true. 07:55
m: say so True
camelia rakudo-moar 5e1b08: OUTPUT«True␤»
masak m: say so so so so so not False 07:56
camelia rakudo-moar 5e1b08: OUTPUT«True␤»
masak m: say infix:<&&>() 07:56
camelia rakudo-moar 5e1b08: OUTPUT«True␤»
FROGGS m: say [&&] 07:57
camelia rakudo-moar 5e1b08: OUTPUT«True␤»
masak m: say [max] 07:59
camelia rakudo-moar 5e1b08: OUTPUT«-Inf␤»
FROGGS m: say [>] # :D 08:01
camelia rakudo-moar 5e1b08: OUTPUT«True␤»
FROGGS m: say <!-- Place your beer here --> # such comment 08:02
camelia rakudo-moar 5e1b08: OUTPUT«(!-- Place your beer here --)␤»
bbkr_ jnthn: so basically "await start { await start { sleep } }" will take only 1 thread from pool? sounds really tough to implement :) 09:14
Solidstate Is Rakudo-Star 2015.07 an official release? 09:18
Anyone manage to get "make rakudo-spectest" pass in Rakudo-Star 2015.07? 09:22
moritz it's just as official as all the other rleases 09:30
and I'm pretty sure the tests passed for the (compiler-) release manager, otherwise he shouldn't have released it 09:31
FROGGS Solidstate: what test failures do you see? 09:37
Solidstate FROGGS: sorry was out to lunch. I got: 10:12
Test Summary Report ------------------- t/spec/S17-lowlevel/lock.rakudo.moar (Wstat: 11 Tests: 7 Failed: 1) Failed test: 7 Non-zero wait status: 11 Parse errors: Bad plan. You planned 8 tests but ran 7. t/spec/S32-io/IO-Socket-Asyn
hmm sec bad formatting
Solidstate Test Summary Report 10:13
-------------------
t/spec/S17-lowlevel/lock.rakudo.moar (Wstat: 11 Tests: 7 Failed: 1)
Failed test: 7
Non-zero wait status: 11
Parse errors: Bad plan. You planned 8 tests but ran 7. 10:14
t/spec/S32-io/IO-Socket-Async.rakudo.moar (Wstat: 65280 Tests: 5 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 6 tests but ran 5.
t/spec/S32-io/IO-Socket-INET.t (Wstat: 65280 Tests: 37 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 47 tests but ran 37.
Files=1028, Tests=45938, 1110 wallclock secs ( 7.03 usr 2.04 sys + 803.69 cusr 60.30 csys = 873.06 CPU)
Result: FAIL
sorry about that, I'm sure there's a better way to copy-paste multi-line content into this chat... 10:15
Ven Solidstate: usually, gist.github.com 10:17
Solidstate Ven - thanks, created gist.github.com/anonymous/da814a2c...tfile1-txt 10:22
Solidstate BTW I did some searching and at least one other user reported similar failure message for t/spec/S32-io/IO-Socket-INET.t , perhaps related to my issue: www.nntp.perl.org/group/perl.perl6....11077.html 10:29
I'm using Perl 5.10.1, don't have access to newer :( 10:30
On the bright side, after "make install" : 10:34
> ./test.p6
Hello, World!
:)
ShimmerFairy Solidstate: the lock and Async tests are safe to ignore (the Async test was fixed some time ago, and there was work on the lock tests recently). Don't know about the INET one, though. 10:38
yoleaux 06:56Z <jnthn> ShimmerFairy: I think $foo<bar> style things really do need resolving to strings at compile time, yes. But...why make another version of val()? Why not just look up $*W.find_symbol(['&val']) from the setting and call it? And if it's not defined yet, then just assume a Str is fine as a fallback.
ShimmerFairy .tell jnthn: I thought about calling &val, I just wasn't sure if compile_time_eval was inefficient or otherwise bad (in the way that the inverse, EVAL, is usually a sign of needing to rethink your code). The Str fallback means it could skip val() on valid values in CORE, but then again I don't think CORE needs allomorphs :) (I already pushed the result of "another version" to the allomorphs branch, if you missed it) 10:42
yoleaux ShimmerFairy: What kind of a name is "jnthn:"?!
ShimmerFairy .tell jnthn I thought about calling &val, I just wasn't sure if compile_time_eval was inefficient or otherwise bad (in the way that the inverse, EVAL, is usually a sign of needing to rethink your code). The Str fallback means it could skip val() on valid values in CORE, but then again I don't think CORE needs allomorphs :) (I already pushed the result of "another version" to the allomorphs branch, if you missed it) 10:43
yoleaux ShimmerFairy: I'll pass your message to jnthn.
FROGGS Solidstate: these tests (apart from the mentioned one) are flappers... they are usually skipped when a release is made
Solidstate: so yes, you can ignore these for now, but we have to take care of them rather soonish 10:44
Solidstate FROGGS - thanks
FROGGS debugging and fixing these will be "fun" :/ 10:45
ShimmerFairy .tell jnthn For the record, I'd be fine if we said that %h<foo bar> didn't go under val() (and perhaps don't do val() on colonpairs either, e.g. :foo<bar>). FWIW TimToady already said %h<42> wouldn't let you access Int keys, for example. 10:46
yoleaux ShimmerFairy: I'll pass your message to jnthn.
cdc bbkr_: about irclog.perlgeek.de/perl6/2015-09-07#i_11179225, maybe what jnthn++ had in mind was more about task-based parallelism (ie. several tasks per thread, task migration). As explained here: bartoszmilewski.com/2011/10/10/asyn...there-yet/ This is just my guess, though. 10:51
FROGGS ShimmerFairy: +1 to that fwiw 10:52
I've always seen %h<foo bar> a shortcut for %h{'foo bar'}
ShimmerFairy FROGGS: it does mean the mention of <> and «» in S02 would be less simple, but I think people expect hash subscripts at least to be string-only things :)
well, %h<foo bar> is a shortcut for %h{'foo', 'bar'}, but aside from that I think that's what most people expect, yes :) . 10:53
FROGGS is it really that?
ShimmerFairy well, it _is_ a qw list :)
FROGGS m: my %h = 'foo bar' => 1, foo => 2, bar => 3; say $h<foo bar> 10:54
ShimmerFairy m: my %h = 1,2,3,4; say %h<1 3>
camelia rakudo-moar 5e1b08: OUTPUT«5===SORRY!5=== Error while compiling /tmp/DuU5m4X88E␤Variable '$h' is not declared. Did you mean '%h'?␤at /tmp/DuU5m4X88E:1␤------> 3'foo bar' => 1, foo => 2, bar => 3; say 7⏏5$h<foo bar>␤»
rakudo-moar 5e1b08: OUTPUT«(2 4)␤»
FROGGS m: my %h = 'foo bar' => 1, foo => 2, bar => 3; say %h<foo bar>
camelia rakudo-moar 5e1b08: OUTPUT«(2 3)␤»
FROGGS hmmm, so my memory is bogus anyway
ShimmerFairy m: my %h = 'foo bar' => 1, foo => 2, bar => 3; say %h«foo 'foo bar' bar»
camelia rakudo-moar 5e1b08: OUTPUT«(2 1 3)␤»
FROGGS I see 10:55
ShimmerFairy So, <> is spec'd as q:w:v// , and «» is spec'd as qq:ww:v// , but I'd be happy going back to :v-less for hash subscripts, and maybe colonpairs (not sure about that, since that for the record includes infix:<example>) 10:56
masak ShimmerFairy: I think :v-less hash subscripts would be less confusing. 10:58
but possibly also less consistent.
in other words, I'm not sure what I think. :/
ShimmerFairy Yeah, the consistency issue is concerning, but like I pointed out TimToady already said :{1 => 2}<1> wouldn't get you what you want, which suggests a mostly-Stringy use of <> for that context 10:59
The idea of having :v on <> and «», if my guess is correct, is that you can enter in numeric things without being forced to go back to a ('foo', 42, 'bar') style list. So I suppose the question is if there are some contexts where we want to force you to revert to that list style after all. 11:02
ShimmerFairy There's also the potential argument that you should have to do %hash{'foo'} if you really want just a string, and that not having val() for so long has let you get away with assuming <> was safely string-only :) 11:07
nine I thought the whole point of the differentiation between <> and {} was to get rid of the ambiguity of {} in Perl 5 11:11
ShimmerFairy I wouldn't know about that, and I don't quite see where the ambiguity you're referring to is. (val() produces an allomorphic type that's both a string and a number, so you can treat it whichever way you mean) 11:14
nine And the compiler/runtime has to somehow guess what I mean. That's the ambiguity.
FROGGS in Perl 5 $foo{flubber} would mean 'flubber' as a string
ShimmerFairy nine: no, it's just a case of multiple inheritance. If multiple candidates of a multi match, that's your hint to be explicit about what you want now. 11:16
masak there's one kind of ambiguity in Perl 5 (literal string vs bare expression) and another in Perl 6 (Str type vs some other type, like Int) 11:17
ShimmerFairy It's not like $foo{flubber} in Perl 5, where you don't know if that's seen as a string xor as a term. allomorphs are more "it's a string _and_ a number!", not an either/or thing. 11:18
masak yes.
but nine is also right that such allomorphism introduces cases where Perl 6 itself now has to guess between e.g. the string and the number. 11:19
like in :{1 => 2}<1>
ShimmerFairy Like I said, there may be some cases where we don't want <> and «» to let you use numerics and still have a nice, space-separated list :) 11:20
FROGGS what will happen if you call foo($int-str) when there is a foo(Str) and foo(Int) candidate? it will be an ambiguous call, right?
ShimmerFairy yes, and that's specifically mentioned in the spec as something that'll happen :)
FROGGS k 11:21
ShimmerFairy "In case multiple dispatch determines that it could dispatch as either string or number, a tie results, which may result in an ambiguous dispatch error. You'll need to use prefix + or ~ on the argument to resolve the ambiguity in that case."
FROGGS I think that's one reason why multiple inheritance might not be always desirable :o)
ShimmerFairy so perhaps remove the implied :v in contexts where you can't easily prefix-disambiguate items? 11:22
right after that quote, there's "[Conjecture: we may someday find a way to make strings bind a little looser than the numeric types, but for now we conservatively outlaw the dispatch as ambiguous, and watch how this plays out in use.]" 11:23
jnthn bbkr_: Uh, not if you sleep and actually block the thread, no, but if you are just awaiting something then yes, the idea is to free up the awaiting thread (perhaps to work on the thing being awaited) 11:27
yoleaux 10:43Z <ShimmerFairy> jnthn: I thought about calling &val, I just wasn't sure if compile_time_eval was inefficient or otherwise bad (in the way that the inverse, EVAL, is usually a sign of needing to rethink your code). The Str fallback means it could skip val() on valid values in CORE, but then again I don't think CORE needs allomorphs :) (I already pushed the result of "another version" to the allomorphs branch, if you missed it)
10:46Z <ShimmerFairy> jnthn: For the record, I'd be fine if we said that %h<foo bar> didn't go under val() (and perhaps don't do val() on colonpairs either, e.g. :foo<bar>). FWIW TimToady already said %h<42> wouldn't let you access Int keys, for example.
jnthn ShimmerFairy: You're not doing compile_time_eval in the normal case though, you're just looking up an (already-called) val sub and calling it, then taking the object it returns and adding it to the SC so you can reference it in a QAST::WVal 11:28
ShimmerFairy One idea is that you could do %h{<foo bar>} if you really want the allomorphic types, now that I think about it. I think "can't manually choose which interpretation you want" might be a good metric for places where <> implies :v and where it doesn't. 11:29
ShimmerFairy jnthn: is there an existing example of this in the parser that I could look at for reference? (Or is it otherwise not hard to figure out?) 11:30
FROGGS my $v := $*W.find_symbol(['Version']).new(~$<vstr>); 11:33
$*W.add_object($v);
make QAST::WVal.new( :value($v) );
ShimmerFairy: ^^
ShimmerFairy oh, so P6 functions (or at least object methods) are exposed to NQP when they exist? cool! :) (I think I noticed that with a .new in add_constant earlier, but I didn't realize that was a general thing) 11:35
moritz $*W gives access to the complete lexical environment of the program being compiled 11:41
pmurias jnthn: do you think it would be ok to merge the js branch into the master nqp branch? 11:44
moritz if it doesn't break anything for moar or jvm, go for it! 11:46
jnthn pmurias: If it makes maint easier, and what moritz++ said, then I'm fine with it 11:47
pmurias it shouldn't break anything
jnthn pmurias: It is bootstrapped-ish and so has about the same build as other things, yes?
Or not quite that far along yet? 11:48
pmurias not yet bootstrapped, should be boostraping soonish 11:49
the differences in the way it builds are kept in Makefile-JS.in
jnthn ok 11:51
pmurias .tell hoelzro before merging in js into the master branch remember to run the tests for the jvm/moar backends to make sure our improved test suit doesn't uncover any bugs in those 11:57
yoleaux pmurias: I'll pass your message to hoelzro.
jnthn m: say Seq 12:26
camelia rakudo-moar 5e1b08: OUTPUT«(Seq)␤»
jnthn m: multi foo(@x) { }; foo((1..10).grep(* %% 2)) 12:27
camelia rakudo-moar 5e1b08: OUTPUT«Cannot call foo(Seq); none of these signatures match:␤ (@x)␤ in block <unit> at /tmp/qlP5MgkFMP:1␤␤»
jnthn m: multi foo([$x, *@xs]) { }; foo((1..10).grep(* %% 2))
camelia rakudo-moar 5e1b08: OUTPUT«Cannot call foo(Seq); none of these signatures match:␤ (@ (Any $x, *@xs))␤ in block <unit> at /tmp/QH9iuvdqdx:1␤␤»
jnthn ohh...the test had .List thrown in rather than the multi-dispatcher being fixed 12:29
So cheating!
brrt many deception 12:32
jnthn Yeah.
jnthn is working out the best way to fix up the multi dispatcher for this case :) 12:32
jnthn Hm, most dispatches hit the cache so I guess I don't need to overly worry about making a wildly efficient solution... 12:33
FROGGS we should implement a neural network and then teach it the right candidates :o)
brrt that is going to be a serious suggestion in about 18 months, i'm thinking 12:34
moritz ... nope. 12:36
the real problem with neural networks is that, even when they work, they simply aren't transparent
brrt hmmm
relational databases aren't transparent to many people
and people use them for everything 12:37
moritz but there are people who can still explain their behavior
jnthn
.oO( Will relational databases ever have a sequal? )
moritz and when the maintainers receive bug reports, they can say "this is not a bug because..."
geekosaur postgres thinks it is one... :p
brrt hmm 12:38
maybe you are right
but then again
i see them popup everywhere
arnsholt The biggest problem with using an ANN (or any other ML method) for compilery stuff is that there's going to be false positives, which are going to wreck your semantics 12:39
moritz I know a case in Germany where a bank trained a neural network to do credit rating
arnsholt In some cases false negatives can also be problematic
brrt do tell
moritz and they had better performance than the previous algorithms
and then somebody who got denied a loan sued 12:40
and since the bank couldn't tell why the neural network denied here the loan, they stopped using it (at least for rejections :-)
masak moritz: why was it so important for the bank to know why the neural network had denied her the loan? 12:43
moritz masak: because to prove that it's not discriminatory not to business with somebody, you have to be able to state the actual reasons 12:44
arnsholt Because laws, probably
brrt who would sue for a denied loan?
moritz *not to do
brrt that makes no sense to me 12:45
hmmm
ok, that does make some sense
moritz brrt: maybe it was a customer protection agency on behalf of somebody, dunno
arnsholt That's a thing which is discussed every now and then in ML circles
arnsholt Especially since most ML methods tend to give large weight to features that proxy for things like race and socio-economic class, even though they're not overt in the training data 12:46
brrt my suspicion is that if the ML algorithm is not fed with data that we could understand as being discriminatory, e.g. doesn't actually know your religion, then it couldn't make any discriminatory inferences that a human would not also make without the data
brrt but it's kind of a circular problem 12:47
'algorithm isn't discriminatory, it just rejects loans from these zipcodes'
arnsholt Yeah, it's definitely non-trivial 12:49
masak this discussion reminds me of Amazon's recommendation engine being horribly racist at some point by mistake 12:53
arnsholt Yeah
Or face recognition algorithms only finding white people 12:54
And digital camera blink recognition false-positives on Asian people 12:55
masak that one is easier to understand, though. probably only tested on fair-skinned folks
arnsholt Yeah, not enough non-White people in the training set 12:55
moritz and here I thought most cameras where developeed in Asia anyway 12:56
brrt masak: what? 12:57
have an example of that? i'm curious 12:58
dalek kudo/nom: 9fdaf03 | jnthn++ | src/ (2 files):
Fix Seq and multi-dispatch interaction.

Can now pass a Seq to a multi wanting an @arg again.		 13:00
ast: 9583915 | jnthn++ | S06-multi/type-based.t:
Test for RT #126003.
 13:01
ast: 6b99c9e | jnthn++ | S06-signature/unpack-array.t:
Remove no-longer-needed .List.

This was added to get the test passing under GLR, but really the multi dispatcher should have been fixed instead. Now it is, so clean up.
jnthn Well, that gets us back down to 1040... 13:02
FROGGS jnthn: do you have any hints on the jvm breakage?
jnthn Also the last GLR-related RT I can see
FROGGS: No, 'cus I ain't really looked at it at all...
Did it get bisuct?
FROGGS jnthn: I'm willing to spent a few more hours on it, but I dunno what to try next
it is kinda bisectable me thinks 13:03
err, unbisectable
moritz a flapper?
FROGGS no
moritz then what makes it unbisectable?
FROGGS Array.new used to NPE until a recent patch by TimToady 13:04
jnthn
.oO( flappy bug, the successor to flappy bird )
FROGGS and that recent patch uncovers a "Cannot call .jast on NQPMu"
jnthn Hmmm
FROGGS I could bisect to the point before the NPE probably 13:05
jnthn I guess I can do a build and take a look
jnthn sets off the NQP build
FROGGS jnthn: the only thing I know: it gets the entire setting, calls .as_jast on it in comile_all_the_stmts, and the result of that seems to be NQPMu 13:06
*I think I know
jnthn hm
jnthn was pondering blogging about GLR stuff but then realizes he should probably just spend the time updating S07
Especially as somebody already bitched about that not having been done :P 13:07
FROGGS *g*
jnthn wonders if it'll be faster to update the GLR draft or just write what got implemented 13:10
Advantage of JVM backend hacking: have time to go make a cup of tea during the build... :)
masak :) 13:13
brrt has glr been merged yet?
another advantage: never be cold when using your computer 13:14
eiro jnthn, awesome talk at YAPC::Asia! thanks a lot 13:20
hello everyone
FROGGS hi eiro 13:21
jnthn eiro: :) 13:21
brrt: yes
brrt cool 13:22
jnthn FROGGS: Well, I reproduced the error at least
brrt somehow i've missed that
masak eiro: hello! 13:23
eiro what's up masak? long time no see :( 13:24
anyone attending patch -p3 here? i miss the perl6 community
FROGGS lizmat and wendy should be around 13:25
at least I think so... 13:26
masak eiro: I was at YAPC::Europe, where were you? :) 13:27
El_Che_ touché 13:31
:)
masak m: given 1, 2 { when 1, 2 { say .^name } } 13:57
camelia rakudo-moar 9fdaf0: OUTPUT«List␤»
dalek kudo/nom: 23286d4 | jnthn++ | src/vm/jvm/Perl6/Ops.nqp:
Map missing op on JVM.

This gets it through the CORE.setting build, and just exploding on startup since the op is NYI.
masak I hadn't really realized that you can smartmatch on a List with `when`. it's nice. 14:01
dalek kudo/nom: 749b72e | jnthn++ | src/vm/jvm/runtime/org/perl6/rakudo/RakOps.java:
Implement p6configposbindfailover for JVM backend.

Though the stuff it stashes isn't yet being used.		 14:01
jnthn :) 14:02
FROGGS m: given 1, 2 { when 1, 2, 3 { say .^name } } 14:04
camelia ( no output )
FROGGS m: given 2 { when 1, 2, 3 { say .^name } }
camelia rakudo-moar 9fdaf0: OUTPUT«Int␤»
FROGGS such consistency :o) 14:05
masak FROGGS: wait, however does 2 smartmatch on 1, 2, 3? 14:15
m: say 2 ~~ (1, 2, 3)
camelia rakudo-moar 749b72: OUTPUT«(1 2 3)␤»
masak o.O 14:15
masak m: say "bananas" ~~ (1, 2, 3) 14:17
camelia rakudo-moar 749b72: OUTPUT«(1 2 3)␤»
colomon ??
m: say ("bananas" ~~ (1, 2, 3))
camelia rakudo-moar 749b72: OUTPUT«(1 2 3)␤»
jnthn I *think* that's to make if $a ~~ m:g/.../ { } work out, fwiw 14:18
timotimo that's the list.accepts returns self thing, right? 14:19
jnthn Before you never saw it for such examples 'cus of the Parcel/List distinction.
masak I'm not sure how I feel about that. 14:20
m:g is nice, but messing up List smartmatching for the sake of getting it to work; not so much
jnthn Yeah, I left it as it was 'cus in terms of "what does List do" it wasn't a semantic change. :) 14:21
But figured it'd end up getting revisisted.
timotimo revisionize it!
ShimmerFairy I'd expect ~~ to be like ∈ in that case, but without building Sets :) 14:22
jnthn I don't actually know what to do about it, so it'll have to be left for TimToady++ :)
smls ShimmerFairy: That's what item ~~ any(list) is for
or item eqv any(list) 14:23
ShimmerFairy still thinks a lot of the set ops could be useful for any kind of Positional, and not just Set objects, btw
dalek kudo/nom: 1a76417 | jnthn++ | src/vm/jvm/runtime/org/perl6/rakudo/ (2 files):
Toss mention of LoL in JVM-specific code.

Also note that slurpy params still need re-doing.
kudo/nom: 15a0856 | jnthn++ | src/vm/jvm/ (4 files):
Further GLR steps for JVM backend.

Toss the ops we no longer need, and add some throws where we need to update the code further. This means that the build should now explode post-setting and with more useful hints of what needs doing to get the JVM backend up and running post-GLR.
jnthn The JVM backend gets through the CORE.setting build by now 14:24
masak m: say 4 ∈ [1, 2, 3]; say 4 ∈ [6, 3, 4] 14:25
camelia rakudo-moar 749b72: OUTPUT«False␤True␤»
masak ShimmerFairy: ^^
ShimmerFairy: or were you hoping for something more than that?
(all the other set ops work, too)
ShimmerFairy masak: Last I used them, they created Set objects you had to manually convert back to a list type 14:26
m: say (1,2) ∪ (3,4)
camelia rakudo-moar 749b72: OUTPUT«set(4, 3, 1, 2)␤»
ShimmerFairy like that :)
eiro back ... managers ... always bother me when i chat on irc ! 14:27
ShimmerFairy I think I'd like it if set operators that didn't get any Set objects didn't end up making Sets 14:27
grondilu finally wrote a GLR-compatible version of SHA-256 14:28
masak ShimmerFairy: I think that's an unreasonable expectation.
jnthn ShimmerFairy: That's the (coercey) way operators in Perl 6 work.
masak ShimmerFairy: compare "10" + "32"
eiro El_Che, masak right .... didn't afford it this year. touché
masak eiro: too bad :/ it was a nice conf 14:28
ShimmerFairy I know that already, I mean that I think it might be nice if said set operators had multis for non-Set-using calls 14:29
eiro but Cluj will be the year of my next yapc!
jnthn was sad to miss it too :(
eiro i saw the schedule and yes: it seems it was awesome. hope we will meet at yapc
ShimmerFairy I know it's just a minor thing, but whenever I've used set ops on lists, I've just converted them right back to lists afterward, so it seems a bit wasteful to have a Set created in that case. 14:29
masak ShimmerFairy: then define your own ops that add the coercing. 14:31
ShimmerFairy Why are you talking about coercing? That doesn't make sense to me here.
masak then that's probably where we should start the discussion. 14:33
most Perl operators coerce to something.
infix:<+> coerces to numeric, for example
the set operators coerce to set
eiro s/yapc/fosdem 14:35
grmbl ... meeting again. goodbye everyone 14:36
ShimmerFairy well, I know about coercing arguments, but that's not what I'm talking about. I'm talking about versions of the set operators which operate on non-Set arguments, and don't involve Set in the process
masak yes, you are. 14:37
and that's kind of going against the grain of how Perl usually works/thinks, is the point. 14:38
&
ShimmerFairy (I think my problem lies in the fact that sets are such a listy thing to me that it's weird how I'm forced into having the Set type by using set operators. A lot of those ops are just as valid on any kind of list, so why make me use Set?)
moritz ShimmerFairy: then write those ops you want, publish them in a module; if they turn out to be universally used, we can core them
ShimmerFairy I still have no clue how "coercion" factors into what I'm talking about. For me, only Int() type constraints are "coercion", as well as the various prefix ops 14:39
ShimmerFairy thinks the "write it yourself!" response is kinda rude, tbh :/ 14:40
FROGGS ShimmerFairy: fwiw, I'd like to use set ops on lists... 14:41
ShimmerFairy It's of course possible right now, I just find it questionable that I have to implicitly construct a Set object to use them, esp. when I'm just going to toss it in list conversion as soon as I'm done with using set ops. 14:42
jnthn ShimmerFairy: Maybe consider if you shoulda been using sets rather than lists in the first place?
FROGGS hmmm 14:43
ShimmerFairy jnthn: if Sets were more Positional than Associative in implementation, that'd be an easier choice for me, I'm guessing :) (Like I said, it's been a while since I last used set ops)
jnthn Yes, but if they weren't then set membership testing would be O(n) instead of being O(1) :) 14:44
ShimmerFairy jnthn: true. It's just really strange to have it based on Associative when there's nothing being associated in a set :) 14:45
dalek kudo/nom: 376d727 | jnthn++ | src/vm/jvm/runtime/org/perl6/rakudo/Binder.java:
First pass at *@foo and **@foo on JVM post-GLR.

Can't yet tell if they work at get us to the next explosioin, or work and cause the next explosion.
jnthn heh, that second work should be don't work :)
ShimmerFairy: It probably makes more sense of Bag and Mix 14:46
*on
ShimmerFairy I think the issue is that in those cases I need a list most of the time, _except_ when I want to do something nifty like an intersection between two lists. So for that one moment I need a Setty thing just because the set ops force it.
But like I said, it's just a minor thing I've noticed whenever I've wanted the set ops to filter two lists in some way, not that big a deal :) 14:50
jnthn Hm, no, seems the slurpy patch is at least fairly OK and the issue is elsewhere 14:53
colomon ShimmerFairy: sets are NOT a listy thing. In particular, they have no ordering on their elements. 14:55
ShimmerFairy well, I perceive sets as an unordered, unique collection of items, and as they're written out they tend to look a lot like lists to me, so thus an unordered, unique list of items :) 14:56
I agree that they're not really Positional in the way other Positional things are, but they sure ain't Associative either :) 14:59
dalek kudo/nom: d8e7b1d | jnthn++ | src/vm/jvm/runtime/org/perl6/rakudo/Binder.java:
Bring hllize semantics in line with Moar backend.

Fixes RETURN-LIST crash, getting us further through startup on JVM.		 15:01
jnthn Gets to line 30348 of loading CORE.setting now 15:02
FROGGS only 5k lines to go then 15:03
jnthn Method 'Int' not found for invocant of class 'Any' in SUBSTR-SANITY (gen/jvm/CORE.setting:9696)
wtf?!
jnthn m: Any.Int 15:06
camelia rakudo-moar 15a085: OUTPUT«Method 'Int' not found for invocant of class 'Any'␤ in block <unit> at /tmp/JVU8xwhRtc:1␤␤»
jnthn Oh...
jnthn So it's that we're getting Any passed in there... 15:08
nine From the backlog: yes, List.ACCEPTS right now is a weird blend of pre-GLR Parcel's and List's that made the spec tests pass but is bound to raise some WTFs 15:09
ugexe m: ::("::Foo"); 15:11
camelia rakudo-moar d8e7b1: OUTPUT«Start argument to substr out of range. Is: 1, should be in 0..0; use *1 if you want to index relative to the end␤ in block <unit> at /tmp/kvYJ2_PvpS:1␤␤Actually thrown at:␤ in block <unit> at /tmp/kvYJ2_PvpS:1␤␤»
dalek kudo/nom: c89820c | jnthn++ | src/core/Inc.pm:
Add missing nqp::hllize.

Gets normal startup to...fail at the same place we do if you give a
  -Ilib.		 15:16
jnthn Darn, hoped that'd fix the -Ilib case too...
jnthn is rather confused by the next JVM issue 15:25
psch hi #perl6 o/ 15:27
ab5tract_ ShimmerFairy: on the contrary... sets have all (my, anyway) expected behavior for Associative, and none for Positional
psch just saw the bit with m:g// on the clog and wanted to mention the re-specing that had happened 15:28
ab5tract_ unordered, unique
psch we used to want m:g// to return a nested match object instead of a List
ShimmerFairy ab5tract_: well, to me an "Associative" thing, well, associates things. And sets don't do that :)
nine ab5tract_: but the values in the set are not "associated" with anything
psch i'll dig for the corresponding discussion
ab5tract_ In fact, Perl 5 never really needed sets because we just use hashes for everything
it's associated with True
psch ab5tract_: i .tell'd you to "ab5stract" a few weeks ago, in case you hadn't seen that, re: jvm-interop iirc 15:29
ShimmerFairy well, I don't think existence counts for much of an association, but that's just me :)
ab5tract_ ah! sorry about that
ShimmerFairy: the point is, you implement sets with hashes (if you want an efficient set, that is)
nine ab5tract_: that it' with True is purely an implementation detail.
ab5tract_ so clearly they are far more Associative than Positional 15:30
nine taion leaking out into the design.
ShimmerFairy I don't think sets are either, actually.
ab5tract_ nine: what else would $set{ $val } return ?
ShimmerFairy: fair enough. I am just responding to your position that "but they sure ain't Associative either" 15:32
not sure I saw the "either" when I first read that, though
ShimmerFairy ab5tract_: what I meant with that line was that I don't think sets cleanly fit into either role :)
jnthn OK, I'll put JVM backend hacking aside for a bit now 15:33
ab5tract_ Indeed. Still, I'm very much of the opinion that a Set is just a Hash with some Setty sugar on top
jnthn It's not working again yet post GLR, but it's a lost closer and failing in a hopefully less terrifying way so others might be able to figure out what's going on. 15:34
If nobody can I'll take another whack at it later in the week. :)
*a lot closer
nine That you can use AT-POS semantics with sets is nice. It's when $set.list returns a list of Pairs where the surprises start 15:35
jnthn: thanks! 15:37
ab5tract_ nine: true
nine: except that I would automatically have reached for .keys anyway :) 15:38
but it's a valid point
nine In 13 years of mathematics at school I've never heard that sets contain some sort of keys. Just items.
ab5tract_ We patched around that for .Bag and .Mix conversion 15:39
timotimo yeah, sets are inside out, so to speak
nine While I can absolutely see the nice sides of the generalization from an implementor's perspective, I don't feel all that comfortable with it from a user's.
ab5tract_ I do want to caveat that I've been havily Perl-ified wrt to sets. Something interesting happened on the way to my math education, and I never pursued it all that way 15:40
nine But I'd also like to add that it's bickering at a high level. IF that's the ugliest part of the language, then we are very well off indeed :)
ab5tract_ nine: I believe that the .list as Pairs thing was GLR-related
jnthn ab5tract_: I don't recall that being a GLR change, fwiw 15:41
nine jnthn: I do seem to remember some change lizmat++ did at the SPW. I think before her change it was even more confusing. 15:42
And I sort of grudingly made peace with Sets being Hashes there. 15:43
ugexe wishes he had the math chops to bicker at *any* level 15:44
pink_mist to me, hashes are just sets with associativity added on 15:47
rather than the other way; sets being hashes with nonsensical associativity because of implementation details 15:48
nine m: sub foo() { return :c(3) }; say foo().perl; 16:02
camelia rakudo-moar c89820: OUTPUT«:c(Mu)␤»
jnthn Phew, think I've nailed RT #125987 16:04
jnthn m: use Test; my $i = 0; react { whenever supply { emit 'x'; emit 'y'; } { $i++ } }; is $i, 2, 'react/whenever with supply that immediately emits values works'; 16:07
camelia rakudo-moar c89820: OUTPUT«Useless use of emit in react in any at /home/camelia/rakudo-inst-2/share/perl6/runtime/CORE.setting.moarvm:1␤not ok 1 - react/whenever with supply that immediately emits values works␤␤# Failed test 'react/whenever with supply that immediately emits…»
dalek kudo/nom: 6e5105d | jnthn++ | src/core/Supply.pm:
Fix handler scoping issue with whenever.

whenever $s { } where $s is a Supply that immediately emitted values upon subscription would end up running the wrong handlers, entangling the various supplies involved.		 16:09
dalek ast: 294d0e4 | jnthn++ | S17-supply/syntax.t:
Test for RT #125987.
 16:09
andreoss m: sub MAIN() { say "hi" } 16:10
camelia rakudo-moar c89820: OUTPUT«hi␤»
andreoss m: sub MAIN() { my $x = True; END say "hi" if $x } 16:10
camelia ( no output )
andreoss m: sub MAIN() { my $x = True; END say "hi" }
camelia rakudo-moar c89820: OUTPUT«hi␤»
andreoss is it a bug?
pink_mist m: sub MAIN() { my $x = True; END { say "hi" if $x } } 16:11
camelia rakudo-moar c89820: OUTPUT«hi␤»
nine jnthn: if I may ask, what in 6e5105d78f is the actual bugfix? The removal of the duplicate nqp::exception() call or replacing cod() by &code?
jnthn nine: Actually the lifting of the closure taking for the handler blocks out of the nqp::handle 16:12
The passing &code is an optimization I probably shoulda put in separate...
pink_mist m: sub MAIN() { my $x = True; END { say "hi" } if $x }
camelia rakudo-moar c89820: OUTPUT«hi␤»
pink_mist huh, that one also works 16:13
jnthn And the removal of the duplicate nqp::exception was actually something I tried first :)
nine Oh a subtle fix combined with two diversions then ;)
jnthn m: sub MAIN() { my $x = True; (END say "hi") if $x }
camelia rakudo-moar c89820: OUTPUT«hi␤»
jnthn nine: Yeah, sorry 'bout that
nine No worry. Just asking to learn :) 16:14
jnthn m: sub MAIN() {(END say "hi") if $x } 16:15
camelia rakudo-moar c89820: OUTPUT«5===SORRY!5=== Error while compiling /tmp/UAv2xDtGD6␤Variable '$x' is not declared␤at /tmp/UAv2xDtGD6:1␤------> 3sub MAIN() {(END say "hi") if 7⏏5$x }␤»
jnthn m: sub MAIN() { my $x; (END say "hi") if $x }
camelia rakudo-moar c89820: OUTPUT«hi␤»
jnthn m: sub MAIN() { my $x = True; END say $x }
camelia rakudo-moar c89820: OUTPUT«(Any)␤»
jnthn m: sub MAIN() { my $x = True; END { say $x } }
camelia rakudo-moar c89820: OUTPUT«True␤»
jnthn There's a golf of it
Likely deserves to go RT-wards
nine Seems like my little Map refactor uncovers quite a few Pair related bugs 16:22
jnthn More than just a pair of 'em, I take it...
moritz we should do that Pairiodically :-) 16:32
nine What is a QAST::Want+{QAST::SpecialArg}?
jnthn A QAST::Want that has had the QAST::SpecialArg role mixed in (meaning it's either a named arg or flattening arg) 16:33
nine How is such a thing usually created? 16:34
Ah, by being .named or .flat 16:35
jnthn Yes 16:36
psch jvm/glr build failure is gcx.LoL and gcx.ListIter being null, from the looks of it 16:41
psch the former i imagine replacing with gcx.List is OK, the latter i'm unsure what to do 16:41
moritz what is it used for? 16:44
jnthn psch: I already fixed those bits
psch jnthn: oh. and i was sure i pulled before looking at it :/ 16:45
oh duh 16:46
glr has been merged as well
dalek pan style="color: #395be5">perl6-examples: 7701347 | andreoss++ | / (4 files):
[euler] problem 60
psch that's what i get for neglecting my keeping up
moritz m: say roundrobin(<a b>; <c d>).^name 16:47
camelia rakudo-moar 6e5105: OUTPUT«Seq␤»
moritz m: say <a b c>.pick.^name 16:49
camelia rakudo-moar 6e5105: OUTPUT«Str␤»
moritz m: say <a b c>.pick(1).^name
camelia rakudo-moar 6e5105: OUTPUT«Seq␤»
moritz m: say <a b c>.roll(1).^name 16:51
camelia rakudo-moar 6e5105: OUTPUT«Seq␤»
moritz m: say <a b c>.roll.^name
camelia rakudo-moar 6e5105: OUTPUT«Str␤»
moritz m: say <a b>.map({$_}).^Seq 16:53
camelia rakudo-moar 6e5105: OUTPUT«Method 'Seq' not found for invocant of class 'Perl6::Metamodel::ClassHOW'␤ in block <unit> at /tmp/tKAaKtnmGb:1␤␤»
moritz m: say <a b>.map({$_}).^name
camelia rakudo-moar 6e5105: OUTPUT«Seq␤»
moritz m: say <a b>.reverse.^name 16:54
camelia rakudo-moar 6e5105: OUTPUT«List␤»
moritz m: say <a b>.rotate(1).^name 16:55
camelia rakudo-moar 6e5105: OUTPUT«List␤»
dalek ecs: 7acbc45 | moritz++ | S32-setting-library/ (3 files):
Remove mentions of Parcel from S32
 16:56
moritz this commits also cleans up some odd return values
like map returning a List of Parcel
jnthn :)
moritz++
I've also started on an S07 re-write
agaurav77 Hi everyone, I've just started viewing tickets on rt.perl.org, and I'm a bit new. Could someone point me to any easy bug? 17:50
moritz agaurav77: I'm taking a look... 17:51
agaurav77 thanks 17:52
moritz agaurav77: rt.perl.org/Ticket/Display.html?id=126006 might be easy 17:53
nine I slowly start to doubt that I'm ready for debugging Perl6::Actions 17:55
moritz agaurav77: also rt.perl.org/Ticket/Display.html?id=125555 17:56
moritz m: my Int $x; my Str $x; $x = 'foo'; 17:57
camelia rakudo-moar 6e5105: OUTPUT«Potential difficulties:␤ Redeclaration of symbol $x␤ at /tmp/uCXxvYO149:1␤ ------> 3my Int $x; my Str $x7⏏5; $x = 'foo';␤»
moritz m: my Int $x; my Str $x; $x = 'foo'; say $x;
camelia rakudo-moar 6e5105: OUTPUT«Potential difficulties:␤ Redeclaration of symbol $x␤ at /tmp/8bX4mq4FOg:1␤ ------> 3my Int $x; my Str $x7⏏5; $x = 'foo'; say $x;␤foo␤»
agaurav77 moritz: 126006 might have been fixed
agaurav77 $f.e says 'True' for me 17:58
looking 125555...
FROGGS nine: what's wrong? 18:00
nine FROGGS: the fix you gisted yesterday seems to work. Unfortunately there seem to be other places that try to create Pairs without values. For example use Foo :named; or return :c(1); 18:02
Both seem to be genuine bugs in Rakudo and that they haven't been fixed yet may correlate with them not being easy fixes...
FROGGS nine: yes, I'd also seen that {:a(1) :b(2)} is broken... I wasn't able to check if my patch is to blame or not 18:03
nine: aye, they are certainly not easy
nine I could of course just work around by giving value a default value of Mu
FROGGS I was even thinking we should toss the support of chained adverbs without a comma... 18:03
moritz +1 18:04
+2
+Inf
FROGGS nine: I can give it a whirl again, but most likely not this evening, as I am still working on the jvm
moritz oh wait, I think %hash<foo>:k,:v might be ambiguous 18:05
nine FROGGS: if you have any hints for me, I'd also be happy to do some more digging 18:06
FROGGS nine: well, I potentially would try to port the circumfix:<( )> patch to circumfix:<{ }> 18:12
nine: but I guess the basic task is to remove all hurting .named that inject QAST::SpecialArgs in the ast 18:13
nine Makes sense. Both. 18:14
FROGGS what we are currently doing is kinda backwards sadly... 18:15
nine backwards how? 18:16
FROGGS in :a :b the second adverb is applied to the first..., and later we try to disentangle them as if a comma was in between
nine Is there a way to dump a piece of QAST for debugging? 18:20
FROGGS nine: sure 18:20
timotimo note($node.dump)
FROGGS nine: nqp::say($past.dump)
nine That's so.....obvious :) 18:21
timotimo and if you do that, make sure you have my latest nqp commit
nine don't display :decl() in qast dumps?
timotimo yup 18:24
nine FROGGS: I'm happy to report that I successfully ported your fix to {:a(1) :b(2)} :) 18:44
timotimo sweet
nine No progress however on use Foo :something; 18:45
Well I found out that the latter is an arglist and I know which .named call is responsible. Sadly it seems to be needed in some cases, though I don't understand why. The code is creating code for creating a Pair after all. 18:46
FROGGS the .named is only needed if it is going to be a named argument in a call 18:47
AFAIK
nine So if I can detect that it's not actually an arglist for a call, I can safely skip it. 18:49
FROGGS that's what I would attempt 18:50
nine Or the other way around: only do it if it's for a call
A job for a dynamic variable in the grammar?
dalek p: 626b327 | FROGGS++ | src/vm/jvm/QAST/Compiler.nqp:
cleanup handling of unkown ops

We used to catch an exception to append source information to the message in order to die again using that more informative message. Now we just put this extra information in the very first exception. That helps us to avoid a problem where we visited the same CATCH block twice.		 18:54
FROGGS nine: now I can also try fiddling with use Foo :something;
nine All tests successful. :)
FROGGS what? 18:55
nine use Foo :something; works :)
FROGGS ohh!
timotimo neato 18:55
FROGGS I'm eager to see the patch...
nine: do we still need the hunt_loose_adverbs thing?
nine FROGGS: yes, that's still in. My fix really is not that exciting 18:56
These are my first steps in Actions after all :)
FROGGS nine: I really enjoy that area 18:58
moritz at its heart, it's very simple code: it transforms one tree into another, bit by bit
it just gets complicated when you have to the conventions of how the target tree must look like 18:59
AlexDaniel moritz: Oh yes, indeed! I was confused about my line numbers. However, “Note that redeclarations actually replace the previous declaration, at compile time. So at the time the initialization of the first declaration of $x is run, its type has already changed to Str.” – what if that goes into the error message? That would be awesome. If only it is always correct… 19:01
dalek kudo/gmr: 3649f9d | (Stefan Seifert)++ | src/Perl6/Actions.nqp:
Fix use Foo :whatever<1> losing the adverb's value
 19:03
kudo/gmr: 2cae30e | (Stefan Seifert)++ | src/Perl6/Actions.nqp:
Fix (:a(1) :b(2)) dieing due to missing value arg to Pair.new

Patch by FROGGS++
kudo/gmr: 7f80346 | (Stefan Seifert)++ | src/Perl6/Actions.nqp:
Fix {:a(1) :b(2)} dieing due to missing value arg to Pair.new
 19:04
moritz is gmr "Great Module Refactoring"? 19:05
FROGGS Map*
timotimo Great Meep Refactoring
nine Great Map Refactor. Since the GLR was named after the immutable base type, I used Map instead of Hash for the name. And m follows l after all ;)
moritz ah :-)
nine Those 3 fixes should actually be of value whether we merge the gmr or not. 19:06
jnthn should look at the GMR at some point :) 19:09
Though the commit messages have sounded pleasing :) 19:10
Happy to see the Enum/Pair thing go
And just have Pair
AlexDaniel
.oO( GMRelia? )
jnthn m: say 2 ** 99999999999999999999999999999999999 19:13
camelia rakudo-moar 6e5105: OUTPUT«0␤»
jnthn hm
jnthn hoped the "too wide" thingy would nail that
AlexDaniel jnthn: “too wide” thing? 19:14
jnthn m: my int $a = 99999999999999999999999999999999999; 19:17
camelia rakudo-moar 6e5105: OUTPUT«Cannot unbox 117 bit wide bigint into native integer␤ in block <unit> at /tmp/0X124iJ8Y3:1␤␤»
jnthn That one.
AlexDaniel oh, I've seen that error. Is it something new? 19:18
timotimo hm, isn't there something like "arbitrarily unsupported" somewhere?
AlexDaniel because if yes, then I should probably revise my bug reports… 19:18
there were lots of them associated with overflows
pink_mist jnthn: isn't that specifically about int? and Int or Num should transparently just make it work? 19:19
AlexDaniel timotimo: I think that it is about lists.
jnthn AlexDaniel: Yes, that error is the solution to the overflows where it shows up
AlexDaniel: So a lot of your bug reports are now closable with tests.
AlexDaniel jnthn: amazing! 19:20
jnthn I think FROGGS++ is to test
AlexDaniel m: "x" xx 9999999999
camelia rakudo-moar 6e5105: OUTPUT«Memory allocation failed; could not allocate 79999999992 bytes␤»
AlexDaniel m: "x" xx 999999999999999999
camelia rakudo-moar 6e5105: OUTPUT«Memory allocation failed; could not allocate 7999999999999999992 bytes␤»
AlexDaniel m: "x" xx 999999999
camelia rakudo-moar 6e5105: OUTPUT«Memory allocation failed; could not allocate 7999999992 bytes␤»
AlexDaniel m: "x" xx 99999
camelia ( no output )
AlexDaniel m: "x" xx 999999
camelia ( no output )
AlexDaniel m: "x" xx 99999999
camelia ( no output )
jnthn AlexDaniel: Did you mean x?
AlexDaniel m: "x" xx 999999999
camelia rakudo-moar 6e5105: OUTPUT«Memory allocation failed; could not allocate 7999999992 bytes␤» 19:21
jnthn xx is list repetition and it's lazy
AlexDaniel jnthn: I know
the thing is, it just segfaulted for me.
jnthn Oh?
AlexDaniel can somebody try that? perl6 -e '"x" xx 9999999999'
jnthn I get the memory allocation failed
AlexDaniel Segmentation fault
timotimo "is to thank" ITYM
AlexDaniel hmm
I'll recompile
moritz too 19:22
jnthn timotimo: hah, yes!
dalek kudo/nom: 16d366a | jnthn++ | src/ (2 files):
Provide ACCEPTS hint on attempt to override ~~.
 19:23
AlexDaniel hehe, somehow I hope that it will segfault with the recent build… That would be my first segfault, I think!! geez, there's something wrong with me… 19:25
jnthn m: constant nums = 1; my \fizzbuzz = nums\ .map({ $_ }); 19:30
camelia rakudo-moar 6e5105: OUTPUT«5===SORRY!5=== Error while compiling /tmp/ncfxNFlrWX␤Variable '&nums' is not declared␤at /tmp/ncfxNFlrWX:1␤------> 3constant nums = 1; my \fizzbuzz = 7⏏5nums\ .map({ $_ });␤»
jnthn std: constant nums = 1; my \fizzbuzz = nums\ .map({ $_ });
camelia std 28329a7: OUTPUT«ok 00:00 140m␤»
jnthn m: constant nums = 1; my \fizzbuzz = nums\.map({ $_ });
camelia ( no output )
jnthn std: constant nums = 1; my \fizzbuzz = nums\.map({ $_ });
camelia std 28329a7: OUTPUT«ok 00:00 140m␤»
jnthn Very odd. Add some space there and it thinks it's looking at a sub call, not a term 19:31
TimToady waves from Málaga 19:32
jnthn notes this on RT #125985
o/ TimToady
TimToady: Guess you were at least somewhat attracted there by the airport having rather more options than Granada? :) 19:33
AlexDaniel OK, Segfault 19:34
I'm on 32-bit, that's probably why
jnthn Well, you better get 32 more bits quick! :P 19:34
AlexDaniel jnthn: why? :) 19:35
I'll better report that and hope that one day it will be fixed? :) 19:36
jnthn Can do :)
jnthn going for some rest :) 19:37
o/
FROGGS jnthn: o/
timotimo good rest, jnthn 19:39
AlexDaniel m: 'x' x 99999999999999 19:40
camelia rakudo-moar 6e5105: OUTPUT«repeat count > 1073741824 arbitrarily unsupported...␤ in block <unit> at /tmp/5vy28rwU54:1␤␤»
AlexDaniel timotimo: not lists, strings!
timotimo ah 19:41
damn the bootstrap process >_< 19:44
[Coke] evening 20:02
dalek rl6-roast-data: 2efa916 | coke++ | / (9 files):
today (automated commit)
FROGGS hi [Coke]
FROGGS btw, I've got a hack that get's us further building/installing rakudo on jvm 20:43
[Coke] yay 20:54
dalek c: 989af8b | labster++ | lib/Type/Numeric.pod:
s:g/Numerid/Numeric/
 21:13
lizmat_ waves from Belmonte, PT 21:23
FROGGS hi lizmat_ 21:24
vendethiel o/ FROGGS, lizmat_ 21:25
lizmat FROGGS vendethiel o/ 21:31
connection seems flaky and with large delay, so probably over satellite
timotimo ohai lizmat
lizmat timotimo o/
seems a lot of rosettacode entries got fixed by 9fdaf03b0a43e527f5a808f7a :-) 21:33
FROGGS that's the current state of perl6-j: gist.github.com/FROGGS/a6aee767b154a611f4ee 21:36
gnight all
lizmat gnight FROGGS 21:45
jdv79 oh... pause fix deplyed. i'lll test tomorrow as i'm wped out. 21:48
jdv79 nite 21:49
timotimo lizmat: i can't find a commit with that id anywhere :( 21:50
masak 'night, #perl6 21:52
timotimo gnite masak
lizmat timotimo: commit 9fdaf03b0a43e527f5a808f7a8eff68a18684be5 Author: jnthn [email@hidden.address] Date: Mon Sep 7 14:55:56 2015 +0200 21:57
in nom
timotimo oh! 21:59
lizmat good night, #perl6! 22:14
raiph o/ 22:15
p6doc says `.DEFINITE` is "True for instances and False for type objects" and `defined` is "False on the type object, and True otherwise". But TimToady clearly implied a distinction between defined and DEFINITE in his recent comment and, iirc, has always held to that view. What should the doc say? 22:16
mohij .tell tadzik: I'm more or less done with putting *env functionality into rakudobrew. Most commands work including local, global and shell switching. 22:17
yoleaux 4 Sep 2015 22:31Z <tadzik> mohij: Wow, thanks man!
mohij: What kind of a name is "tadzik:"?!
raiph .oO ( I guess .DEFINITE could be False for non type objects that aren't instances ) 22:18
mohij .tell tadzik I'm more or less done with putting *env functionality into rakudobrew. Most commands work including local, global and shell switching. 22:18
yoleaux mohij: I'll pass your message to tadzik.
mohij .tell tadzik I have only tested on linux so far. Will do some Windows testing soon. What do you think about merging? 22:19
yoleaux mohij: I'll pass your message to tadzik.
mohij .tell tadzik Tradeoff: Slight startup time decrease because the shims are perl and not bash anymore. 22:20
yoleaux mohij: I'll pass your message to tadzik.
psch raiph: aiu .defined depends on the type, while DEFINITE checks "does it have a value" 22:40
raiph: as in, .defined is allowed to return False for DEFINITE values which the type itself calls undefined 22:41
s/have a value/have any value/
psch m: say so 0 22:41
camelia rakudo-moar 16d366: OUTPUT«False␤»
psch m: say 0.defined; say 0.DEFINITE
camelia rakudo-moar 16d366: OUTPUT«True␤True␤»
psch ...that understanding doesn't quite survive this output though 22:42
psch wait, that got changed recently, didn't it? Mu.defined calls .Bool, which for Int now returns True for 0 because it was inconsistent before 22:42
m: class A { has $.a; method defined { return False if $.a == 0; True }; }; my ($a, $b) = A.new(:a(0)), A.new(:a(1)); say $a.defined, $b.defined; say $a.DEFINITE, $b.DEFINITE # this is what .defined is allowed to do aiu, in any case 22:45
camelia rakudo-moar 16d366: OUTPUT«FalseTrue␤TrueTrue␤»
ugexe the Proc constructor does a pretty good job of showing .DEFINITE usage i thought github.com/ugexe/rakudo/blob/nom/s...roc.pm#L14
psch m: say $*IN.defined; say $*IN.DEFINITE 22:47
camelia rakudo-moar 16d366: OUTPUT«True␤True␤»
psch ugexe: i'm still wondering why those calls couldn't be to .defined 22:47
i'll just try that i guess, i got stumped with jvm and let myself be distracted anyway :)
ugexe perl6 -e 'my $h = IO::Handle.new; say $h.DEFINITE; say IO::Handle.DEFINITE' 22:49
True
False
timotimo psch: i'm glad you're putting some effort into the jvm again :) 22:50
ugexe i guess .defined is the same result there
psch ugexe: yeah, the difference was raiph++s question 22:51
i laid out my understanding from the design above, but the impl doesn't quite seem to reflect it
timotimo: i try, thanks for the encouragement :)
timotimo .DEFINITE also goes directly to the underlying virtual machine's definition of definiteness
raiph I think current p6doc wording, taken precisely, as I quoted earlier, logically entails that .defined and .DEFINITE, called on a type object, return False, and called on an instance, return True, and called on a value that is neither type object nor instance, return True for .defined and False for .DEFINITE. 22:52
timotimo i.e. an nqp::isconcrete check
um
how can something be neither type object nor instance?
hm, well, nqp::null i suppose?
but those aren't supposed to show up in perl6 space at all
raiph I think I'm definite about that, but it's possible the definitions aren't exactly meant to be precise :)
psch fwiw, replacing all .DEFINITE calls with .defined gives me PASS for all files in t/spec/procasync 22:54
i think that's the right files to run, anyway :) 22:55
raiph: called on an object that is neither type object nor instance, from your quote .DEFINITE should be undefined, as i read it 22:56
...which most likely just makes all of this worse :)
raiph Hmm. Correction. I think p6doc wording logically entails that *some* values that are neither type object nor instance *may* return False. 22:57
(for .DEFINITE)
psch in any case, i can't think of any code that produces differing results between .defined and .DEFINITE 22:58
well, except something that overrides .defined 22:59
which is covered by what i wrote above
timotimo we could do a quick survey of what implementations of method defined exist in core 23:00
raiph psch: Yes. Per the p6doc lines I quoted, .defined and .DEFINITE are the same for all values -- except that for non type object / non instance it's True for .defined and undefined for .DEFINITE which means it can at most be different by being False
timotimo raiph: you're wrong 23:01
raiph timotimo: OK. :)
timotimo raiph: defined may also return 1, "hello", IO::Handle.new("/etc/passwd"), or -> { 1.rand }
raiph timotimo: note that I'm not speaking of how things actually are in the spec or rakudo or how they're meant to be, just what I infer from the p6doc lines I quoted (which are presumably slightly off) 23:02
timotimo OK 23:06
raiph Heh. I'm blind.
So p6doc says for Mu.defined "Returns False on the type object, and True otherwise." I believed that. But then a couple lines later "Very few types (like Failure) override defined to return False even for instances". 23:08
Which totally makes sense of course. I'd even read that before and enjoyed it. Part of the P6 approach to maybes/exceptions. And very simple, really. 23:10
psch m: { 1 + "a"; CATCH { default { .defined.say; .DEFINITE.say } } } # i'm still confused 23:15
camelia rakudo-moar 16d366: OUTPUT«True␤True␤»
psch m: { 1 + "a"; CATCH { default { .defined.say; .DEFINITE.say; .say } } } # i think 23:16
camelia rakudo-moar 16d366: OUTPUT«True␤True␤Cannot convert string to number: base-10 number must begin with valid digits or '.' in '⏏a' (indicated by ⏏)␤ in block <unit> at /tmp/MbtNvTOfch:1␤␤»
psch yeah, i am
timotimo so a failure being defined is confusing to you?
er, i mean
is that the object of confusion?
psch timotimo: in conjunction with raiph++'s quote, yes
iff p6doc says Failure overrides .defined to be False and its True in the impl, that's confusing 23:17
psch of course it might be that p6doc is wrong, i'm not precluding that possibility 23:18
i also think that p6devs mostly do things right, which means that the impl is probably correct
pink_mist I seem to recall reading something like that in one of the early synopses 23:19
pink_mist ah right, here: design.perl6.org/S02.html#Undefined_types 23:20
raiph My latest thinking is that what is intended is: DEFINITE == True for what I'll call normal objects and False for abnormal objects, and .defined is the same with the exception that some objects that want to be normal can pretend for a while to be abnormal until maybe normal code notices -- or doesn't, in which case it throws itself as an abnormality
(for above purposes type objects are considered abnormal objects) 23:21
timotimo psch: though, inside a CATCH, wouldn't it actually be the exception rather than the failure? 23:21
m: my $result = 1 + "a"; say $result.DEFINITE; say $result.defined 23:22
camelia rakudo-moar 16d366: OUTPUT«Cannot convert string to number: base-10 number must begin with valid digits or '.' in '⏏a' (indicated by ⏏)␤ in block <unit> at /tmp/N1z4SIkNm_:1␤␤Actually thrown at:␤ in block <unit> at /tmp/N1z4SIkNm_:1␤␤»
timotimo m: my $result = try 1 + "a"; say $result.DEFINITE; say $result.defined
camelia rakudo-moar 16d366: OUTPUT«False␤False␤»
timotimo m: my $result = try 1 + "a"; say $result.WHAT; say $result.DEFINITE; say $result.defined
camelia rakudo-moar 16d366: OUTPUT«(Any)␤False␤False␤»
timotimo m: my $result = try 1 + "a"; say $result
camelia rakudo-moar 16d366: OUTPUT«(Any)␤»
timotimo huh?
that ... doesn't seem right to me?
psch m: my $s = Failure.new; say $s.defined; say $s.DEFINITE 23:23
camelia rakudo-moar 16d366: OUTPUT«False␤True␤»
psch timotimo: you're right about Exception inside the CATCH, yeah
timotimo: but try leaking the Failure was deemed a bug a few months back, iirc 23:24
timotimo try leaking the failure?
you mean why $result didn't have the failure?
hmm 23:25
psch yeah, try is { ... { CATCH { default { } } }
where ... is the code appended
timotimo mhm 23:25
psch timotimo: irclog.perlgeek.de/perl6/2014-10-25#i_9564960 "a few months back" actually means "almost a year", in some cases... :) 23:37
dalek p/js: 65169c8 | (Pawel Murias)++ | src/vm/js/QAST/Compiler.nqp:
Store ctx in $*CTX in preparation for implementing nqp::handle.
 23:38
p/js: 43fc557 | (Pawel Murias)++ | src/vm/js/QAST/Compiler.nqp:
When compiling a return make it have a $T_VOID type instead of a $T_OBJ one.
p/js: d67f2a1 | (Pawel Murias)++ | src/vm/js/ (3 files):
Pass test 44.

Implement throwing, resuming, catching and rethrowing exceptions.
try/catch has a hefty performance penalty under v8 as it turns of optimalizations. Benchmarking and thinking things over is necessary if we want to minimalize the impact of that. This commit implement exceptions naively.
p/js: f282ebe | (Pawel Murias)++ | src/vm/js/nqp-runtime/runtime.js:
Fix bug when an exception is unhandled.
p/js: ca3389d | (Pawel Murias)++ | src/vm/js/ (2 files):
Make seekfh throw exceptions when passed an invalid offset or whence 0 and a negative offset.
p/js: fabfc28 | (Pawel Murias)++ | src/vm/js/ (2 files):
Stub nqp::getstdin.
labster m: 1/128 == (1/128).perl.EVAL 23:40
camelia rakudo-moar 16d366: OUTPUT«WARNINGS:␤Useless use of "==" in expression "/128 == (1/128).perl.EVAL" in sink context (line 1)␤»
labster m: say 1/128 == (1/128).perl.EVAL
camelia rakudo-moar 16d366: OUTPUT«False␤»
grondilu glad to see the js backend is still on its way 23:42
labster yes. pmurias++ 23:44
grondilu lately I've been learning a bit of HTML5/WebGL and a js backend is my only hope to ever use it with Perl 6, isn't it? 23:49
thus a js backend would really be cool
psch grondilu: you probably could write a p6 server-side webapp that dynamically serves webgl, but i think that'd be somewhat backwards... 23:52

Powered by Cro and the Raku® Programming Language.

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

Thank you!