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:06 lucasb left, nine left, nine joined 00:07 rba[m] joined 00:48 [Coke] joined 01:05 hoelzro left 04:04 DrForr_ left 04:14 hoelzro joined 04:59 discord6 joined, discord6 left, discord6 joined
TimToady vrurg, jnthn: I commented on #2677 05:50
R#2677 even 05:51
synopsebot_ R#2677 [open]: github.com/rakudo/rakudo/issues/2677 [6.e][consensus needed][detrap][needs research][roles] Uncertainty about submethods in roles
TimToady from which you can tell I've backlogged as far as Febrary... :) 05:56
*ru
07:13 patrickb joined
|Tux| Rakudo version 2019.03.1-660-g9b639961c - MoarVM version 2019.05-94-g459e68675
csv-ip5xs0.676 - 0.713
csv-ip5xs-205.097 - 5.322
csv-parser22.761 - 22.798
csv-test-xs-200.422 - 0.430
test6.744 - 7.023
test-t1.682 - 1.776
test-t --race0.792 - 0.849
test-t-2027.889 - 30.597
test-t-20 --race9.014 - 9.178
 08:38
masak TimToady! \o/ 08:55
jnthn TimToady: Thanks :) 08:57
lizmat Files=1275, Tests=108166, 207 wallclock secs (26.41 usr 7.51 sys + 2878.07 cusr 287.59 csys = 3199.58 CPU) 09:34
09:54 rba joined
kawaii releasable6: status 10:35
releasable6 kawaii, Next release will happen when it's ready. R6 is down. At least 4 blockers. 262 out of 660 commits logged (āš  1 warnings)
kawaii, Details: gist.github.com/c73f6911baacea9dc8...b305899d00 10:36
kawaii AlexDaniel: while we wait for blockers to be resolved, maybe worth another Blin run in the meantime? 10:37
AlexDaniel releasable6: status 10:57
releasable6 AlexDaniel, Next release will happen when it's ready. R6 is down. At least 2 blockers. 262 out of 660 commits logged (āš  1 warnings)
AlexDaniel, Details: gist.github.com/b2f75f0c0a065fc463...38c5d612c5
AlexDaniel kawaii: looks a bit better now? :) 10:58
kawaii Much better ;)
So uh, looks like we're over 400 commits out from the changelog too, ugh that's going to take a while 11:18
AlexDaniel kawaii: yes, better start now :) 11:41
Geth Ā¦ problem-solving: rba self-assigned rakudo.party github.com/perl6/problem-solving/issues/52 12:30
Ā¦ problem-solving: rba assigned to maettu Issue rakudo.party github.com/perl6/problem-solving/issues/52
jnthn Do we know if folks read/value the changelog? It's a lot of manual work. 12:51
kawaii jnthn: I don't know, I have the bad habit of _not doing so_, but that's just me. 13:01
I don't relish combing through 400 commits either 13:02
jnthn: rakudo.org/post/announce-rakudo-st...se-2019-03 13:06
IMO this is of more value than a raw changelog ^
it outlines only the major changes
patrickb kawaii: Agreeing. I was just typing a response along the same lines. I guess most people are interested in the highlights only. To know whether a specific bug was fixed one would look at the issue instead. 13:08
kawaii cc: AlexDaniel for further thoughts
patrickb But then, how do you know what the highlights are? These remaining 400 commits will have some highlights in them for sure... 13:09
kawaii patrickb: I was just about to prompt people to list some suggestions for the 'big changes' :)
patrickb The perl6 weeklies are an excellent source for what happened maybe just skimming through those is an approach. 13:15
kawaii Yes lizmat does an excellent job with those 13:16
I'd say they're the primary source of my perl 6 news
other than this IRC and the flurry of github emails I ignor.... read :) 13:17
13:28 titsuki joined 13:32 MasterDuke joined
Geth rakudo: ea7957101d | (Paweł Murias)++ | 4 files
[js] Fix the js build after recent build system changes
 13:41
