»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'p6: say 3;' or /msg camelia p6: ... | irclog: irc.perl6.org or colabti.org/irclogger/irclogger_log/perl6 | UTF-8 is our friend! 🦋
Set by Zoffix on 25 July 2018.
b2gills .tell hankache `abs` isn't the only one it catches, but it is specific to a few functions github.com/rakudo/rakudo/blob/d596...3558-L3565 00:16
yoleaux b2gills: I'll pass your message to hankache.
02:30 CDT <hankache> b2gills: thanks mate. But shouldn't the parser catch all occurrences? Why did it only catch abs?
masak oh, right! Perl 5 allows me to run a program where not all subs being used have been declared... 05:12
I think I'm turning into a static correctness enthusiast as I grow older 05:13
"do you want your program to signal problems up-front, or make a 'best effort' of it and surely fail later, at runtime" -- gee, I dunno, let me think 05:14
jmerelo releasable6: status 05:23
yoleaux 17 Sep 2018 22:05Z <AlexDaniel> jmerelo: what is up with this rejectionism lately in perl6/doc? :)
releasable6 jmerelo, Next release will happen when it's ready. 0 blockers. 112 out of 125 commits logged
jmerelo, Details: gist.github.com/dbf946d24c60881552...f9cdc88d56
masak "rejectionism"? 05:24
jmerelo .tell AlexDaniel what do you mean? 05:25
yoleaux jmerelo: I'll pass your message to AlexDaniel.
masak I'd expect there to be goals and a "definition of done", not wilful rejecting of contributions. phrasing that as "rejectionism" feels less than constructive. 05:27
but I might be missing some vital context here
jmerelo masak: I closed a couple of issues which weren't really issues. He opened them back. This is one of them github.com/perl6/doc/issues/2315
masak ok. hm. 05:29
those type graphs are both (a) an impressive use of (I assume) graphviz, (b) usually massive overshare and a bit scary -- Real being an example 05:30
jmerelo masak: also, just available by clicking on a helpful link and generated automatically. Placed exactly where they should be. 05:31
masak yep, agreed.
jmerelo masak: This is the other: github.com/perl6/doc/issues/2314 05:31
masak I can see the argument that whoever has made those type graphs -- and I mean absolutely no offense technology-wise -- is very keen on "showing everything", perhaps at the expense of clarity 05:31
Edward Tufte would be turning in his grave, if you know what I mean 05:32
but yes, it's *hard* to strike a balance there
jmerelo masak: I'm a fan of Edward Tufte. But then, the OP talks about "list the subsets of Real". The "subsets" of Real are listed there. I suggested this github.com/perl6/doc/issues/2315#i...-421989200 to the tune of if there's an issue with all graphs, open an issue about that. 05:33
masak reading the second issue 05:34
jmerelo masak: the issue is clearly *not* about the "subsets" of Real. That's why I closed it.
masak this seems to be partly a case of a newbie who wants to help but doesn't quite have the vocab/routines for it
"Because it is a routine." -- I sympathize strongly with this one, even having understood that `dd` is not part of the spec. the querent is operating under fairly sane assumptions. 05:36
jmerelo masak: I don't know. There's a lot of stuff in Rakudo that is not part of Perl 6. Plus dd is documented (in "program", which is clearly not part of the language). You could argue it could be indexed, but then perl 6 doc is perl 6 doc. 05:37
masak jmerelo: sorry, I'm not so much arguing against you, as seeing the querent's point of view :)
jmerelo: you may well have a point that `dd` doesn't strictly belong 05:38
then again, I could see the argument for having *something* there, even if it's "`dd` is not part of the spec, but Rakudo implements it... see [that other page] for more info" 05:39
jmerelo masak: plus *it's indexed*. It's just not in that URL made out of thin air. Just type "dd" in the slot above.
masak mm. I don't have a horse in this race. I acknowledge that you can find `dd` in some ways in the docs.
AlexDaniel I reopened 2, 3rd was reopened by somebody else 05:40
yoleaux 05:25Z <jmerelo> AlexDaniel: what do you mean?
AlexDaniel generally it'd help if we focused on what made the user create a ticket
instead of nitpicking on what they ended up asking 05:41
masak I tend to do a little bit of both
sometimes I rename an issue to better state its intended purpose
sometimes I close it and open a new, more specific/precise one
heh -- I'm writing some Perl 5. I had forgotten the feeling of writing a "data pipeline" such as split-grep-join *backwards", because only the function forms are available, not the method forms 05:46
no wonder people tend to take to the method forms in Perl 6; you can write the steps in textual order 05:47
jmerelo AlexDaniel: it's impossible to get into the minds of the OP. What they ended up asking is all we've got. What made the user create the ticket, as masak says, might be a different thing altogether. You address that, you'll make everyone unhappy, including the OP 05:49
masak not really what I said, but OK 05:50
jmerelo masak: sorry, I tried to channel this one "sometimes I close it and open a new, more specific/precise one".
masak right
because I could *see* the querents intent, and can create a better issue for it 05:51
this reminds me of something mjd wrote about x/y problems. basically that you're a bit screwed no matter how you help the person
jmerelo Thing is, if the issue is a general, site-wide, problem, that's the thing we have to address. And also the thing might have been addressed already, that's why it's closed.
masak there will always be people criticizing you and telling you you should've done it the other way
jmerelo masak: so true. 05:52
jmerelo masak: you got a link to that talk? 05:54
masak ISTR it being a blog post 06:00
or an email
masak jmerelo: this is slightly related, but I have a feeling there was something else that was even more apt: perl.plover.com/yak/12views/sample...html#sl-33 06:04
jmerelo masak: thanks. 06:05
tyil masak: I personally really like using the method forms, as it reads much nicer 06:42
I can just read from left-to-right about what I'm doing to my data
El_Che masak: you're are destroying our dynamic lang propaganda! 06:45
masak El_Che: I see a false dichotomy between "dynamic/late binding" and "static/early feedback" 06:46
El_Che masak: you missed the word propaganda :)
masak yes 06:47
I feel it's a pity, is all
this is my career. I want the best possible language for the task, not one largely determined by tribalism and propaganda
nycnyc123 join 06:51
masak nycnyc123: you have successfully joined. state your purpose and desiderata. 06:52
masak .oO( split-grep-join ) 06:52
buggable New CPAN upload: Sparky-Plugin-Notify-Telegram-0.0.2.tar.gz by SPIGELL modules.perl6.org/dist/Sparky::Plug...an:SPIGELL 08:14
Zoffix My two cents on the docs Issues discussion: we should all be working towards a common goal of making the language better instead of bean-counting the amount of Issues that get closed or viewing the Issue reportee as some sort of a customer. On R#2315 there's a comment "If you want to open another different ticket saying "Repeat in every Role all the known classes that mix it in, or include in every class all 09:03
known classes that subclass it" please do so by all means.". What's with this wanting to open another ticket? They didn't come to pay a phone bill. If there's a problem with the docs site it should be fixed. If there's a problem with composition of the current Issue, split it up however makes solving the problem better. Don't come at the user like they owe us something.
Also, that user is like the quintessential noob. I'd be listening to what their report as problematic in the docs with more than the usual amount of ears. 09:05
s/their/they/;
masak vibes with agreement
masak yes, there is a way to approach issues of this kind such that the end result is "greater than the parts" 09:06
which sometimes means not standing on ceremony
timotimo you can even rename the issue on github 09:30
so if "the title of the issue is too specific" is the problem, just make it more general
moritz FYI I'm rebooting www.p6c.org; it was stuck, and perl6.org down 11:23
randc How would I go about using prompt() to get some user input, but pre-filling what I thing the user will ty to stdin.... like printing to stdin without a newline so that the user can modify before predding enter... 12:33
think the user will type* 12:34
pressing*
El_Che randc: I would show a default 12:35
editing on a prompt is often annoying, imho
timotimo you can print out a \r which will put the cursor back at the start, then re-write the beginning of the prompt up to the point where the cursor is supposed to be 12:36
however
if the default is "foo" and the user now types a "b", it'll become "boo" in the output
randc but for this program it is very common to just need to change the date in a long project name... so I think it would be nice... 99% of the time the user copies and pastes the previous setting and just changes the date, so I want to pre fill it... 12:37
El_Che I see
timotimo you'll most probably want some kind of commandline UI library to help you with that 12:38
ncurses or Terminal::Print come to mind
i haven't worked with either, really
tyil would something like linenoise be usable, not sure if you can prefill it with a value 12:39
then you'd get regular hotkeys like ^a to go to start of string as well
which would be nice to have in this context, I think
Hotkeys goes to start of string 12:41
tyil :I
randc Ok thanks. I will look into those. I was attempting to do something like $*IN.write.... but that was wrong...
timotimo right, linenoise or readline could also help 12:42
araraloren o/ 12:59
Geth doc: df0b71d8d6 | (Zoffix Znet)++ | doc/Type/Promise.pod6
[6.d] Document new behaviour of `start` in sink context

