[Tux] significant slowdown due to jnthn's changes? 06:57
This is Rakudo version 2017.07-83-g9658dd98c built on MoarVM version 2017.07-243-g6941cada
csv-ip5xs 2.795
test 13.434
test-t 4.518 - 4.582
csv-parser 13.526
timotimo possible 09:43
jnthn [Tux]: Yup 09:44
Expected.
m: say 4.1 / 4.5
camelia 0.911111?
timotimo quick, call 911111 09:50
AlexDaniel timotimo: ok, so if I'm seeing this MoarVM panic I mentioned earlier, what should I do? 09:53
timotimo which one is that? wrong owner? or forwarder != item failed? 09:54
AlexDaniel timotimo: I don't understand the question. This is all I see: “MoarVM panic: Internal error: invalid thread ID 36807280 in GC work pass” 09:57
timotimo ah, thread id is what it calls it 09:58
AlexDaniel timotimo: like, what information do I have to gather to make a useful ticket out of it? 09:59
timotimo under what circumstances do you get that? the nfg many-threads test? 10:00
AlexDaniel timotimo: whateverable tests. Nothing in particular seems to be causing it 10:07
jnthn AlexDaniel: It's likely a GC bug, so will probably be hard to gather info on 10:08
AlexDaniel normally that kind of stuff was associated with Proc::Async (so I could narrow it down to one method), but this time it seems like it's not
jnthn I'm about to start looking into it
Hopefully will be able to reproduce it locally with GC stressing enabled
AlexDaniel but do you have something to reproduce it with?
jnthn AlexDaniel: The spectest timotimo just mentioned and somebody reported they could get it in an NQP test yestreday even 10:09
AlexDaniel oooh ok
jnthn AlexDaniel: It's possible you'll be seeing a differrent regression of course 10:10
But there's a good chance not
AlexDaniel ok, good
thanks
Geth nqp: 39d458620b | (Jonathan Worthington)++ | tools/build/MOAR_REVISION
Bump MOAR_REVISION for a GC fix.
 11:04
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...3-g82c282e
rakudo/nom: c1e41f9fba | (Jonathan Worthington)++ | tools/build/NQP_REVISION
Bump to get MoarVM with GC bug fix.
 11:05