vrurg I would say it's a wrong approach of offloading changelog maintenance on Liz. A commiter knows best of all what's commited and wether it's worth mentioning in the changelog. This also makes it easier to filter out really significant ones for Liz (who is, BTW, the only one soing this kind of stuff, so we must think of helping her). 13:44
Besides, some people do not report problems and don't check issue trackers. They simply wait until something gets fixed. And to know if it was fixed they check changelogs. 13:46
kawaii vrurg: I didn't intend to offload it all to her, I think we were just pointing out that of her own accord, she does a good job at keeping people up to date with compiler goings-on. :) 13:48
How about if we adopt a policy whereby if you make a commit and you _feel_ it might be newsworthy, update the changelog, if not, don't?
moritz +1
the downside is that it's easy to forget to do so 13:49
jnthn Perhaps we could put some marker at the end of a commit message, e.g. `changelog: true` and those commits will go into the changelog?
(Doesn't help us this month, alas.)
vrurg kawaii: You're proposing my own guiedline. :) 13:50
jnthn++ 13:51
Though typing 'changelog: true' is is awkward. Just a 'for changelog' on it's own line perhaps? 13:54
jnthn: BTW, had some time to play with the cores yesterday. Experimentally added a dedicated list on the world's context object alongside with PADS and made optimizer to use it. Looks even tidier that scanning for '!CORE_MARKER'. Hope to make find_symbol utilize that too today and see if CORE:: can be built out of that. 13:57
*than scanning
jnthn vrurg++ 13:58
vrurg: 'for changelog' could also work; was just going on a style I've seen used elsewhere for meta-data in commit messages (e.g. gerrit's thingy IDs) 13:59
kawaii _some_ kind of token in the commit message, CL, changelog, changelog: true... any will do provided we agree on a standard and people adhere to it :) 14:00
vrurg jnthn: I used to build changelog from commits for my Perl5 modules only skipping those marked with 'minor: ' prefix. Dist::Zilla plugins are great for these kind of things. 14:01
kawaii: It made me think of specifying sections of changelog: 'For changelog fixes', 'For changelog deprecations', etc. 14:04
kawaii { "changelog": true, "type": "fix" } 14:07
vrurg: ĀÆ\_(惄)_/ĀÆ
maybe asking people to put a raw json into their commit message is a bit much, but would certainly make it nice for any automated tools 14:08
vrurg And then make people adopt it... :D I'm afraid even the simple thing of adding 'for changelog' could be ignored by many. It has to be in a policy.
Geth rakudo/feature-1860: a362fac5bb | Coke++ | lib/Test.pm6
Clean up diagnostic output

