Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
00:00 reportable6 left
vrurg Is there a commit with similar hash in roast, perhaps? 00:00
timotimo haha 00:01
perhaps you can put any commit hash in any repo
or maybe only for repos that are beyond a certain size?
AlexDaniel you can view the whole tree as if it was another repo github.com/perl6/roast/tree/c11e7e...4086722cc2 00:02
timotimo maybe the check "is this in the right repo?" is cheap up to a certain size or something
AlexDaniel this is definitely not right xD
I'll report that…
timotimo oh, you could fool people into believing something is in an official repo
00:03 reportable6 joined
timotimo could be some social engineering potential there 00:03
extra especially if it can be made to work in private repos
talking about that in a publically logged irc channel is, of course, not a good way to do responsible disclosure, oops 00:04
i hope i didn't ruin anyone's chances at a bug bounty by just blurting that out
AlexDaniel I mean, yeah, I should've thought a bit before sharing, I guess :) 00:06
00:09 pamplemousse left 00:12 pamplemousse joined 00:15 lucasb left
AlexDaniel hmmmm 00:16
timotimo: now that I think about it, did anybody somehow push rakudo commits into roast or vice versa? 00:17
ah, it should be easy to check that…
no, not really, hmm 00:18
timotimo i mean it's not impossible 00:20
orphaned branches are a thing git supports
AlexDaniel and github tends to cache them for a bit longer 00:21
I think this is the first commit…
github.com/perl6/roast/commit/8454...793b829910
let me check…
ugexe i was about to say... seems like something i did before 00:22
timotimo maybe they don't do "git gc" because "throw more storage at it" is easier and cheaper than "run git gc at bajillions of git repos"
AlexDaniel no, its children are also in 00:23
ok, *this* is the newest commit: github.com/perl6/roast/commit/a8cd...1d35686eff 00:24
or so it seems to me
so not a vulnerability then, as you'd have to push stuff into your own repo
timotimo OK 00:25
ugexe i remember wondering why that push was taking so long
AlexDaniel it's not great but I also can't see how it hurts, heh… :)
I found it because I was bisecting something in rakudo, then vrurg asked the question about roast, so I ended up pasting rakudo sha into a roast url 00:26
vrurg AlexDaniel: speaking of bisecting. Have you had a chance of running blin on the HEAD? I wonder if lizmat's changes to Map have affected any of the ecosystem modules. 00:28
AlexDaniel kawaii: ↑ ? 00:29
vrurg: kawaii said they'll run it, but I didn't see the results
vrurg Ok. That'd allow closing extra tickets on both rakudo and problem-solving.
timotimo how well does the get-caller's-language-version thing work with stuff like "the sub that asks is called via a closure that had been passed to grep" or something? 00:30
AlexDaniel I don't think I can run it easily nowadays. I had a google compute instance with a bunch of cores and I no longer do
kawaii I'm awake
Sorry have been in hospital recently
timotimo hey kawaii
AlexDaniel I can maybe run it locally but then it takes forever, especially on the kind of machines I have
timotimo glad to see you're back
kawaii Blin run tomorrow friends
I promise
I love you all
timotimo mhh tasty blins
AlexDaniel kawaii: we love you too ♥ 00:31
kawaii: and also, your health is more important than blin anyway, take care
timotimo i actually saw blinry in a freezer at a grocery store a month ago or so
00:31 pamplemousse left
AlexDaniel kawaii: I assume you're not coming to perlcon? 00:31
00:32 pamplemousse joined
AlexDaniel that was a weird way to phrase that… “are you coming to perlcon?” I meant to say :) 00:33
kawaii Sadly not this year AlexDaniel, but future Perl events for sure 00:34
So many friends I want to meet
AlexDaniel yeah!
vrurg timotimo: depends on how one implements it. I currently use CLIENT::LEXICAL::<CORE-SETTING-REV> 00:36
timotimo kawaii: what continent are you based on? 00:37
kawaii I'm in the UK timotimo!
AlexDaniel so, as I understand, these commits in roast are not on any branch, so eventually they'll expire and will be gc-ed 00:38
vrurg Oh, I just have gotten chance of reading the rest of the conversation. I join the chorus: the health is most important. Take care of yourself, kawaii ! 00:39
timotimo cool. i'm not sure which conferences i'll be visiting in the future, but the chances of meeting are non-zero 00:40
vrurg timotimo: unless I'm overexhausted, but the closured sub could end-up with grep's context as it's CLIENT:: and thus – with 'c' revision. 00:41
timotimo that could potentially be bad 00:45
i'm also very tired right now
but it'd surely be a good idea to construct the most difficult combinations of stacking we can come up with and see if everything makes sense
00:46 pamplemousse left
vrurg It's even worse than that: GLOBAL can have no client package 00:49
I think it's incorrect. Even if a routine is defined in GLOBAL in could be called from anywhere. 00:50
timotimo like most programs having a MAIN that is called from the setting 00:54
right?
Geth rakudo: vrurg++ created pull request #3103:
Return Failure from failed P6-level .parse on 6.e		 01:05
vrurg timotimo: for example. Or a closure passed into a module's routine/method/whatever. 01:06
timotimo right
what does it meeeaaannnn 01:07
AlexDaniel vrurg: oh yay, you found it :) 01:10
I was looking for my revert but couldn't find it 🤷 01:11
vrurg AlexDaniel: are you about the ticket? It's referencing the 'caller language' ticket.
AlexDaniel ah, ha!
wasn't my revert of the tests after all :) 01:12
vrurg timotimo: don't drag it. ;) Am I missing something?
timotimo too tired to think, but thank you for working on that issue that had everybody hide 01:14
vrurg timotimo: if you come up with anything. I can't think out of anything better than CLIENT:: for now. Though most correct use of CLIENT::CORE:: comes up with 'c' and this is not correct. Being put together with the GLOBAL error it means PseudoStash needs some more rework. :( 01:16
AlexDaniel: if by any chance there's a commit for tests for Grammar returning Failure – I'd love to have it. 01:17
AlexDaniel vrurg: take a look at these: github.com/perl6/roast/commit/b536...00a3d6cd2b github.com/perl6/roast/commit/1fb6...958d1b4afd 01:19
vrurg: they're not exactly the tests you're looking for, but these changes were committed together with the rakudo change
vrurg: IIRC there are no other tests, just these changes to hide the fact that we were breaking everything
vrurg: also yeah, I got confused with roast and rakudo commits again :) 01:20
vrurg No escape then, will have to write few. 01:21
AlexDaniel vrurg: we also need some tests to make sure that the behavior in v6.c and v6.d remains still…
or do we?
vrurg AlexDaniel: just keeping the current tests will be sufficient. 01:22
AlexDaniel vrurg: ok, but why?
vrurg Would have to add explicit 6.d though
AlexDaniel vrurg: I'm not following. We're making a change to what .parse returns, what's going to make sure that in 6.c and 6.d it still returns Nil? 01:23
I should've been smarter and reverted these changes in roast back then 01:24
but I didn't
vrurg Oops, I'm over-exhausted already... Sure, Failure is Nil...
Ok, noted. 01:25
AlexDaniel so current 6.c-errata and 6.d-errata won't trip if you change what .parse returns
which is a mistake that we're allowed to fix, I think
by perhaps reverting these commits by TimToady 01:26
Geth ¦ rakudo: vrurg self-assigned [WIP] Incorrect behaviours of CORE:: and CLIENT:: pseudo-packages github.com/rakudo/rakudo/issues/3104 01:30
vrurg AlexDaniel: if you have time to revert and test them I would very much appreciate that. 01:31
I'm afraid of making extra mistakes. 01:33
AlexDaniel vrurg: we can do that after the merge 01:34
or we can as well do that before, but I'm currently going to bed… 01:35
vrurg AlexDaniel: I left a note to myself on the PR, so must not fail. 01:36
AlexDaniel and tomorrow I'll be screaming happily in anticipation of perlcon, probably for the whole day
vrurg Sleep well! :) And have a happy day!
01:51 Voldenet left 01:55 Kaiepi left 01:56 Voldenet joined, Voldenet left, Voldenet joined 02:52 Voldenet left 02:57 Voldenet joined, Voldenet left, Voldenet joined
Geth roast: vrurg++ created pull request #564:
Add tests for CLIENT:: pseudo-package		 03:04
rakudo: vrurg++ created pull request #3105:
Allow use of CLIENT:: pseudo-package in code in GLOBAL		 03:06
05:54 robertle left 05:56 scovit left 06:00 reportable6 left 06:01 reportable6 joined 06:18 scovit joined 07:32 lizmat joined 08:02 lizmat left 08:03 lizmat joined 08:14 lizmat left 08:19 lizmat joined 08:28 lizmat left 08:50 lizmat joined 09:12 lizmat left 09:13 lizmat joined 09:28 lizmat left 09:31 ufobat joined 12:00 reportable6 left 12:05 reportable6 joined 12:55 lucasb joined 13:24 pamplemousse joined
Geth rakudo: 7aa2848fa9 | (Vadim Belman)++ | 2 files
Allow use of CLIENT:: pseudo-package in code in GLOBAL