POV: github.com/rakudo/rakudo/commit/6ee5f75778 Propspec: github.com/perl6/roast/commit/7a426fb4a3 Per 6.d-prep: github.com/perl6/6.d-prep/blob/69a...or-handler		 15:11
synopsebot Link: doc.perl6.org/type/Promise
jmerelo Hi, AlexDaniel 15:25
AlexDaniel o/ 15:26
jmerelo: fwiw colabti.org/irclogger/irclogger_log...09-21#l229
jmerelo AlexDaniel, Zoffix it's a big if, "if there's a problem with the docs site". I mean, issues are issues. We close them if they are repeated, or if what is being asked can't or won't be done for some reason. 15:29
FWIW, I didn't simply close the issue. I addressed it, checked what was being said, and explained why I closed them. Which is exactly the same that I have done in other cases, noob or not. Read, check, address, and close them either by changing stuff or by explaining why I close it. 15:32
Also, we can't simply special-case some document just because someone requests for it. If someone wants a specific URL to work, we can't do that. We can say: OK, we are not doing this in this case, but a different issue is doing it always. Enphasis on "a different issue" 15:33
jmerelo If someone wants some specific information added to some type, we can't do that. Even more so if that information is already there, a click away if you bother to click on that. It's a different issue "we want that information repeated in every single page". It simply *is* a different issue. 15:34
Someone wants that to be done, it's added to the 178 issues already opened and probably will get a "wishlist" label on top of that. 15:35
AlexDaniel I look at one of these tickets and I see problems pouring out like crazy: routine is not a routine, type graphs too big, search returns a bunch of shit for ‘dd’ and you can't easily see the right one, type graphs not visible right away (depending on the amount of text and methods documented on the page), rakudo-specific routine is documented when we don't do that (or maybe we do that but nowhere it says why we do that for that
particular case), etc.
and I believe all of these contributed to why someone spent their time on creating a ticket 15:36
jmerelo AlexDaniel: none of which are *the* issue. They are other, different issues.
AlexDaniel my point is that we can adjust the ticket as needed to redirect the effort to some right place 15:37
jmerelo AlexDaniel: my point is that you can, to a certain extent.
AlexDaniel like link to existing tickets, create new ones for things that are separate, change the title of the ticket for something else…
jmerelo AlexDaniel: we do that all the time. Subjects are slightly changed. But an issue with dd can't become an issue with all rakudo-specific routines. It's a different issue. 15:38
AlexDaniel jmerelo: why not
jmerelo AlexDaniel: first, because you have not simply done that. You want to reorient the issue, just do it on the issue. The issues, as it is, is addressed. Different issues, they are not, but it's better to open a new one than reuse it. 15:39
It's simply practical. A new, fresh issue, will have different participants, different opinions.
jmerelo I mean, what's the big deal? GitHub does not charge by issue created. 15:40
Zoffix jmerelo: well, that's fine. Just create an issue. 15:40
AlexDaniel I wouldn't mind if you created a new ticket and closed the original one once it had enough off-topic comments, or whatever
Zoffix +1 15:41
jmerelo AlexDaniel: I wouldn't mind if anyone else did. I closed those tickets, did so for a reason, which I explained. Whoever opened it back, or the OP, are probably a much better choice for doing so. 15:42
AlexDaniel I disagree that a ticket should be closed before a new ticket was created 15:42
jmerelo Particularly, I don't have any issue with graphs size, or with listing or not the subclasses. 15:42
Zoffix You're hardly the target audience of the site. 15:43
jmerelo AlexDaniel: a ticket is closed when it's been addressed, or if the person who addresses it (that would be me, I guess) understands that nothing else can be done to address it. 15:44
jmerelo Zoffix: that's not the point. The issue should be created, in general, by whoever has an issue. 15:44
Zoffix Why?
jmerelo Zoffix: among other things, getting a notification that something is done about it or requesting original clarifications. 15:45
Zoffix I mean the issue *was* created by someone who had an issue. You closed it in a mildly rude manner.
jmerelo Zoffix: I close issues almost every day. I don't know which issue you mean.
Zoffix And when you tell a user who barely grasps (a) the language; (b) organization of the site; (c) our polices and the way we do things—that they can create another issue if they want but you're closing this one, I don't think they have enough reason or motivation to do anything after that point. 15:46
Zoffix jmerelo: as one example, D#2315 15:47
synopsebot D#2315 [open]: github.com/perl6/doc/issues/2315 RFE: please list the subsets for Real
Zoffix The first reply to the user reads to my eyes as "you're doing it wrong" and the immediate closure after that suggests it's not up for discussion 15:48
AlexDaniel also I insist that the user had good intent, in case anyone even doubts it
Zoffix And I guess the point is: what did we achieve by closing that issue so soon?
For example, in reply there's a "Type graphs are always on the bottom of the page, so that they don't get in the way of the actual documentation." 15:50
That can be true. And OP's comment that they're hard to reach can also be true
AlexDaniel no we didn't, in fact the user is perhaps less likely to report other issues in the future
Zoffix What's our COMMON goal here? To make docs better: so we could phrase it: "They're that way so they don't get in the way. Is there a good way to include them at the top, while still ensuring they don't get in the way"?
jmerelo Zoffix: right. The OP also says "please list the subsets for Real". If he had an issue with graph positioning, I guess that's what the OP would have said. He's saying that they are blurry (which they are not) 15:51
Zoffix So instead of rushing to close the issue to get the "total" count below some arbitrary goal, we can leave the issue open and involve the reporter in the process and perhaps achieve some option that solves both the problems that lead to the current arrangement and the OP's problem
Zoffix jmerelo: that's a good example of a problem with the site. Saying "which they are not" is not helpful to the common goal of having a better site. We clearly have a user who says they're blury. Why do they think so? Is it a problem with their browser/device or did we fail to consider some system set up and the graphs come out blury for some users. If they get unblurred when you click on them, then how can we 15:54
make it more obvious to users that they can click on it
jmerelo Zoffix: an option that might leave everyone involved unhappy. The OP because they have nothing to do with the original post (listing subsets)
Zoffix: once again, that is not the OP. If I see an issue saying graphs are blurry, I'll check the blurriness in several devices, and eventually, if that's the case, will try to address it. 15:55
Zoffix: I already did address the size of the chart, together with AlexDaniel. Not a big deal to work with anything.
AlexDaniel looks at docs.perl6.org/type/Metamodel::Met...Type_Graph 15:56
jmerelo Zoffix: We look at it from the point of view of devs, as a bug. You report a bug ("blurriness of a graph"). Well, it's a vector graph. It's difficult that it's blurry, but it might be in some devices (small ones?). So you ask for additional information
AlexDaniel I guess that's better than camo.githubusercontent.com/603b8bf...742e706e67 15:57
jmerelo: additional information, yes. That's starting to move into the right direction :)
Zoffix jmerelo: that sounds like you would ignore a problem with the site just because whoever reported it did not structure their report to your liking. And my point is that we shouldn't ignore it and we shouldn't rely on reportees to fix their reports 15:58
jmerelo Zoffix: but that requires the OP actually reporting *that* bug. Not "do *this* particular thing because *that* is wrong". Because that means that the particular thing is what needs to be solved, not *that* which is wrong. And if it happens if that it's difficult to reproduce that wrongness...
Summertime the obvious solution is to switch the site to gopher protocol
geekosaur for soem types, thecorrect answer is likely to realize that they're never going to work as graphs and suggest alternatives 15:59
jmerelo Zoffix: you are telling the only person who actually bothered to address the issue that he's ignoring it. It's not a matter of structure stuff to my liking (BTW, we created issue templates for a reason, and that reason is to understand clearly what's the intention of the OP) it's a matter of understanding what's wrong and try to fix it.
geekosaur like for Mu, you probably want to sugest looking at te graph fro a particular subclas to see where ti fits in 16:00
because int he other direction, it wil be literally everything, and there is no way to present that sanely except Mu --> {cloud}
AlexDaniel fwiw I'd have no time at all during this weekend (for heated discussions especially, but I have time to do the release), and I'd be offline for most of the time. Please ping AlexDaniel` once the moar release is ready, or if there's anything else release related
AlexDaniel runs away
jmerelo geekosaur: you can click on this docs.perl6.org/images/type-graph-M...tainer.svg and get it full size 16:01
jmerelo geekosaur: while I could agree in principle that there should be better way of listing subclasses, superclasses, and whatnots, still converting the OP to that might leave everyone unhappy 16:02
geekosaur: the OP because that's not what he wanted. He wanted something for that class, not the other, which he might not care. And the rest of the people because it's reopening an issue that was solved a long time ago, to everyone joy, using the graph. 16:04
Zoffix jmerelo: I wouldn't consider closing the issue with a brusque reply as "addressing the issue"
jmerelo: from here, it feels to me like we're closing the issues for the sake of closing them, rather than having the issues be a tool for improving the site. 16:05
Zoffix So in the end of the month someone could tweet "Look! We addressed 1000 docs issues this month!" 16:05
jmerelo Zoffix: right. Addressing is doing all the work checking what's wrong, if there's actually a problem, composing an answer as articulate as possible, and, only then, closing it.
jmerelo Zoffix: and I feel we are not dealing with the issue, but going in a meta-level that is not really addressing the issue. 16:06
Zoffix: In this case, subclasses of real need to be listed, because "Real is what is not complex" is not considered precise enough. But it's the most precise definition you can come up with. The Real role is exactly that. 16:07
Let's thing about a number. Is it complex? Yes. Then it is not Real. No. Then it is! 16:08
jmerelo A definition by exclusion is much more precise than listing, *by hand* all *known* subclasses. 16:08
Zoffix jmerelo: in a way, yes, we are going in a meta-level: if the user says the graph should be at the top, it doesn't mean we have an A/B scenario where we can only make the graph at the top or only leave it at the bottom. If we go that way, we deem that the graph at the bottom is because we don't want it to get in the way and that's what the user was told and then the issue was closed. But by going to meta-level 16:09
of saying: how can we present the type graph better, the A/B now become two different user experiences we need to consider: (1) graph gets in the way; (2) graph is burried and unreachable.
And start to look for a solution that could address both. 16:10
jmerelo Zoffix: you are getting into the mind of the OP. The issue says, exactly: "Would you consider adding to the top of the page: "Real" is a "Role" that includes the following classes: FatRat, Rat, Rational, Duration, Instant, Int, PromizeStatus, Bool, Automicint, Sinval, Order, InStr, NumStr, Num" 16:10
TimToady I love it when a plan starts coming toge...er...stops flying apart... 16:11
geekosaur there's also floating TOC 16:12
jmerelo Zoffix: that is what he wants, nothing else; look at the title too. It's also a request for enhancement. So would I consider adding that to the top of the page? Well, no. Saying "Real is not Complex" is shorter, more precise and generally better. Substituting that by "known" classes is by no means an enhancement.
Zoffix Yes! I precisely get into the mind of the OP. I don't give a shit what the issue says exactly. I want to know what caused a person to think why they wanted to list all those clases at the top. Is that because they missed the type graph? Why did they miss it, should it be more obvious? Is that because the type graph doesn't present the information in a good order, what would be a better order?
geekosaur "genrally better" by whose defintion 16:13
Zoffix jmerelo: I don't think I think in terms of "what he wants" tho. You could say this user is a test file that evaluated the site and there are some `nok - ....` in the output :)
geekosaur now that I know whatthis is actually about, I think the request as such is reasonable. but might be better adressed by emphasizing role, with a link to the constituents/type graph 16:14
Summertime @ graph specifically, merits regardless collapsable graph section? or a graph with a [show more nodes] button? both would allow it to be smaller by default, and as a result, brought up in obviousness without taking more space
Zoffix generally better by the definition of fewer people having issues with it
El_Che wow, huge backlog
Zoffix jmerelo: i.e. I don't care what the user wants. I care about why they want that.
Zoffix g2g
geekosaur zoffix is right here. this is an origin of xy problems: user trying to make sense of what, by defintion since they're asking, doesn't make sese to them 16:15
and will therefore be making decisions based on incomplete or incorrect information
jmerelo Zoffix: again, meta. In general, I care about both. But I might find, in my own very little mind, different reasons. 16:16
TimToady what's really going on here is that it is impossible to make documentation that is good both for people who are good at abstractions and people who are...not so good at them 16:17
jmerelo geekosaur, zoffix: I very much encourage you to read all the coments. Please check out this one ". When I clicked on one of the members, I got another page as complicated as the one I was on."
geekosaur that particular one my comment already got disregarded, thanks 16:18
jmerelo geekosaur, zoffix: so let's get into his mind, and address the issue. Let's create an issue that says "All pages of the docs are too complicated"
El_Che There is also the issue of 100's open issues, certainly when they are related. It diffuclt for devs and writers zo address them efficiently. Also many users stay away from projects with too many open issues.
geekosaur "at what point do we have to decide whether or not to support people who don't learn/think the same way"
jmerelo geekosaur, zoffix: Let's continue with this: "What I would like to see is for you to start simple (like perldocs) and then work up to the developer level complicated stuff." 16:19
El_Che so there is balance to achieve there
geekosaur and you have again made your decision. I see no reason to discuss snce it comes down to discuss = agree with what has already been decided 16:20
jmerelo OK, let's open another issue for that. At the end of the day, it's really impossible to satisfy that issue. Not to mention that perl6 docs actually "start simple" (with /language stuff) and work as reference.
jmerelo TimToady++ 16:20
Let's go to another issue, which I opened (after seeing the problem in the perl6 list), and was closed after 14 comments: github.com/perl6/doc/issues/2303 16:22
We try to support everyone, we really try. 16:24
But sometimes, as TimToady says, it's just impossible. We can't explain every single feature of the language every single place it shows up. There's a part for that, the /language pages. Not the reference. 16:25
AlexDaniel “many users stay away from projects with too many open issues” 17:49
interesting, I stay away from projects that have too few open tickets
AlexDaniel interesting, opencart has 146 open issues 17:50
AlexDaniel did something change there? 17:51
it was a false impression then :) 17:52
[Coke] late to comment but I am fine with dd being documented as long as it is clear that it is rakudo specific. We talk a lot about other implementations but we don't have one yet, so I think a warning label is the easiest way to go here (this is kind of a 180 from my previous thoughts of moving rakudo specific items to a separate wiki)
zoffix++ for 17:53
zoffix++ for "My two cents on the docs Issues"
jmerelo [Coke]: It's documented and indexed, only not in that particular URL. It's not in that particular URL because it's not part of Perl 6. The documentation, accessible if you use "dd" in the search slot, states clearly that it's part of Rakudo, as well as examples and what it does. 17:55
[Coke] which ticket was the dd request on? 17:58
jmerelo: thanks for the clarification!
AlexDaniel D#2314 17:58
synopsebot D#2314 [open]: github.com/perl6/doc/issues/2314 RFE: dd in the docs
[Coke] waves from a different edge of NYS.
jmerelo [Coke]: Sure :-) 18:04
[Coke] added a note to the dd ticket pointing to D#1099 ; having a url like docs.perl6.org/search?q=dd I think would solve the problem. I actually have some time this weekend, I'll see if I can get something working. 18:05
synopsebot D#1099 [open]: github.com/perl6/doc/issues/1099 [search][site][wishlist] Add new top level search page
[Coke] wonders if 'make html' in doc will finish here before he has to go pick up his kid. 18:22
leont It seems my rakudobrew setup is b0rked :-/ 18:53
El_Che AlexDaniel`: true, both cases give a terrible impression 19:12
AlexDaniel`: the worst is, however, year-old ignored PR's like perl-ldap 19:13
geekosaur leont, it does that. rakudobrew is disrecommended for a reason 19:16
Xliff \o 19:17
Xliff If I have a sub like so: "sub a($a, $b, $c) { my @a = ($a, $b, $c); @a.say; }; " is there any way to shortcut the assignment to @a? I know that having a signature removes the use of @_, was just wondering if there was a way I could have a signature and still pull back the arguments as a list or an array. 19:19
timotimo sure, you can use destructuring/sub-signatures 19:19
Xliff Any examples?
timotimo m: sub a(@a ($a, $b, $c)) { say "scalars are $a $b and $c, array is @a[]"; }; a((1, 2, 3)) 19:20
camelia scalars are 1 2 and 3, array is 1 2 3
timotimo m: sub a(@a ($a, $b, $c)) { say "scalars are $a $b and $c, array is @a[]"; }; a((1, 2))
camelia Too few positionals passed to 'a'; expected 3 arguments but got 2 in sub-signature of parameter @a
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
timotimo you can use ? and *@ to make the number of entries that have to be in the list more lenient
Xliff Ah! Nice. 19:21
Still would like to leave the signature alone.
timotimo m: sub a($a, $b, $c) { my @a = MY::<$a $b $c>.values; say @a.perl }; a(1, 2, 3) 19:22
camelia [1, 2, 3]
timotimo isn't that much better!!!
oh, the values there is redundant 19:23
m: sub a($a, $b, $c) { my @a = MY::<$a $b $c>; say @a.perl }; a(1, 2, 3)
camelia [1, 2, 3]
thundergnat sub a ($a, $b, $c) { ($a, $b, $c) }; my $d = a(1,2,3); say $d; say $d.^name; 19:27
evalable6 (1 2 3)
List
thundergnat m: sub a ($a, $b, $c) { ($a, $b, $c) }; my $d = a(1,2,3); say $d; say $d.^name; 19:28
camelia (1 2 3)
List
thundergnat ^^ Xliff 19:29
Xliff thundergnat++ && timotimo++
thundergnat m: sub a ($a, $b, $c) { [$a, $b, $c] }; my $d = a(1,2,3); say $d; say $d.^name; # or if you really want an array 19:30
camelia [1 2 3]
Array
leont Is there any p6 equivalent to podcheck? 19:37
Zoffix leont: I'm 80% sure that's the perl6 compiler itself. If you make a POD error, your program won't compile. 19:58
m: say 2+2;␤=begin head␤ 19:59
camelia 5===SORRY!5=== Error while compiling <tmp>
Preceding context expects a term, but found infix = instead.
Did you make a mistake in Pod syntax?
at <tmp>:3
------> 3<BOL>7⏏5<EOL>
Zoffix m: say 2+2;␤=begin head␤=end head
camelia 4
leont Ah, it seems the errors I briefly saw were in Pod::To::Pager, and not Pod errors (I didn't see them long enough until I put a cat in between) 20:01
buggable New CPAN upload: Wkhtmltox-0.0.1.tar.gz by AZAWAWI cpan.metacpan.org/authors/id/A/AZ/...0.1.tar.gz 20:15
leont Is anyone here going to Strangeloop? 20:30
It sounds like a good place to talk about Perl6 20:31
rindolf leont: hi 21:05
rindolf leont: thanks again for github.com/Leont/getopt-long6 21:06
leont Just pushed a bunch of new features :-) 21:07
rindolf leont: thanks
leont: with tests?
leont Some
Not truly enough, but enough to know it's not completely broken
leont Writing documentation now. Planning to bump version after that. 21:12
rindolf leont: thanks 21:15
docs are good 21:16
leont Is there a good pod5 to pod6 tutorial? Or otherwise some examples of idiomatic pod6? 21:27
leont @tyil: it seems putting formatting in a heading makes Pod::To::Pager crash 21:33
lizmat leont: I guess opensource.com/article/18/9/signatures-perl-6 is too low level for you 21:41
(and the preceding articles)
ah.. you mean *pod* 21:42
sorry for the noise
lizmat I guess I'll put that on my list for the 5-6 articles 21:42
leont confused for a moment :-) 21:42
lizmat it's late :-) 21:45
El_Che isn't md the 21th century pod? /me ducks< 22:37
tyil leont: thanks for the notice, I'll look at it soon-ish. if you are able, can you make an issue on the repo (gitlab.com/tyil/perl6-pod-to-pager) with an example? 23:01
leont Quite frankly, pod not being as extensively redesigned as perl itself was is a missed opportunity as far as I'm concerned. 23:44
TimToady that's a bit of an assumption there 23:48
Herby_ o/ 23:50
TimToady part of the problem was that it was so extensively redesigned that we didn't quite understand how to implement or analyze it 23:52
TimToady though to be fair, it was as extensively designed by *me*, since I had to delegate something or go crazy 23:56
*wasn't
TimToady that durn n't key is acting up again... 23:56
mst TimToady: opportunity cost is a thing 23:58
anyway, presumably we're allowed pod6.d ? 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!