For #1860		 14:09
vrurg I wonder if it is possible to attach a simple form to a PR on github?
Geth rakudo: coke++ created pull request #3024:
Clean up diagnostic output
TimToady maybe a tag on the issue before it's even fixed, assuming the changelog entry references the issue 14:15
14:16 pamplemousse joined
kawaii 'Tags' on GitHub are GitHub specific and not part of the actual .git data if I understand correctly, it's a possible solution but not one we could use any programmatic tooling on I think. 14:18
_Maybe_ one could use GitHub's API to find PRs with the `changelog` tag and form a list that way, I do not know currently.
vrurg Aren't PR's has their own commits? BTW, there could be a template for PRs (help.github.com/en/articles/creati...epository) which would pre-include standard meta-information lines. One would just need to change those ā€“ similar to issue tracker template rakudo has now. 14:23
I would probably try adding a PR template later today. 14:33
kawaii that could work, there's markdown for checkboxes ("- [] changelog" if I recall) we could use for that 14:34
15:48 patrickb left
AlexDaniel I'mā€¦ not sure 15:48
kawaii Informative! 15:49
AlexDaniel if we only changelong the things that are ā€œnewsworthyā€, wouldn't it be so that people downloading the new release will get a false impression that nothing was fixed/improved? 15:52
ā€œlook they only changed these 10 thingsā€
it shouldn't be so if we present it right 15:53
kawaii AlexDaniel: most OSS projects usually add a line saying "misc performance improvements in X and Y..."
AlexDaniel I agree that changelogging is a difficult thing, though if we you all think it's unnecessary you could've said it like a year ago :D 15:54
:D
kawaii I wasn't here a year ago! :P 15:55
AlexDaniel fair enough!
kawaii: let's do it this way
vrurg There should be two block of info: more detailed changelog and brief release info. So, people seeking for more details know where to get 'em. 15:56
AlexDaniel kawaii: you research this and figure out what's the best way to go forward, I changelog the commits for this release
kawaii AlexDaniel: here's a good example of how releases should look, from another OSS project I am a core member of: mybb.com/versions/1.8.21/
note the `Issues resolved (39)`, with a simple link to GH
AlexDaniel kawaii: and in the special notes of this changelog we say that the format will be different next time
kawaii we make use of GitHub milestones and a special query to show all of the issues closed from the last release to the current one, might be worth investigating for Rakudo 15:57
but yes agree, I will research a good way of doing things from now on
vrurg: would linking users to a query page like github.com/mybb/mybb/issues?q=is%3...e%3A1.8.21 meet that requirement of a more complex breakdown? 15:58
vrurg kawaii: I conclude that there is no need to create a PR template any time soon?
No, it must be included into a distribution. People are lazy in general. Give them the easiest way. 15:59
kawaii FYI in other OSS projects I work on, we don't allow a PR unless it solves an issue, even if it's not a bugfix, we'd still make an issue saying "X is slow" or "Y is not optimal"
vrurg But I don't see a big deal in forming the ChangleLog from commits. 16:00
kawaii: That's what I was used to while working on Foswiki. Every commit there was linked to a task. That was enforced by git hooks. 16:01
AlexDaniel kawaii: I kinda agree with that, but what about performance improvements?
kawaii: sometimes there's a ticket, but usually a dev just finds some unoptimized code and makes it better
so we end up having no ticket for it
vrurg AlexDaniel: usually, when you make a block of changes you have a task in your ming, a goal. That makes good point for a new issue to be created.
AlexDaniel which personally I don't mind, but people want to see perf improvements in the changelog, I'm pretty sure
kawaii Yes so perf improvements should have an issue associated :) 16:02
AlexDaniel so it means more work/hassle for lizmat? :) 16:03
kawaii I'm going to draft up an RFC later tonight and we can discuss from there
vrurg kawaii: make it into problem-solving
lizmat notes she is a limited resource
jnthn too, though most of his perf work is in the MoarVM repo :) 16:04
vrurg lizmat: we could spare a bit of you by makeing it easier to analyse the changes. :)
AlexDaniel vrurg: not exactly 16:05
16:05 pamplemousse_ joined
vrurg AlexDaniel: that's why I used word 'usually' 16:05
lizmat vrurg: actually, more descriptive changelog messages are what I really need :-)
vrurg But basically it's not that hard to get used to.
AlexDaniel vrurg: well it's not that hard for the release manager to get used to changelogging stuff, too 16:06
vrurg lizmat: we could enforce those with git hooks too. It could be made a requirement to have 1-2 lines of description with each commit. 16:07
16:09 pamplemousse left
lizmat I wouldn't be in favour of that. That would just ensure 2 lines of garbage to go through if someone doesn't feel like adding 2 lines. 16:09
vrurg AlexDaniel: let's see what would kawaii come up with. Perhaps we could merge the best of all worlds?
lizmat: that's possible. In either case it's a matter of ones responsibility. I used to think of how would others understand what's I did.. 16:13
lizmat too bad commit messages are immutable.
sometimes I wish I had an easy way to see the original commit message, followed by any comments made on Github for that commit 16:14
a la "git log"
Geth rakudo: a362fac5bb | Coke++ | lib/Test.pm6
Clean up diagnostic output

For #1860		 16:16
rakudo: fd492d28a9 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | lib/Test.pm6
Merge pull request #3024 from rakudo/feature-1860

Clean up diagnostic output
synopsebot_ RAKUDO#1860 [open]: github.com/rakudo/rakudo/issues/1860 [Test.pm] Test.pm "looks like"
AlexDaniel github.com/perl6/problem-solving/issues/53 16:17
lizmat: yea, github comments kinda suck
well, they're great, but they're just not part of git, which sucks
[Coke] lizmat++ ; happened to see that ticket I opened last year and realized I could just do it. 16:21
Geth nqp: 4300d42139 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump NQP to get profile fix
 16:28
16:41 pamplemousse_ is now known as pamplemousse
Geth rakudo: 2dc68c9224 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get profiler fixes
 16:43