There is no reason for limiting its use in GLOBAL package.
rakudo/rakudo#3104		 14:34
synopsebot RAKUDO#3104 [open]: github.com/rakudo/rakudo/issues/3104 [WIP] [WIP] Incorrect behaviours of CORE:: and CLIENT:: pseudo-packages
Geth rakudo: 22702ea312 | (Vadim Belman)++ (committed using GitHub Web editor) | 2 files
Merge pull request #3105 from vrurg/rakudo_issue_3104

Allow use of CLIENT:: pseudo-package for code in GLOBAL
roast: 1821f07324 | (Vadim Belman)++ | 2 files
Add tests for CLIENT:: pseudo-package

Test for cross-language revision usage
roast: ef264eb457 | (Vadim Belman)++ (committed using GitHub Web editor) | 2 files
Merge pull request #564 from vrurg/rakudo_issue_3104

Add tests for CLIENT:: pseudo-package
15:06 vrurg left, vrurg joined 15:56 pamplemousse left 16:23 pamplemousse joined 16:49 epony left 17:10 Kaiepi joined 17:34 epony joined 17:52 pamplemousse left 18:00 reportable6 left 18:03 reportable6 joined, ChanServ sets mode: +v reportable6 18:13 chloekek joined
vrurg timotimo: ping 18:43
timotimo pong 18:45
18:46 chloekek left 18:52 Kaiepi left 18:55 Kaiepi joined
vrurg timotimo: what do you think about nqp::p6callerrevision op? 19:00
timotimo sounds like an interesting suggestion, but how would it be implemented? 19:01
vrurg timotimo: Similar to what I do with pseudo-packages: CLIENT::CORE::. I would experiment with it but I know too little about Moar internals. 19:02
timotimo such an op can also be implemented as a desugar in the compiler, which is nqp code 19:03
vrurg I didn't find any nqp implementation of p6* yesterday. But now as you mentioned desugar which I forgot about... 19:04
Ok, Actions.nqp. Thanks, I'll work with that! 19:05
MasterDuke the p6* ops are in rakudo/src/vm/moar/ops/ i think
vrurg Though it turns out that for Grammar it must be done in absolutely other way. 19:06
MasterDuke: those are C-implementations which I'm not ready to dive into.
Besides, p6callerrevision should be backend-independant. 19:07
vrurg is also considering compiling COREs by compiler with language revision they're implementing. 19:09
I.e. CORE.e.setting would be compiled as if `use v6.e` was specified.
timotimo vrurg: you'd probably find it in src/vm/moar/Perl6/Ops.nqp 19:10
MasterDuke timotimo++
vrurg timotimo: what's not right about Perl6/Actions.nqp? 19:12
timotimo not sure if there's implementations of desugars there 19:13
oh
19:13 chloekek joined
timotimo but there are 19:13
OK!
vrurg Fine. But that's if I ever need it. So far, jnthn's approach is that classes with different behaviour must be separaterly defined per-core. There is already PseudoStash for 6.c/d and PseudoStash for 6.e and those are two different classes. Similar to different module versions. 19:15
What worries me most for now is that there is no way to distiguish one from another. 19:17
19:17 pamplemousse joined
ugexe m: class Foo:api<6.d> { }; say Foo.^api 19:20
camelia 6.d
vrurg ugexe: I thought about ver for that purpose. Anyway, neither is set for now and that's what I plan to take care of. 19:25
Another question: how do I distinguis them in a signature? Say, 6.e core knows about two class versions. But sub foo(Foo where Foo.^ver eq '6.e') { ... } is too clumsy. 19:27
Geth rakudo: 74f2d3f465 | (Ben Davies)++ | src/core/ThreadPoolScheduler.pm6
Actually handle passing :every(Inf) to ThreadPoolScheduler.cue properly

