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:17 anatofuz left, lucasb left 00:42 anatofuz joined, anatofuz left 01:22 anatofuz joined 01:26 anatofuz_ joined, anatofuz left 01:51 anatofuz_ left 01:59 anatofuz joined, anatofuz left 02:12 anatofuz joined 02:13 anatofuz left 02:17 dogbert11 left 02:18 squashable6 left 02:20 squashable6 joined, ChanServ sets mode: +v squashable6 04:02 anatofuz joined 04:12 anatofuz left 04:14 anatofuz joined 04:16 anatofuz left 04:21 anatofuz joined 04:27 anatofuz left 04:30 anatofuz joined 04:34 anatofuz left 04:39 anatofuz joined 04:57 anatofuz left 04:58 anatofuz joined 05:02 anatofuz left 05:04 b2gills left 05:05 anatofuz joined, b2gills joined 05:29 robertle left, squashable6 left 05:33 squashable6 joined, anatofuz left 05:36 anatofuz joined 05:40 anatofuz left 05:42 anatofuz joined 05:54 anatofuz left, anatofuz joined 05:55 anatofuz left 05:56 anatofuz joined 06:09 anatofuz left 06:10 anatofuz joined 06:23 anatofuz left
samcv vrurg, well it's not language-perl6, since there haven't been new commits. and same with language-perl. so maybe some other addon you have. can i get a list of all your modules in atom? 06:24
06:24 anatofuz joined
samcv just do `~/.atom/packages` and should get a list of all of them 06:24
06:34 anatofuz left 06:35 anatofuz joined 06:41 anatofuz left 06:44 anatofuz joined 06:52 anatofuz left 06:54 anatofuz joined 07:01 anatofuz left 07:08 anatofuz joined 07:22 anatofuz left 07:23 anatofuz joined 07:28 anatofuz left 07:34 anatofuz joined 07:39 anatofuz left 07:51 anatofuz joined 07:57 anatofuz left 08:09 anatofuz joined 08:11 anatofuz left, anatofuz joined 08:16 anatofuz left 08:18 awwaiid left 08:21 anatofuz joined, anatofuz left 08:22 anatofuz joined 08:26 anatofuz left, anatofuz joined 08:35 anatofuz left 08:36 anatofuz joined 08:39 anatofuz left, anatofuz joined 08:40 anatofuz left 08:41 anatofuz joined 08:45 anatofuz left, Ulti left 08:46 Ulti joined 09:04 tyil is now known as tyil[m], tyil[m] is now known as tyil 09:19 anatofuz joined
|Tux| Rakudo version 2019.07.1-351-g554f91e88 - MoarVM version 2019.07.1-238-gfc78a13b6
csv-ip5xs0.763 - 0.770
csv-ip5xs-206.448 - 6.503
csv-parser21.750 - 22.601
csv-test-xs-200.418 - 0.419
test7.251 - 7.276
test-t1.707 - 1.736
test-t --race0.778 - 0.782
test-t-2029.366 - 29.873
test-t-20 --race8.961 - 9.025
 09:28