17:16 rba left 17:33 rba joined 18:00 AlexDaniel left, AlexDaniel joined
Geth Ā¦ problem-solving: AlexDaniel self-assigned Release process changes github.com/perl6/problem-solving/issues/54 18:08
Ā¦ problem-solving: AlexDaniel self-assigned Changelogging takes too much time and effort github.com/perl6/problem-solving/issues/53 18:10
18:26 pamplemousse left
nine FWIW the ChangeLog is also the basis for the Changes section in the openSUSE RPM packages. Though due to the line limit there I have to summarize a lot. That's actually usually the most time consuming part of packaging. 18:31
lizmat nine: is that a column limit or number of lines limit ? 18:34
nine number of lines 18:35
lizmat that's for the whole RPM, or per issue / feature ? 18:36
nine I think the limit is 30 lines
for the whole rpm
For example: build.opensuse.org/package/view_fi...s?expand=1 18:37
AlexDaniel heh, debian just says ā€œNew upstream version 2018.09ā€ :) 18:44
dogbert11 does anyone recognize this error: Cannot find method 'sink': no method cache and no .^find_method 19:30
vrurg dogbert11: trying to call the method on a low-level class object. Most likely, on something BOOT* 19:34
dogbert11 vrurg: I get it when running a spectest file (intermittently) 19:39
vrurg Which one? 19:40
dogbert11 t/spec/S17-supply/return-in-tap.t 19:41
timotimo we can make that error output the type's debug name 19:45
dogbert11: pull moarvm's master and try again, if you didn't yet figure out what happens 19:48
dogbert11 timotimo: I believe I have master, lizmat bumped a couple of hours ago. btw, here's a gist gist.github.com/dogbert17/79611c50...33689fb778 19:49
timotimo i pushed to master like a minute ago
dogbert11 aha :) 19:50
timotimo++, faster than a heat wave :)
timotimo it won't be a fix 19:51
just more info in the exception message
MasterDuke `Cannot find method 'sink' on 'BOOTCode': no method cache and no .^find_method`
timotimo yeah, that's not the kind of thing you'd expect to have returned into something HLL, and especially not in void context 19:52
sink context*
dogbert11 ok, let's see if I can repro ...
timotimo: Cannot find method 'sink' on 'BOOTCode': no method cache and no .^find_method 19:53
timotimo i feel like the linkify userscript should also understand t/spec/ links 19:54
does the fudger take care to have lines match up with the original? might not be possible with the #? blah emit feature 19:55
if that's ever used?
dogbert11 good question 19:57
timotimo otherwise that'd be more smarts than i want to put in there
dogbert11 I like it as it is :)
timotimo hm? 19:58
dogbert11 well, more links are better ofc but not at the cost of massive complexity
it would be really cool if you could untangle a link like gen/moar/stage2/NQPHLL.nqp:1835 20:00
but I suspect that might be quite difficult ? 20:01
ASAN has absolutely nothing to say :( 20:02
20:04 MasterDuke left
dogbert11 I see that MasterDuke has managed to reproduce the error 20:04
20:06 MasterDuke joined
timotimo that's a bit more difficult, because what actual file it comes from will depend on the line numbers of other files 20:09
dogbert11 aha 20:10
timotimo gist.github.com/timo/7cfe71a667bbd...0431da45a4 - updated; give it a try if you want :) 20:12
time to prepare some dinners 20:14
well, just one dinner actually
dogbert11 timotimo++, way cool
nothing for the cats?
timotimo they already get a little extra so that they get enough liquid 20:20
we don't have a cat spring or something, so getting them to drink is challenging 20:21
but spritzing some extra water on their wet cat food already helps
20:21 ggoebel joined 20:41 pamplemousse joined 21:22 AlexDaniel left 21:28 ggoebel left 21:32 AlexDaniel joined 21:50 AlexDaniel left
dogbert11 timotimo: at least the error is old, I just got the same failure on 2018.12 22:20
22:23 pamplemousse left
timotimo i wonder how it gets a BOOTCode from that stuff 22:28
dogbert11 wait a minute, is that error message from MoatVM? 22:45
it is, excellent 22:46
and ofc it's MoarVM rather than MoatVM as I wrote above :) 22:48
jnthn
.oO( Well, there's the name for the security-hardened version... )
 22:51
dogbert11 .oO(I'm a moaron) 22:55
timotimo: got it in gdb, gist.github.com/dogbert17/e8010e8a...b70d4e6369 22:56
timotimo try dumping the bytecode perhaps? dunno 22:57
dogbert11 and how do I do that? 22:58
timotimo call MVM_dump_bytecode(tc) 22:59
dogbert11 timotimo: gist updated 23:02
timotimo ah, there's really not much there 23:03
it's just getting whatever try-it returned
dogbert11 any other suggestions? 23:04
timotimo with rr you could step backwards to see what put this result in the return path in the first place 23:05
dogbert11 which I can't do since I'm on AMD
timotimo graaaahhhhhh 23:06
dogbert11 hopefully the new Ryzen CPU's coming on July 7th solve that problem
23:51 ggoebel joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!