¦ rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....4-g39d4586
AlexDaniel jnthn: I guess it means that I should test it? :) 11:09
jnthn AlexDaniel: Yes :)
lizmat jnthn: builds ok, spectesting now 11:20
spectest fine 11:30
AlexDaniel yup, much better here also 11:34
if not perfect
jnthn++ 11:41
stmuk PASS FreeBSD 11.1
jnthn Yay :) 11:55
Thanks for testing.
lizmat on 3rd try, t/spec/S03-metaops/hyper.rakudo.moar became a flapper :-(
Geth rakudo: bduggan++ created pull request #1124:
Fix spelling of descriptor		 14:35
rakudo/nom: 9b31d1f542 | (Brian Duggan)++ | src/core/Proc/Async.pm
Fix spelling of descriptor
 15:16
rakudo/nom: f083cfc6a7 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Proc/Async.pm
Merge pull request #1124 from bduggan/nom

Fix spelling of descriptor
Zoffix mst: since you somewhat followed the project: XTaTIK is dead :) my $boss has different ideas about our websites, so gutting the one XTaTIK website I had to make a smaller web app and that'll be it for it. Still in Perl 5/Mojolicious tho. 15:30
my new $boss I should say 15:31
mst ah
alas, poor yorick ... 15:32
Zoffix yorick?
mst just some dude from an old hamlet
Zoffix ah :)
geekosaur wonders if Shakespeare was ever translated to Russian... 15:33
(I confused someone in #haskell with a quote the other day)
stmuk is it possible to have nqp c0abee7953ac tagged as 2017.07.1 15:53
AlexDaniel ( github.com/perl6/nqp/compare/b2b8c...abee7953ac ) 15:57
stmuk: well… not having it there seems to cause quite a bit of pain for you, right? 16:00
stmuk it does make things less maintainable 16:02
the last couple of star releases there were quite important fixes put it just after the tagging 16:03
AlexDaniel stmuk: what if instead of doing 2017.07.1 release we just add 2017.07-rakudo-star lightweight tag?
well, “release” as it's just a tag anyway 16:04
stmuk yes that's good too
although if you used 2017.07.1 it would encourage other downstreams (distro packages etc) to use a version with fixes 16:08
maybe a quarterly release tag? 16:09
for example anyone "apt install rakudo-2017.07" will get a version where --ll-exeception doesn't work whereas the one in star does 16:11
neither does "perl6 -v" show any apparent difference in version since nqp version isn't displayed
AlexDaniel well, to me this sounds like we should be more eager to make point releases 16:13
stmuk: wait, why would a lightweight tag work for you? 16:15
I mean, it's just a pointer, you can use c0abee7953ac directly with the same result 16:17
stmuk its not just me its anyone packaging rakudo
AlexDaniel Zoffix: thoughts? :) 16:18
stmuk 2017.07.1 or similar clearly has bug fixes over 2017.07 where random hashes don't 16:19
Zoffix AlexDaniel: irclog.perlgeek.de/perl6-dev/2017-...i_14911275
stmuk its baby steps towards some sort of Medium or Long Term Support branches
Zoffix --ll-exception is just not a feature that warranted a hot fix or point release or whatever
stmuk I don't agree you are asking people to use code for 3 months with known and easily fixable problems 16:20
Zoffix It's not a feature regular users use in their code. 16:21
And when debugger was broken for 3 or 6 months; we survived. 16:22
stmuk its fairly sad noone seemed to notice
will there ever be any support of LTS for rakudo or do you just ask users to wait a 1 or 3 in the hope the next release works? 16:23
1 or 3 months
Zoffix No one noticed because it's a feature used by core devs to find where in the core guts explosion happens. I'm not sure what's sad about it. Most of the core bugs I fixed, I didn't even need that feature. 16:27
ugexe i noticed and mentioned it, but no one seemed to care enough to fret so I figured it wasnt a big deal 16:28
Zoffix "hope the next release works" . Not hope. Test it. --ll-exception ain't got any tests so that's why its breakage slipped through
stmuk justifying feature breakage on the basis that noone uses doesn't seem a good idea to me we should be tweaking processes to minimise breakage 16:29
AlexDaniel actually…
ugexe to be clear i'm on the fence on the point release for it
AlexDaniel yeah, me too
but actually that's exactly how you justify it 16:30
stmuk yes the breakage should be spotted in the first place .. but some breakage happens and we need to be able to fix it
Zoffix ugexe: I thought it was fixed after MasterDuke's patch. Though granted I didn't even test anything after my amendment to that code
AlexDaniel there are hundreds of tickets, stuff is getting fixed all the time. Well, how many of these are regressions? Not many, but the reason why we don't have many regression tickets nowadays is because nobody is searching for regressions :P
the last time I did it was like more than 10 tickets
so just because something is a regression doesn't really mean we should make a point release. If noone is using it, then I guess it's a good reason not to 16:31
Zoffix stmuk: my point isn't about justifying anything. I'm saying there will be new bugs all the time and jumping in, trying to fix bugs that aren't important after release needs to be triaged and judged by their importance. Users unable to include full stack trace when reporting bugs in Rakudo is hardly a priority
stmuk I'm wondering if star shouldn't use the release tarballs but submodules and just cherrypick minor fixes for a limited period of time
Zoffix In fact, most don't include it. 16:33
stmuk its not just --ll-exception but the problems with the 2017.04 release as well
AlexDaniel yeah, and we're expected to see this in the future also
Zoffix We addressed the problems with the 2017.04 release with the Toaster
AlexDaniel right, maybe less 16:34
Zoffix Or more precisely: the Toaster is one of the solutions implemented to address those problems
stmuk that helps with spotting problems but I'm talking about the case (increasing frequent) where obvious bugs slip through 16:35
I'm not even talking about maintaining star with bug fixes for 3 months but fixing the odd bug a day or two after the release 16:37
Zoffix That's part of the process. IMO if it's not important enough to cut a point release of Rakudo; it's not important enough to cherry pick it into R*. Rakudo Star being Rakudo + docs + modules is an easy model to understand. Rakudo Star being Rakudo + cherry picks for some evidently unimportant (since no Rakudo point release) bugs + rest is needlessly complex IMO. I'd expect Rakudo Star to not cherry pick
anything into the compiler it ships; I think this will be more important with the quarterly language point releases next year.
NeuralAnomaly: status 16:40
NeuralAnomaly Zoffix, [?] Next release will be in 1 day and 3 weeks. Since last release, there are 18 new still-open tickets (4 unreviewed and 0 blockers) and 90 unreviewed commits. See perl6.fail/release/stats for details
Zoffix There've been 18 new tickets since last release. You're not gonna cherry pick all the fixes, just because you can, eh? 16:41
AlexDaniel we only care about regressions though
there's one but it's the old stuff
perlpilot (and apparently only if it's within N days of the release)
stmuk no I'm talking about the sort of issues we had in the last two R* releases 2017.04 and 07
AlexDaniel and the only other one is --ll-exception which is what we are talking about…
cog_ hi, how come panda still included in R* modules and not zef ? 16:43
Zoffix So yeah, I think the easiest approach is to improve the testing process and not cherry pick anything into star.
AlexDaniel cog_: this was mentioned, yes. Yes, it should be changed
Zoffix 2017.04 problem was really a problem with Rakudo releases (now addressed) where the only reason R* had to imporvise was because cutting 5th point release was ridiculous. 16:44
stmuk this probably means less frequent R* releases
cog_: uh? zef is in R* and panda tells the user not to use it
Zoffix 2017.07 problem; I wouldn't even call it that. A core dev's debugging aid got broken, big whoop, regression or not. 16:45
AlexDaniel uh! Indeed I misread something
cog_ stmuk, am I looking in the wrong place ? github.com/tadzik/Task-Star/blob/m...META6.json
ugexe the problem isn't that it is busted but that the message is misleading
stmuk cog_: yes that's wrong 16:46
cog_ stmuk, care to elaborate ?
Zoffix And that's it in the past, what 2 years? I'm not seeing the upcoming R*-calypse that we need to come up with some sort of solutions for problems that don't really exist.
ugexe: and any core dev would realize the misleading message and any non-core dev wouldn't be using that fedature.
stmuk cog_: 1. that version of Task::Star doesn't contain the current rakudo star modules 2. has been deleted from the ecosystem 16:47
Zoffix cog_: that's a package that should be deleted from the ecosystem and not what's included in Rakudo Star
AlexDaniel m: printf("%d, %d", 1); # yeah right…
camelia Your printf-style directives specify 2 arguments, but 1 argument was supplied??
Zoffix buggable: eco Task::Star
buggable Zoffix, Task::Galaxy 'Another meta-package for modules (with tests), fatter than Task::Star and more test orientated.': gitlab.com/stmuk/p6-task-galaxy.git
Zoffix Right, it's not even in the ecosystem anymore
stmuk Zoffix: do you ever think there will be a reliable LTS Rakudo? 16:48
cog_ stmuk, so how R* is generated ? where does it gets its list of module ? is that published anywhere ?
stmuk cog_: look in the release tarball
Zoffix stmuk: I don't think we should have anything like that for at least the next 2, 3 years.
AlexDaniel “any non-core dev wouldn't be using that fedature” is a very loud statement, and is likely false
I've used --ll-exception several times this year because some error messages sucked 16:49
now, maybe we don't have many unfixed errors like this, I don't know
geekosaur it's often requested from users when they trip over something behaving oddly in core
stmuk Zoffix: we should at least be taking some baby steps towards LTS
Zoffix: more agressively fixing bugs every quarter by a bit of extra tagging isn't a big ask 16:50
cog_ ok, got it the place to look is github.com/rakudo/star
Zoffix stmuk: I'm no longer a release manager, so I don't think that imploration should be addressed to me, but looks back realistically on the past 6 months: Setties/Baggies completely overhauled; all of the IO completely overhauled; all of the Proc/Proc::Async completely overhauled; a bunch of Socket stuff also overhauled. What LTS are you talking about when we're still nailing down the holes in spec? 16:51
stmuk cog_: that's not really where you should look .. look in the tarball
cog_ I want to know how it is generated
stmuk I'm talking baby steps not runnning to LTS
Zoffix stmuk: the bugs are already fixed more aggressively every three months and fewer risks are taken pre-R* release 16:52
AlexDaniel: and how many users used :delete on an Array by comparison to --ll-exception? 16:53
AlexDaniel Zoffix: was it a regression?
Zoffix Why does it matter?
What do you consider a "regression"?
mc: my @a is default(42) = 1...*; @a[1]:delete; say @a[1]:exists; .say for @a[^10] 16:54
AlexDaniel something that worked in the past, then I updated and it no longer works
committable6 Zoffix, ¦2015.12: «Cannot .elems a lazy list? in block <unit> at /tmp/OpEQReEue0 line 1??Actually thrown at:? in block <unit> at /tmp/OpEQReEue0 line 1? «exit code = 1»»
stmuk you are telling users to wait 3 months before they can get an internal stack trace?
Zoffix Yes, I am
Just as they have to wait to get right results from :delete on a lazy array
stmuk even although the fix is 2 or 3 lines
Zoffix stmuk: except IT IS NOT
This entire discussion started with the issue of point releases and downstream stuff 16:55
Because it's not 2 or 3 lines, it's a whole ton of work.
Zoffix &
AlexDaniel stmuk: regrarding LTS stuff, I am not making any decisions like this before I make at least one release, so can't tell anything right…
right now* :) 16:56
stmuk its work because you have to release at worse 3 tarballs
AlexDaniel but maybe can't tell anything right also :)
stmuk how is typing a command to tag a lot of work?
I think my point is a simple fix shouldn't be a lot of work 16:57
AlexDaniel: ok no worries
AlexDaniel stmuk: but I'm not sure what command you're talking about exactly. For example, if I make a lightweight tag, then it's no different than you just using a hardcoded commit (it's just a pointer to some commit, it's not going to be signed or anything) 16:59
so let's assume regular annotated tag then, sure. What do you expect to see in VERSION ? 17:01
as it'll say 2017.07 but that's not entirely true
so I'll have to change that? But then we'll need to have it branched out in some way
what I'm trying to say is that if we want to do it in a reasonable way, then it's not just one command 17:04
stmuk I had to patch VERSION anyway
I'm just trying to make this process less hacky 17:05
github.com/rakudo/star/blob/master...-fixes.txt
AlexDaniel can't we just live with it for 3 months? Did we have anybody complain about the bug already? :S 17:08
like, you don't *have* to go through the trouble
stmuk well two devs talked me into it :)
this is the fix github.com/perl6/nqp/commit/c0abee...e5fc85ca70 17:11
nine WRT an LTS release or releases, I guess it will happen like with the Linux kernel. People who are interested enough in those to do the actual work will do that.
It's clear that Zoffix++ is not interested :) But if others are, why not? Doesn't hurt anyone.
stmuk perhaps I think its likely to come from R* currently since there aren't any other candidates 17:12
nine Well for me that sounds like a reason to have R* in the first place, since personally I don't really see the point of bundling rakudo with an arbitrary selection of modules. 17:13
stmuk well it means at least a few modules tend to get tested by third parties on various other systems 17:14
ARM whatever
windows :(
jdv79 looks like File::Temp has a test failure on the current rakudo 18:14
# Failed test 'Some files were unlinked by GC'
Zoffix jdv79: zef update
jdv79: it was fixed in File::Temp about 4 hours ago
jdv79 weird, i just reinstalled zef. ok. i'll try that 18:15
Zoffix jdv79: did you nuke ~/.zef too?
It should be installing version 0.0.6 18:16
jdv79 no. update didn't fix it too...
Zoffix jdv79: what about zef --/cache install File::Temp ?
or zef --/cached install File::Temp
second one 18:17
But anyway, the fix was just fixing the tests. Just force install
jdv79 yeah ok 18:20
mr_ron .tell timotimo I finally managed to verify that I was running p6 with MoarVM patch you mentioned yesterday, and the example in RT #131774 still gets a MoarVM memory panic on my ubuntu with a ulimit of 4Gig and 150_000 iterations. 19:21
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131774
yoleaux mr_ron: I'll pass your message to timotimo.
timotimo hey mr_ron 19:24
yoleaux 19:21Z <mr_ron> timotimo: I finally managed to verify that I was running p6 with MoarVM patch you mentioned yesterday, and the example in RT #131774 still gets a MoarVM memory panic on my ubuntu with a ulimit of 4Gig and 150_000 iterations.
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131774

Powered by Cro and the Raku® Programming Language.

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

Thank you!