09:43 anatofuz left 09:45 anatofuz joined
AlexDaniel So! We decided to include extensions in the PR so that editors only have to adapt once, yet we picked a set of extensions on a whim because we're rushing the PR for whatever reason (I wanted the rename for years, yet now somehow a few extra weeks is suddenly a problem‽). And this set of extensions 1. Is just distasteful (at the very least too long) 2. Implies that people shouldn't use .t even though we've been doing that for a long 09:51
time, also nobody bothered to write a justification on why it should be so (as I said previously, something something editors is very weak). All of that together doesn't sound right to me, and I'd like the rename to go as smooth as possible.
change my mind
I'm asking here because maybe I'm just being dumb and the situation is much clearer to everybody else. I don't want extra noise on the PR 09:52
timotimo, lizmat, jnthn ↑ 09:53
lizmat I don't personally care much which extension is going to be used
I'm open to changing this later 09:54
before we actually role out 'raku'
09:54 Kaiepi left
lizmat is a little distracted by being glued to BBC wrt constitutional developments in the UK 09:55
09:55 Kaiepi joined 10:04 Kaiepi left 10:05 Kaiepi joined
AlexDaniel but previously the PR used to say that extensions are going to change, and that it'll be decided later to which particular ones 10:06
but somehow we had to pick something, and we did, and now we're somehow open to changing that?
jnthn Are we? :) 10:07
lizmat I only said that we *could* decide to change it, not that we *should* 10:10
AlexDaniel well, if we're not, I can post that as a request for changes, so that at least the test extension can be properly explored
10:11 Kaiepi left
jnthn AlexDaniel: tbh, mostly what I saw of your argument seemed to me overly dismissive of the current reality of how editors work with file extensions, and overly optimistic about that changing. 10:12
AlexDaniel jnthn: what about having `prove` just work?
10:13 Kaiepi joined
AlexDaniel or are you being overly optimistic that `prove` will change? :) 10:13
10:13 Kaiepi left, Kaiepi joined
AlexDaniel or what's the plan? That's my main concern, really, this is not thought through at all, and not described in the PR or pretty much anywhere 10:14
jnthn 1) Nothing about the presence of an alternative for .t for those who wish to use it prevents them using it. 2) Not everyone is using `prove`, and I thought we wanted to encourage use of `prove6` (whatever that ends up being called) anyway.
10:15 Kaiepi left
AlexDaniel also, me being dismissive of how editors work? I was the one who started investigating what's the actual situation with editors is while everyone was saying there are some magical problems 10:16
10:16 Kaiepi joined
AlexDaniel and turns out there's no problem with Atom, or at the very least shouldn't be 10:16
jnthn Well, what I saw is you saying there shouldn't be and others saying they do have one :)
AlexDaniel and intellij is its own snowflake, but yet bashsupport is somehow doing it?
10:17 Kaiepi left
AlexDaniel and your 1) doesn't do it for me, I don't see why we should deliberately have a mix of extensions 10:18
either we encourage our own extension or we encourage .t, the PR is currently going to encourage our own extension, I'm asking why, you're telling me I'm free to use whatever extension I want 10:19
lizmat in the case of .t, originally it was thought to indicate that the script would output TAP
jnthn OK, I thought the PR was offering it up as an option
So apparently I read into it what I thought it should say. 10:20
AlexDaniel “For testing, the extension `.rakutest` should be used, while the old `.t` extension will continue to be supported for 6.e, with deprecation messages appearing from 6.f onward.”
look it even says we're deprecating it
I have no idea how that's even going to work
what's going to deprecate it? prove6?
jnthn Uff, yeah, how'd I miss that :/ 10:21
lizmat well, I wrote it that way because that was what *I* thought was the result of the extension issue
look, to me, this is not at all law to be held up until the end of times 10:22
AlexDaniel so we're open to changing that?
jnthn: are we? ;)
but, even if it starts saying “For testing, the extension `.rakutest` should be used.” without extra remarks, I'm not sure that's not good enough for me
lizmat well, as I said, .t should indicate TAP output, regardless of what executor it produces 10:23
at least in my opinion
AlexDaniel that's correct, yes
lizmat but I guess it's harder to have tools adapt to that
than it is to change to / support an alternate extension
AlexDaniel lizmat: what do you mean? `prove` itself already works 10:24
I guess prove6 doesn't, but honestly its incomplete anyway
lizmat I don't think prove was the problem, but other tools saying that .t implies Perl 5 code ?
AlexDaniel you can have a .t file written in python, with python shebang, `prove` will run it as python
lizmat e.g github ?
AlexDaniel why you guys keep bringing stuff as examples when you have no idea if there's an actual problem? 10:26
lizmat it just goes to show how much confusion there is
AlexDaniel no problem with github as far as I know
I have all these tests with .t github.com/perl6/whateverable/tree/master/xt
none of them seem to be detected as perl5 code 10:27
lizmat then I am ever more confused (but also still very much distracted) 10:28
jnthn AlexDaniel: I guess it uses linguist for that, and I'm guessing the #! line in the tests is giving it a clue; I'm not sure how common it is to include that, however (I never do).
AlexDaniel jnthn: you should include it if you want prove to run it correctly by default (funnily enough, that doesn't work for “perl6” because it has perl in it) 10:30
then you don't need --exec=raku on the command line
and you can have a mix of perl5 and python and whatever else .t files
jnthn: from what I've read linguist also can look at the presence of `use v6` 10:31
I should double check that though… 10:32
jnthn AlexDaniel: If the argument is that I should include it so prove can then fail to do the right thing with it, I can see why I've not been doing it. :) 10:35
I agree that the situation with raku would be an improvemnet there, though.
AlexDaniel Perl6Regex = /^\s*(?:use\s+v6\b|\bmodule\b|\b(?:my\s+)?class\b)/ 10:37
fancy
lizmat shouldn't that also include grammar / rule / regex ? 10:39
token ?
as you could also have a file consisting of just a grammar etc. ? 10:40
timotimo .o( monitor ) 10:43
AlexDaniel lizmat: well, heuristics will become much simpler once we let go of perl5 extensions
at least some time in the future
timotimo would it be fine for me to put my "i would prefer shorter extensions, as well as using .t for tests" in the review i put on #89? 10:44
lizmat yes 10:47
jnthn AlexDaniel: An argument that distinct extensions make heuristics easier favors a .rakutest or such extension, though? :)
AlexDaniel jnthn: not really, because we're talking about providing the same information with a shebang 10:49
jnthn AlexDaniel: I guess, but an extension isn't even a heuristic, and doesn't need looking at the content. Also...I really don't see us getting widespread adoption of a shebang in .t files. 10:55
(I've always used prove with the -e option)
(Until I started using Comma's test runner instead for most things)
AlexDaniel I see no problem getting a widespread adoption of a shebang in .t files
“Create a Ruby file test.rb (or something like that)” testanything.org/testing-with-tap/ruby.html 10:56
I'm now looking at how other languages do it
it's weird
timotimo .junit 10:59
AlexDaniel now that I think about it, there's nothing specifically wrong with .rk or .raku extensions for test files, is there? 11:01
how often do you have runnable scripts that are not tests in the t/ directory?
ok, plain `prove` won't work, but what's the point of a separate test extension anyway? 11:02
I can understand the need for a distinction between executables and modules, and I can see a good argument for having a separate extension for docs 11:03
but for tests? Hmm
jnthn Hm, it's also a way of looking at it 11:05
lunch &
timotimo right, sometimes you'll have modules in your test folder hierarchy for helpers and such 11:07
AlexDaniel treegrep: t/.*\.pl 11:15
greppable6 AlexDaniel, gist.github.com/b023675f091c2b2594...1033fbdf2f
AlexDaniel treegrep: t\/.*\.pl
nine FWIW the "perl6 is not recognized in the shebang issue" has been fixed for serveral Perl 5 versions already
greppable6 AlexDaniel, gist.github.com/477a913941133d053b...6a4d2295fb
AlexDaniel nine: oh 11:16
treegrep: \/x?t\/.*\.pl
greppable6 AlexDaniel, gist.github.com/32ce0cf30028e86115...e9f56c5b2c
AlexDaniel treegrep: \/x?t\/.*\.p[l6] 11:17
greppable6 AlexDaniel, gist.github.com/e10d8c1cd4aa371116...61c2187ccc
AlexDaniel wait that's a perl6 regex?
treegrep: \/x?t\/.*\.p<[l6]]
treegrep: \/x?t\/.*\.p<[l6]>
greppable6 AlexDaniel, gist.github.com/f1675d0c3bf3b50d0a...80833f22df
AlexDaniel, gist.github.com/ab5af49ce3e55dc815...2954125cc1
11:19 ugexe joined
ugexe github.com/ugexe/Perl6-CompUnit--R...6444B8FFB3 11:19
End of discussion
11:19 ugexe left
AlexDaniel and what does that even mean? 11:20
timotimo an example of how to use libraries for tests? 11:21
nine Or...not. Apparently the fix has been reverted :/ www.nntp.perl.org/group/perl.perl5....36423.html
AlexDaniel and how is that even relevant?
#!/opt/perl64/bin/perl 11:22
you've got to be kidding me
11:23 ugexe joined
ugexe i guess I have to spell it out 11:23
it shows a valid reason to have script files that are not tests included in the t folder
timotimo ah, because there's a bin/ in there 11:24
ugexe te Example doesn’t explicitly use .p6 but it just as easily could
11:24 anatofuz left, ugexe left 11:25 anatofuz joined
AlexDaniel well, I already see that based on the output from greppable, with actual bin files that have extensions 11:27
I understand you could do that, but that's why I asked “how often” 11:28
nine In our (Perl 5) code base at work we have a t/generate_test_files.pl script that generates .t files for the unit tests classes in t/lib
11:30 anatofuz left
AlexDaniel so what? Now we're suddenly arguing that `prove` doing the right thing by default would be great? 11:30
or what's the point even, now I'm completely lost
nine I was just saying that it can be useful to have a distinct extension for tests. I'm still very much a fan of .t.raku or something like that btw. 11:31
AlexDaniel anyway, I'll go for a ride, then I'll submit a request for changes. The deprecation clause for .t is not going to fly for sure, and the rest about extensions is very questionable in book too
in my book* 11:32
nine Yeah, extensions seem to be the weak point just now. But that was to be expected honestly :)
AlexDaniel if we want the rename to go through, it feels like the previous version of the PR is more likely to be accepted 11:33
the one that said that extensions will most likely change, but it'll be discussed separately
then we can have the rename go through and we'll also be able to bikeshed extensions to death 11:34
nine jnthn: Just wanted to say that I can sympathise with and support every word of your PR approval message. Except for that I took the liberty of avoiding the energy drain by not getting involved in the discussion and focusing on fixing stuff instead :) 11:36
11:39 anatofuz joined
timotimo it's not like jnthn really had a choice to do that 11:40
i mean, he had a choice, sure, but i guess it was expected of him to pay attention
nine timotimo: you mean approve?
timotimo: oh, probably you mean to participate. Yes, that was pretty much forced 11:41
timotimo no, just involve himself in general
yeah
AlexDaniel some things need to be fixed regardless of whether you want to spend your energy on them or not 11:42
the bigger energy drain in these cases is when you ignore, then you have to suffer for years instead
11:44 anatofuz left
nine AlexDaniel: both true. Nevertheless I'm glad I had the option of staying out of the discussion. 11:52
And because of that I'm immensly grateful to you people who conducted the necessary discussion and worked towards a solution! 11:53
11:55 anatofuz joined 12:01 anatofuz left 12:02 anatofuz joined
jnthn nine: I've been glad to watch you get on with stuff while my energies were being spent on this (and on a totally unreasonable number of cold-y things). 12:15
AlexDaniel: I'm confused, you already *did* approve the PR. 12:18
On what ugexe pointed out: I've got similar stuff happening in a t/ directory too, so it's not entirely unusual to have libs/scripts there 12:19
AlexDaniel: (previous version was more likely to be accepted) then you lose my approval, so...not really :) 12:22
12:49 lucasb joined 14:42 anatofuz left 14:43 anatofuz joined
AlexDaniel jnthn: ok then fix this one? 14:45
I did approve, I changed my mind
14:47 anatofuz left 15:05 dogbert11 joined
lizmat jnthn: work so far on making Proxy subclassable: gist.github.com/lizmat/b9dee7095a5...1b04b9dc66 15:12
unfortunately fails in building with: Cannot find method 'specialize' on object of type NQPClassHOW
at gen/moar/Metamodel.nqp:3405 (blib/Perl6/Metamodel.moarvm:compose)
jnthn lizmat: Perl6::Metamodel::ContainerSpecProtocol is meant to be composed into ClassHOW 15:15
And publish_container_spec probably needs calling from .^compose or so
lizmat ok, so we're good in adding an attribute to every class out there ?
jnthn It's not like it's every object out there :) 15:16
lizmat true, but every "but" is a class, no ?
jnthn Yeah, though mixin caching :)
lizmat anyways, will try to grok what you said there and get back to you :-) 15:17
jnthn So unless you're a fantastic variety of "but"s...
oops
you've :)
15:17 ufobat__ joined
jnthn Probably get it to work at all first, but at some point you'll then need to look up the MRO to see if a parent has a container spec thing set up 15:17
Otherwise it won't actually help subclassing 15:18
lizmat well, being a fantastic variety of "but"s pretty much describes my life in the past year or so :-(
I was thinking doing that on the trait_mod:<is>
jnthn No, that's the wrong place 15:19
It needs doing in the MOP
lizmat ok...
jnthn I think boolean spec and invocation spec have to solve the same problem, so you can crib from them
lizmat the ContainerSpecProtocol.nqp looks ok to you then ? 15:20
15:21 ufobat_ left
jnthn It looks feasibly correct (though I'm doing multiple other things at the same time as looking at it, on not enough sleep, so...) 15:21
lizmat good enough for me :-)
jnthn I can't remember if the other two I mentioned walk the MOP inside of the role or outside of it
lizmat hmmm.. I need to add the new file to the list of files to concat: any idea where that loves now ? 15:23
ah, looks like tools/templates/common_metamodel_sources 15:24
jnthn
.oO( I'm not sure I want to know where it does that... )
 15:25
That sounds likely. It's all moved around a bunch of late
lizmat and it builds! :-) 15:29
running spectests now
and that's clean.. :-) 15:38
15:50 anatofuz joined 15:56 MasterDuke joined 16:23 anatofuz left 16:59 Kaiepi joined
japhb FWIW I happen to hate long (.rakufoo style) extensions; I'm sufficiently used to having to tell prove what executable to use that I just shell aliased that problem away; the editor I currently use is aware of being able to reinterpret a file using a different language plugin; I agree that .t means 'produces TAP' not 'executed by perl5'. 17:32
discord6 <Rogue> I feel like there should be FatRat versions of all the trig functions 17:33
<Rogue> it's quite annoying to have your number degrade as soon as you run them through a trig function 17:34
[Coke] could make multi versions of them that DTRT.
and then use them in the scope you care about.
discord6 <Rogue> Or even Rat versions, since FatRats can get, well, fat 17:35
<Rogue> I can't make up my mind on that the conversion rules should be, though 17:36
<Rogue> Obviously FatRat inputs need to lead to FatRat outputs
<Rogue> But should Rat inputs degrade to Num by default, or remain Rat by default? Or, put another way, do we have an :exact parameter or a :fast parameter 17:37
MasterDuke Rogue: lizmat has (had?) something (pragma/dynamic variable/etc) in the works to control what happens with Rats (e.g., should they get promoted to FatRats instead of converted to Nums). (can i add more parenthetical statements (should i?)?) 17:38
timotimo how do you make a FatRat come out of a trig function? computers don't have enough ram for that
discord6 <Rogue> That's a good question timo 17:39
<Rogue> Some sort of defaulted :$precision argument?
<Rogue> I would be pretty awesome if we could carry irrational constants around in numbers, but I know that's a pipe dream 17:40
timotimo yeah, that'd be a CAS, maybe Math::Symbolic or whatever 17:41
lizmat MasterDuke Rogue github.com/rakudo/rakudo/pull/3122 17:50
17:51 vrurg left 18:05 chloekek joined 18:20 anatofuz joined
lizmat jnthn: do we need a separate "publish_container_spec", why not have set_container_spec perform all of that logic ? 18:30
I guess so you can call it in ClassHOW.compose without worries ? 18:33
discord6 <Rogue> lizmat: that's a good idea as well, to avoid repeating your intention 18:42
<Rogue> but maybe introduce Rat as another possible value for things like trig functions where a FatRat could potentially become infinitely large 18:43
<Rogue> not sure how (or if?) trig functions could spit out an exact answer without just rounding cleverly (which doesn't seem a good choice) 18:45
<Rogue> maybe I'm going down a road that ends at a cliff here :^) 18:46
18:54 anatofuz left
jnthn lizmat: Yes, so it can be applied at composition time. 19:02
lizmat ok, should I look at Perl6::Metamodel::C3MRO.compute_mro to plug in checking for container_spec ? 19:03
jnthn No 19:04
lizmat MROBasedMethodDispatch ?
jnthn What you need to do is walk the mro in publish_container_spec 19:05
Well, check if there's one in this class, and if not, then do something like github.com/rakudo/rakudo/blob/mast...ol.nqp#L60
lizmat oki
jnthn Basically, query classes up the MRO to see if they have a container spec 19:06
That'll make the subclassing of it work.
19:39 vrurg joined
Geth_ rakudo/subclass-proxy: 4a76778c52 | (Elizabeth Mattijsen)++ | 4 files
Allow sub-classing of Proxy objects

Inspired by:
   stackoverflow.com/questions/580553...rectly-tie
This allows one to say: ... (8 more lines)		 19:52
rakudo: lizmat++ created pull request #3196:
Allow sub-classing of Proxy objects		 19:53
lizmat jnthn: ^^ 19:54
20:10 chloekek left
jnthn lizmat: Have some comments, but I think they're mostly "please delete some lines of code" :) 20:40
(Left the comments on the PR already)
20:46 leont joined 20:51 anatofuz joined
Geth_ rakudo/subclass-proxy: ead4fcc3c3 | (Elizabeth Mattijsen)++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
Make sure we decont whatever we create a Proxy subclass with
 21:07
rakudo/subclass-proxy: 963646644f | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/ContainerSpecProtocol.nqp
Don't assign to "local" atteribute
 21:09
21:22 squashable6 left 21:24 squashable6 joined, anatofuz left
Geth_ rakudo/subclass-proxy: fe1dcadaec | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/ContainerSpecProtocol.nqp
Remove special case

Since the first element of .mro is the class itself, it will find its own container_spec that way.		 21:24
21:27 vrurg left 21:31 anatofuz joined
Geth_ ¦ problem-solving: AlexDaniel assigned to jnthn Issue New Raku file extensions github.com/perl6/problem-solving/issues/108 21:35
22:03 anatofuz left, anatofuz joined
Geth_ rakudo/subclass-proxy: 5eea5f4eb6 | (Elizabeth Mattijsen)++ | 2 files
.compose_repr is only needed in the bootstrap
 22:04
22:24 anatofuz left 22:25 anatofuz joined 22:29 anatofuz left 22:36 anatofuz joined, anatofuz left 22:43 dogbert11 left 22:44 ccamel joined 22:47 camelCaser left 22:54 leont left 23:22 anatofuz joined 23:38 squashable6 left, squashable6 joined 23:42 epony left, anatofuz_ joined 23:44 anatofuz left 23:47 anatofuz_ left

Powered by Cro and the Raku® Programming Language.

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

Thank you!