It was supposed to run the given block only once, but it was running it every millisecond instead.		 19:33
ugexe you dont 19:35
vrurg ugexe: github.com/perl6/problem-solving/issues/3 and github.com/perl6/problem-solving/issues/71 19:36
If there're two implementations of `Set` and I want to support them both in my code? 19:37
ugexe then fuck you
lol
intead of "you dont" i should have said "you cant right now" 19:38
vrurg friendly community...
;)
I propose sub (Foo:ver<6.e> $foo) {...} notation. 19:39
ugexe it could work (although maybe the single colon in the signature would make it difficult to parse?)
but i imagine for that to really work we'd need a module Foo:ver<1.0> to automatically set .^ver as appropriate (i.e. with the stuff from META6.json if it exists) 19:40
class Foo:ver($*DISTRIBUTION.meta<version>) { ... } 19:41
timotimo longest-token-matching ought to do this right
Kaiepi what if META6.json doesn't match the :ver the class was declared with? i've forgotten to update it before 19:42
vrurg In a module it should be author's responsibility. In the core – I'm gonna start with per-CORE language and then ClassHOW would fetch the infor from the compiler and set it.
ugexe DIHWIDT
Kaiepi dihwidt? 19:43
ugexe doctor it hurts when i do this
Kaiepi oh
ugexe so dont do it
vrurg timotimo: BTW, the grammar would also have to support :ver<>:D But still should be feasible. 19:44
ugexe Foo:ver<420>:_: 19:45
timotimo even more smileys 19:46
:_:
ugexe i thought there was a :_: but maybe i was mistaken 19:47
ah its just :_
vrurg Heh.... More punctiation to the God of Punctiuation... 19:48
*punctuation 19:49
ugexe class Foo { method foo(IO::Path:_: IO::Path $) { } } 19:50
Kaiepi what does :_ do? 19:52
MasterDuke it's like * for type smilies. :_ means either :U or :D
ugexe i.e. its the same as no smiley 19:54
Kaiepi oh
20:51 ufobat_ joined 20:55 ufobat left, chloekek left 21:13 pamplemousse left 21:14 pamplemousse joined 21:17 MasterDuke left 21:24 lizmat joined 21:28 pamplemousse left 21:37 BeastieBot left 21:38 BeastieBot joined 21:53 pamplemousse joined
Geth rakudo: taboege++ created pull request #3108:
Pod: allow empty config value		 21:58
22:14 pamplemousse left 23:46 lucasb left
Geth rakudo: vrurg++ created pull request #3109:
Make COREs compile with their respective language revision		 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!