[Tux] | This is Rakudo version 2016.08.1-48-gf2df2c5 built on MoarVM version 2016.08 | 07:03 | |
csv-ip5xs 10.233 | |||
test 15.488 | |||
test-t 7.439 | |||
csv-parser 16.548 | |||
rm -rf /tmp/*-p5helper.so | |||
(sorry 'bout that last line) | |||
lizmat wonders how simple simple-regex.com would be in Perl 6 | 07:27 | ||
breakfast& | |||
nine | Shameless repost of #perl6-toolchain material: github.com/perl6/toolchain-bikeshe...r/build.md | 07:47 | |
stmuk_ | it might be worth analysing the Build.pm files currently in the ecosystem | 08:15 | |
arnsholt | nine: I think I'd argue for the run parameter accepting a list as well | 08:16 | |
stmuk_ | I suspect many might resemble github.com/perl6/doc/blob/master/Build.pm and basically only copy files in place | ||
nine | stmuk_: yes, already started doing that | 08:17 | |
stmuk_ | nine++ # one step ahead | 08:18 | |
nine | stmuk_: I do hope that actually no other Build.pm file does what doc's does. Because doc's makes a whole lot of flawed assumptions. Like into which repo it's going to be installed. That this repo is a Repository::Locally at least. That the repo doesn't have a doc directory. That the repo is writable. | 08:20 | |
It's actually no custom build step at all. It's installation. | |||
stmuk_: I do hope you know that I mean well by criticising :) | 08:22 | ||
stmuk_ | :) | 08:23 | |
nine | p6doc certainly shows that we are still missing a lot of infrastructure. And that I didn't give documentation any thought at all :/ | ||
stmuk_: you could actually install the shipped .pod6 files as resources and access them via %?RESOURCES. That way you can get rid of a lot of poking in CURI's internals. | 08:26 | ||
stmuk_ | the docs are basically just S22 I think? | 08:27 | |
nine | S22 doesn't seem to mention docs at all? | 08:29 | |
stmuk_ | I meant general %?RESOURCES docs. I've seen no info about installing .pod6 at all | 08:30 | |
nine | Yes. You could put them into resources/docs/ and add them to the META.info's resources list: "resources": ["doc/Language/5to6-nutshell.pod6", ...] | 08:32 | |
Then access it via %?RESOURCES<doc><Language><5to6-nutshell.pod6> | 08:35 | ||
stmuk_ | would I have to list each file explicitly? all 354? | ||
nine | Yes. But I'm quite sure you can script that :) | 08:36 | |
stmuk_ | I'm prefer being able to put directories or wildcards in | 08:38 | |
dynmically generating a META6.json each time a file is added means the file gets very long and missed entries highly likely | 08:39 | ||
git commit -m"sorry I forgot to update META6.json again" | |||
nine | Possible. But right now you do have a couple of bugs in your Build.pm and p6doc. All of which would be fixed by moving to RESORUCES. | 08:42 | |
stmuk_ | the core p6doc files are probably a special case anyway due to the number of files | 08:45 | |
the p6doc problem was basically caused by moving the .pod from under 'lib' to 'doc' in the source tree | 08:48 | ||
nine | So far 46 commits added files to the doc/ directory | 08:50 | |
stmuk_ | cd doc/doc && find . -type f | wc -l | 09:03 | |
296 | |||
nine | A commit can add multiple files | 09:06 | |
I used git log -p doc | egrep -- '^commit|--- /dev/null' | uniq | grep null | wc -l | 09:07 | ||
stmuk_ | anyway my point was that p6doc contains a large number of .pod6 files and is likely to have a large number added | 09:09 | |
maybe an external MANIFEST file would be better? | 09:10 | ||
lizmat | commute& | 09:11 | |
nine | stmuk_: that would need updating, too? | 09:18 | |
stmuk_ | true | 09:20 | |
anyway quickly clicking through modules.perl6.org suggests most people don't use Build.pm and its mostly used to check presence of libfoo.so or .ddl so p6doc is probably a special case | 09:22 | ||
and most aren't using .pod6 but markdown anyway | 09:34 | ||
Zoffix | m: my $t = BEGIN now; sub infix:<ā„> ($,$) {}; sub infix:<ā„ā„> ($,$) {}; sub infix:<ā„ā„ā„> ($,$) {}; sub infix:<ā„ā„ā„ā„> ($,$) {}; sub infix:<ā„ā„ā„ā„ā„> ($,$) {}; say now - $t | 10:23 | |
camelia | rakudo-moar f2df2c: OUTPUTĀ«1.9912729ā¤Ā» | ||
Zoffix | nine, I'm unsure why the Color ops gave you that result... custom ops still seem slow, and I recall people telling me they won't ever be fast because we have to mutate the grammar for them | ||
nine | Zoffix: is it possible that precomp helps there? | 10:25 | |
Zoffix | Ohhh | 10:26 | |
Yeah, that's probably it. | |||
(they also are now fast on my box). nine++ | |||
dalek | p: 7a3bbc1 | (Pawel Murias)++ | tools/build/ (2 files): [js] Add a .nqp suffix on a intermediate build target. |
||
p: 1b70b2a | (Pawel Murias)++ | src/vm/js/HLL/Backend.nqp: [js] Fix the missing v8-profiler error message. |
|||
p: 84c5f40 | (Pawel Murias)++ | tools/build/ (2 files): [js] Fix typo. |
|||
p: 8c76bca | (Pawel Murias)++ | / (8 files): [js] Build a nqp-js-on-js package rather then stuffing stuff into node_modules. |
|||
Zoffix | Used to be 20 seconds, according to the module docs :) Now just fraction of a second | 10:27 | |
Zoffix passes around a round of ++ | |||
gfldex | m: enum E(<a b c>); dd E.keys; | 12:19 | |
camelia | rakudo-moar f2df2c: OUTPUTĀ«()ā¤Ā» | ||
gfldex | that feels wrong | ||
jnthn | m: enum E(<a b c>); dd E.enums.keys | 12:22 | |
camelia | rakudo-moar f2df2c: OUTPUTĀ«("a", "c", "b").Seqā¤Ā» | ||
gfldex | m: enum E(<a b c>); dd E::.keys; | 12:25 | |
camelia | rakudo-moar f2df2c: OUTPUTĀ«("a", "c", "b").Seqā¤Ā» | ||
gfldex | m: enum E(<a b c>); dd E::.values; | 12:26 | |
camelia | rakudo-moar f2df2c: OUTPUTĀ«(E::a, E::c, E::b).Seqā¤Ā» | ||
gfldex | that's what I would suspect .keys to default to | ||
jnthn | Would break the ".keys on a type object returns the empty list" consistency we have now, though | 12:29 | |
gfldex | enums are special in that they are always type objects and never turn into an instance | 12:30 | |
jnthn | uhh | 12:31 | |
Enum values are instances of the enum type | |||
gfldex | m: enum E(<a b c>); dd E ~~ Enumeration; | ||
camelia | rakudo-moar f2df2c: OUTPUTĀ«Bool::Falseā¤Ā» | ||
jnthn | m: enum E <a b c>; say a.WHAT | ||
camelia | rakudo-moar f2df2c: OUTPUTĀ«(E)ā¤Ā» | ||
gfldex | and that looks buggy | ||
jnthn | m: enum E <a b c>; say a ~~ Enumeration | ||
camelia | rakudo-moar f2df2c: OUTPUTĀ«Falseā¤Ā» | ||
jnthn | Consistent at least... | 12:32 | |
m: enum E <a b c>; say a.^roles | |||
camelia | rakudo-moar f2df2c: OUTPUTĀ«Method 'roles' not found for invocant of class 'Perl6::Metamodel::EnumHOW'ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā» | ||
gfldex | how do I tell that a type object is an enum with Rakudo? | ||
jnthn | Oh, same as you tell if a class is a class etc: match against hte meta-type | ||
m: enum E < a b c >; say E.HOW ~~ Metamodel::EnumHOW | |||
camelia | rakudo-moar f2df2c: OUTPUTĀ«Trueā¤Ā» | ||
gfldex | ~~ Enumeration looks correcter :) | 12:33 | |
jnthn | Why? There's no ~~ Class or ~~ Role or ~~ Subset. | 12:34 | |
That's just confusing space and meta-space. | |||
timotimo | don't drop your pins on my territory! | 12:36 | |
moritz | I never quite understood what role Enumeration played anyway | 12:37 | |
jnthn | moritz: Place to shove common methods that an enumeration type has, really | ||
moritz | jnthn: then I don't understand why the enum type type-checks false against Enumeration | 12:38 | |
jnthn: for example GrammarHOW adds Grammar as a default parent class; I'd expect a similar mechanism for GrammarHOW | |||
but it seems that instead Perl6::Action calls trait_mod:<does> to fudge in Enumeration | 12:39 | ||
jnthn | moritz: Yeah, we fudge it in at the moment. It's a kind of "do we really want to do it this way?" hedge :) | ||
timotimo | you mean EnumHOW :) | ||
moritz | yes | 12:40 | |
moritz ConfusedHOW | |||
jnthn | I don't believe S12 or any of the design docs mention an Enumeration role | ||
OTOH, S12's enums design has always been kinda a wish list of things enums should do rather than a model for how they should be implemented. Granted it's better now than it has been at times in the past... :) | 12:41 | ||
gfldex | m: enum E(<a b c>); sub f($e where * ~~ Metamodel::EnumHOW){ say 'oi' }; f E | ||
camelia | rakudo-moar f2df2c: OUTPUTĀ«Constraint type check failed for parameter '$e'ā¤ in sub f at <tmp> line 1ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā» | ||
jnthn | If we decide we're keeping it done with an Enumeration role then we should make it answer True there and make .^roles work, anyways. | ||
where .HOW ~~ | |||
gfldex | m: enum E(<a b c>); sub f(Metamodel::EnumHOW Ā§e){ say 'oi' }; f E | 12:42 | |
camelia | rakudo-moar f2df2c: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Malformed parameterā¤at <tmp>:1ā¤------> num E(<a b c>); sub f(Metamodel::EnumHOWā Ā§e){ say 'oi' }; f Eā¤ expecting any of:ā¤ constraintā¤ formal parameterā¤Ā» | ||
gfldex | m: enum E(<a b c>); sub f(Metamodel::EnumHOW $e){ say 'oi' }; f E | ||
camelia | rakudo-moar f2df2c: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Calling f(E) will never work with declared signature (Perl6::Metamodel::EnumHOW $e)ā¤at <tmp>:1ā¤------> b f(Metamodel::EnumHOW $e){ say 'oi' }; āf Eā¤Ā» | ||
gfldex | m: enum E(<a b c>); sub f($e where *.HOW ~~ Metamodel::EnumHOW){ say 'oi' }; f E | ||
camelia | rakudo-moar f2df2c: OUTPUTĀ«Constraint type check failed for parameter '$e'ā¤ in sub f at <tmp> line 1ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā» | ||
gfldex | m: enum E(<a b c>); sub f($e where .HOW ~~ Metamodel::EnumHOW){ say 'oi' }; f E | ||
camelia | rakudo-moar f2df2c: OUTPUTĀ«oiā¤Ā» | ||
gfldex | it's one of those "you need to know that to guess it" things (also ENODOC) | 12:43 | |
all I wanted to do was to write a short blog post but instead I learned new things :( | 12:44 | ||
usecase in case you wonder: gist.github.com/ede35a3da3f2c0cb51...78f2efea7b | 12:45 | ||
dalek | kudo/nom: 76a86d4 | MasterDuke17++ | src/core/Exception.pm: Fix RT #118607 Give the same suggestion for a sub redeclaration as for a method. |
13:16 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=118607 | ||
dalek | kudo/nom: 8e5a1aa | MasterDuke17++ | src/core/Exception.pm: Make sure message is returned when $.what is not a routine |
||
kudo/nom: 5dba970 | (Zoffix Znet)++ | src/core/Exception.pm: Merge pull request #854 from MasterDuke17/RT118607 216e3aa | (Brock Wilcox)++ | src/Perl6/Compiler.nqp: Remove legacy fallback repl methods |
|||
kudo/nom: 1d2351f | (Brock Wilcox)++ | src/core/REPL.pm: Extract toplevel control flag check for consistency |
|||
kudo/nom: 68443fe | (Zoffix Znet)++ | src/ (2 files): Merge pull request #853 from awwaiid/repl-cleanup REPL Cleanup |
|||
travis-ci | Rakudo build passed. Zoffix Znet 'Merge pull request #854 from MasterDuke17/RT118607 | 14:50 | |
travis-ci.org/rakudo/rakudo/builds/156218564 github.com/rakudo/rakudo/compare/f...ba970cadb9 | |||
MetaZoffix | IMO we should have some sort of "policy" for RFC tickets; specifically, what would be the criteria for closing them when the proposed feature has NOT been implemented. There are 55 RFCs right now and I see some going back to 2009 perl6.fail/t/RFC | 15:50 | |
I like Mojolicious's way, where users are actively reminded to give feedback on RFCs and if none happens the RFC is closed simply due to lack of interest. | 15:51 | ||
mst | "closed without prejudice" is a good approach, I think | 15:54 | |
Mojo is excellent at the 'closed' part and variable on the rest | |||
but I can hardly claim superiority on the front of 'level of cranky' so ;) | |||
[Coke] | I am strongly opposed to closing tickets because they're old and we haven't commented on them. | 15:56 | |
might work for a business product, but in our case, it's likely that none of our volunteers have ever reviewed it. | |||
MetaZoffix | [Coke]: but what if they have? At which point can an RFC be closed? | 15:58 | |
[Coke] | if the dev team says "nope, ain't doing it" | ||
or "yes, we did it." | |||
MetaZoffix | What's a "team" in that sense? | ||
JimmyZ | who commit the most core code | 15:59 | |
:P | |||
[Coke] | are you asking who the dev team is, or which subset of the dev team is sufficient to decide? | ||
MetaZoffix | [Coke]: how many dev team members are sufficient for a decision that an RFC ticket can be closed. | 16:00 | |
nine | Usually decisions are made by whoever feels confident enough to make one. | ||
[Coke] | because those are both great questions. Is it a language decision? then @LARRY should be involved. is it an implementation detail ? maybe different people. | ||
MetaZoffix | And I have a concrete example that I considered for an hour and wrote my feedback that is a -1 vote: rt.perl.org/Ticket/Display.html?id=129131 | ||
[Coke] | MetaZoffix: I'm not making that decision. | ||
MetaZoffix | Who are @LARRY? I know there's Ti mToady and pm ichaud. Anyone else? | 16:01 | |
[Coke] | (about what's the minimum) | 16:02 | |
as for your ticket, which is so new I had not seen it until you mentioned it here, I agree with your notes. | |||
Is pmichaud still on the list? Ok. | |||
MetaZoffix | ĀÆ\_(ć)_/ĀÆ | 16:03 | |
[Coke] | Damian might want to be on that list. | ||
maybe jnthn | |||
maybe a bunch of us. I dunno. This dev team hasn't historically worked in a hierarchy "THIS IS HOW THINGS ARE DONE" way. | 16:04 | ||
s/chy/chical/ | |||
MetaZoffix | heh | ||
nine | MetaZoffix: FWIW I'd +1 rejecting the ticket | ||
[Coke] | Zoffix: you didn't cc the mailing list on your well thought out reply on 129131 | 16:05 | |
so I doubt any of the dev team would have even known about it if you hadn't dropped the link here. | |||
MetaZoffix | [Coke]: I think I did, I just hit "Reply". I've replied and then joined IRC, so maybe it just hasn't propagated yet. | ||
[Coke] | no. it would say on the message if you had cc'd the list. | 16:06 | |
did you check the box? | |||
" | |||
Click to Toggle Cc of [email@hidden.address] | |||
you have to click that, or it's a reply just in the ticketing system. | |||
MetaZoffix | For me, it's pre-ticked, but it's not a Cc, but a Bcc: i.imgur.com/koYT9Ux.png | 16:07 | |
[Coke] | ... no. that's not ticketd. | ||
you have to click it. | |||
it's a link with a <li> in front of it. | |||
so when I said 'check the box' above, I mis-spoke, apologies. | 16:08 | ||
... | |||
oh, you're showing even higher above. | |||
MetaZoffix | Oh, down below... I thought the one on the top left box was enough | ||
Hm, now that you mention it, I don't think my replies ever show up on the mailing list, but I always assumed it was because it was detecting that it was *me* replying so it didn't send an email to me | |||
[Coke] | ... maybe? I have always had to click the box. | ||
*the link*( | 16:09 | ||
MetaZoffix | I'll be clicking the link from now on. | ||
[Coke] | I don't see anythign special about that ticket where I would have hope that the BCC worked. | ||
thanks for pointing that out though, I don't think I ever saw that actual checkbox! | 16:16 | ||
new roast ticket: github.com/perl6/roast/issues/147 | 16:23 | ||
[Coke] looks forward to zoffix's ticket dashboard incorporating /spec /roast /nqp /MoarVM et al. | 16:24 | ||
er, etc. | |||
MetaZoffix | :) | 16:25 | |
timotimo | oh Rt you flaming pile of garbage :) | 16:27 | |
[Coke] | timotimo: serious alternates welcome at rt.perl.org/Ticket/Display.html?id=128520 | 16:28 | |
timotimo | i just mean the "click here to toggle bcc" thign | 16:37 | |
potentially that's something our admins hacked in for us? | |||
other than this little cosmetic thing, i have no "proper"/founded criticism | 16:40 | ||
hm. i got thrown onto the "front page"/"dashboard"/"whatever" after i used "log in as another user" from the ticket view | |||
that was annoying. i think it should have led me straight back to the ticket i was viewing | |||
but i don't have to login very often, so i don't have to do this dance much | 16:41 | ||
lizmat waves from Ljubljana | 16:46 | ||
dalek | ast: 44779ac | MasterDuke17++ | S04-declarations/multiple.t: Test for RT #118607 Requires Rakudo PR #854 (github.com/rakudo/rakudo/pull/854). |
17:06 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=118607 | ||
dalek | roast: 27f56c1 | MasterDuke17++ | S04-declarations/multiple.t: | ||
roast: Another test for the fix for RT #118607 | |||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=118607 | ||
dalek | roast: | ||
MasterDuke | r: say (0 => 1, 1 => 0).max(:by(*.value)) | 18:18 | |
camelia | rakudo-moar 68443f, rakudo-jvm cd19db: OUTPUTĀ«1 => 0ā¤Ā» | ||
MasterDuke | r: say (0 => 1, 1 => 0).max(*.value) | ||
camelia | rakudo-moar 68443f, rakudo-jvm cd19db: OUTPUTĀ«0 => 1ā¤Ā» | ||
MasterDuke | r: say List.can("max")[0].signature.perl | 18:20 | |
camelia | rakudo-moar 68443f, rakudo-jvm cd19db: OUTPUTĀ«:($: | is raw)ā¤Ā» | ||
MasterDuke | i was looking at RT #115758, but it's pretty old | ||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=115758 | ||
MasterDuke | r: say max :by(*.value), { 0 => 1, 1 => 0 } | 18:21 | |
camelia | rakudo-moar 68443f, rakudo-jvm cd19db: OUTPUTĀ«0 => 1ā¤Ā» | ||
MasterDuke | r: say (0 => 1, 1 => 0).max(:foo(*.value)) | 18:25 | |
camelia | rakudo-moar 68443f, rakudo-jvm cd19db: OUTPUTĀ«1 => 0ā¤Ā» | ||
MasterDuke | r: say max :foo(*.value), { 0 => 1, 1 => 0 } | ||
camelia | rakudo-jvm cd19db: OUTPUTĀ«Unexpected named argument 'foo' passedā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā» | ||
..rakudo-moar 68443f: OUTPUTĀ«Unexpected named parameter 'foo' passedā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā» | |||
MasterDuke | huh, i also just noticed that jvm said 'named argument' and moar said 'name parameter' | 18:26 | |
git grep -i 'named parameter' | wc -l # 17 | 18:31 | ||
git grep -i 'named argument' | wc -l # 18 | |||
does anybody care one way or the other? i feel the wording should be the same between the backends for the same error, but what about making them all 'argument' or all 'parameter'? | 18:40 | ||
nine | MasterDuke: design.perl6.org/S99.html#parameter | 18:46 | |
MasterDuke | nine: if i'm interpreting that correctly, 'parameters' are part of a signature, and 'arguments' are what a block/sub/etc are called with? | 18:50 | |
MetaZoffix | yeah | ||
MasterDuke | in that case, i'd say the jvm error is incorrectly worded | 18:51 | |
nine | yes | ||
dalek | kudo/raccoon: a54cb0f | niner++ | lib/Distribution/Builder.pm: fixup "First steps towards a declarative build system for modules" |
18:58 | |
kudo/raccoon: defd764 | niner++ | / (4 files): Support different build systems Rename Distribution::Builder to Distribution::Builder::MakeFromJSON and add Distribution::Builder as a role for build systems. The optional "builder" key in the META data is used to select the build system. |
|||
MetaZoffix | I guess it can be read both ways... To me 'argument' looks more correct, since the error refers to the place where I'm passing some arguments to a thing | 18:59 | |
MasterDuke | oops, that's what i meant | 19:00 | |
read them backwards | |||
masak, moritz: do you think RT #115758 is still valid? | 19:55 | ||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=115758 | ||
[Coke] | bah. have perl6 code running at $dayjob that just gave me: | 20:05 | |
Use of uninitialized value of type Any in string context | |||
Any of .^name, .perl, .gist, or .say can stringify undefined things, if needed. in method dispatch:<.?> at /usr/share/perl6/runtime/CORE.setting.moarvm line 1 | |||
timotimo | uh, that's not a good backtrace | 20:09 | |
moritz | try running with -ll-exception | 20:11 | |
[Coke] | thought I'd need ll exception to get a trace that mentioned the CORE. | 20:12 | |
masak | MasterDuke: yes, I think it's still valid. unless something has happened that's outside of the scope of what I'm reading in that ticket. but I know of no such thing. | 20:14 | |
dalek | kudo/nom: b1c444f | TimToady++ | src/core/metaops.pm: Calling unary on reduce needs arity, not count For a reduction with a single argument, we want to look to see if the operator in question has a unary interpretation, and call that. Unfortunately, there are functions that can handle a unary but whose count is larger than 1, so would not be called. Now we check .arity instead, which can still be 1 (or 0) for such functions. (We don't test for exactly 1 since most functions with .arity of 0 have a .count greater than 0, so allow one arg.) |
22:29 | |
timotimo | oh, is that for, like, reduce with ++? | 22:31 | |
i could imagine using .succ with produce could be a bit sugary-er than the ... operator | 22:32 | ||
TimToady | well, ++ is not an infix, and reduce only works on infixes | 22:39 | |
yoleaux2 | 23 Aug 2016 19:03Z <[Coke]> TimToady: newish sink ticket at RT #128692 | ||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128692 | ||
TimToady | but if an infix has a degenerate case with 1 argument, it can now return what the 1-arg form produces, instead of always returning the 1 argument | 22:40 | |
[Z] still doesn't invert a single list, however, and might never, given it conflicts with one-arg semantics | 22:41 | ||
timotimo | oh | ||
TimToady | trouble is, zip only happens to work as inversion if the arrays in question are not ragged | 22:42 | |
timotimo | amusingly enough, it still works if the arrays in question are tattered | 22:43 |