AlexDaniel Xliff: okay, I see it 00:07
00:07 hungrydonkey joined
AlexDaniel hmm 00:08
it gets stuck on `Testing Foo::Regressed for flappiness` 00:09
but why
Xliff: meanwhile maybe try some module that works, like JSON::Fast 00:11
maybe that succeeds…
Xliff: it's a bit weird because it used to work, and I'm pretty sure it still works fro Altai-man
for*
tyil . 00:22
AlexDaniel Xliff: actually, it seems to be working just fine 00:26
Xliff: it feels quite a bit slower than it ever was 00:27
it could possibly be something that regressed in rakudo or zef 00:28
but otherwise it is functional, just slow
try --deflap=1 instead of the default 4
and you'll probably see some progress faster
Xliff: also, if you terminated it in the past, it's possible you'll need this bit: rm -rf /tmp/whateverable/rakudo-moar/*
Xliff Yeah. Just came back from dinner and it's still trying Foo::Regressed 00:36
OK. JSON::Fast worked. 00:37
Still need a case that will show me an error response so that I can see what I'd need to capture. 00:38
AlexDaniel Xliff: run it for just Foo::Regressed but with --deflap=1 00:43
then it'll finish much faster
we can come up with a case that's much faster but doesn't involve a module… but involving a module is kinda the point 00:44
also, why is it so slow???
00:48 MasterDuke left
AlexDaniel Xliff: OK, the original command takes 15 minutes to finish here 00:50
that's actually not as slow as it felt :) 00:51
Xliff Started it's looping behavior. 00:53
It's at 15 minutes and still going.
AlexDaniel Xliff: one of the last lines should've been “🥞🥞🥞 Testing Foo::Regressed for flappiness” 01:01
Xliff: is that correct?
Xliff Yes. 01:02
gist.github.com/Xliff/6bcb7966c76d...730a2dce6d 01:03
AlexDaniel btw it's not looping, it is just printing some info periodically 01:04
ah, it's already bisecting 01:06
so just wait
or… not
hold on
Xliff Last time I waited all night and it still hadn't finished.
AlexDaniel Xliff: right, I see, it's not trying to fetch other builds, so it is indeed stuck somehow 01:07
it's very close though
so you have both zstd and lrzip installed, right?
Xliff No. Was missing lrzip 01:11
AlexDaniel that might be the problem, but I'm surprised that it doesn't propagate anywhere 01:12
whateverable itself does check if lrzip is installed and complains otherwise
so hmm
01:16 Kaiepei left 01:21 Kaiepi joined
Xliff Weird. Updated gist gist.github.com/Xliff/6bcb7966c76d...730a2dce6d 01:26
AlexDaniel Xliff: nice! It finished! 01:27
Xliff: now check the output/ folder to see stuff! 01:28
Xliff OK, so overview acts as a summary of the entire run, then there is an output file for each module processed. 01:40
AlexDaniel yeah
and that's how it looks when you run it on the whole ecosystem: gist.github.com/AlexDaniel/bfe7920...e-overview 01:41
Xliff I can get much of what I need from data.json, however there would be one thing that would be helpful
AlexDaniel output files are generated only for modules that required bisection
Xliff data.json should include a bisected hash if one is found. Then I can process everything in one file.
And with that, there is no reason why I can start creating issues for each repo. 01:42
AlexDaniel Xliff: shouldn't we just modify blin.p6 to generate whatever we need? It probably has more data internally 01:43
Xliff Is that where I can add the bisect hash to data.json output? If so, then yes.
AlexDaniel and we need just 1 rakudo ticket, because it's rakudo bugs that we discover
Xliff You should be able to do that rather quickly, yes? 01:44
OK. Makes it even easier.
AlexDaniel well, either we should move everything out of blin.p6 so that all files are generated separately, or we should generate everything in blin.p6 01:45
02:11 ufobat__ joined
Xliff You telling me blin does not generate data.json? 02:14
Does blin not generate overview, either?
02:15 ufobat_ left
Xliff AlexDaniel: I will have to look into this. Weekend at earliest. 02:15
AlexDaniel Xliff: the point is that blin.p6 script generates all files. If you want to generate more files, it probably makes sense to add code to blin.p6. If you think that this kind of stuff should be separate, then you're free to implement it as a separate script that works on data.json, but then please move other stuff from blin.p6 so that it's also separate 02:20
Xliff AlexDaniel: My hope is that, with one minor modification to blin, that my changes can be isolated into a separate script that blin could then execute. 02:21
I think we are splitting hairs, though. All I need in data.json is a bisect hash, if it exists. Then I'm off to the races.
Everything else will be web-based.
AlexDaniel yeah but some files are generated in blin.p6 and you want to write a separate script. That's fine but I don't like the idea of having half done one way and another half done differently 02:22
Xliff WTAF?
NO files will be generated by a separate script. 02:23
I just want the bisect hash in data.json. Is there a technical reason why that is a problem?
AlexDaniel but you say you want to work on data.json
Xliff Yes. As an INPUT
AlexDaniel in blin.p6 you have *all* the data in memory, you don't need to write to a file so that you immediately read from it to get the data you need… 02:24
Xliff OK, then. But this is logic separate from the entirety of blin.
AlexDaniel right, I'm fine with having a separate script that generates stuff 02:25
it can be called from blin.p6 automatically but that's not a big deal I guess
but then we probably want to move other stuff out of blin.p6…
Xliff AlexDaniel: I'm agnostic. Let me make these changes and then you can comment on how you want it all to fall into place, however arguing about this stuff now is pointless. 02:26
AlexDaniel namely .dot file and svg generation
ok!
Xliff: %json-data{$name}<bisected> = ~.bisected; 02:28
Xliff: that should work, alternatively we can figure out how to dump the whole object with all attributes 02:29
Xliff Thanks!
02:40 hungrydonkey left 02:42 hungrydonkey joined 02:48 hungryd5 joined 02:49 hungrydonkey left 03:37 upupbb-user3 left 03:45 Xliff left 05:09 sourceable6 left, bloatable6 left, releasable6 left, shareable6 left, quotable6 left, statisfiable6 left, nativecallable6 left, committable6 left, linkable6 left, unicodable6 left, greppable6 left, bisectable6 left, tellable6 left, reportable6 left, evalable6 left, coverable6 left, benchable6 left, squashable6 left, notable6 left 05:10 committable6 joined, notable6 joined, squashable6 joined, greppable6 joined, benchable6 joined, releasable6 joined 05:11 nativecallable6 joined, bisectable6 joined, unicodable6 joined, linkable6 joined, tellable6 joined, coverable6 joined, statisfiable6 joined, reportable6 joined, bloatable6 joined 05:12 sourceable6 joined, quotable6 joined, shareable6 joined, evalable6 joined 05:41 upupbb-user3 joined 06:08 hungryd5 left 06:11 hungrydonkey joined 07:13 dogbert17 left 07:14 dogbert17 joined 07:18 MasterDuke joined 07:37 hungrydonkey left 07:53 sena_kun joined 08:09 sena_kun left 08:24 sena_kun joined
[Tux] Rakudo version 2020.02.1-239-g170add262 - MoarVM version 2020.02.1-47-g3c3ad0678
csv-ip5xs0.688 - 0.711
csv-ip5xs-206.028 - 6.278
csv-parser24.112 - 24.547
csv-test-xs-200.364 - 0.369
test7.516 - 7.524
test-t1.929 - 2.026
test-t --race0.964 - 0.974
test-t-2031.211 - 31.301
test-t-20 --race9.536 - 9.650
 09:13
09:27 sena_kun left 10:16 MasterDuke left 10:18 MasterDuke joined 10:29 AlexDani` joined, AlexDaniel left 10:30 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined 10:36 lizmat joined
lizmat Files=1305, Tests=111219, 205 wallclock secs (28.17 usr 7.94 sys + 2890.99 cusr 269.40 csys = 3196.50 CPU) 10:40
releasable6 Next release in ≈3 days and ≈7 hours. 4 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 11:00
lizmat .ask sena_kun should we just start changing github.com/rakudo/rakudo/wiki/ChangeLog-Draft ? It seems to be for 2020.02 ? 11:24
tellable6 lizmat, I'll pass your message to sena_kun
lizmat bisectable6: sub s () { my @A = 1, { @A[1] } ... * }; s()[1] 11:56
bisectable6 lizmat, Bisecting by exit signal (old=2015.12 new=170add2). Old exit signal: 1 (SIGHUP) 11:57
lizmat, bisect log: gist.github.com/27af4c65f3114050b0...3a3c44dca9 11:58
lizmat, (2017-01-10) github.com/rakudo/rakudo/commit/e1...7eaafbc92b
jnthn bisectable6: 2020.1 HEAD sub s () { my @A = 1, { @A[1] } ... * }; s()[1] 11:59
bisectable6 jnthn, On both starting points (old=2015.12 new=170add2) the exit code is 1 and the output is identical as well
jnthn, gist.github.com/3a6f9259defee6bc15...dee91ea321
jnthn bisectable6: 2020.01 HEAD sub s () { my @A = 1, { @A[1] } ... * }; s()[1]
bisectable6 jnthn, Using old=2020.01 new=HEAD in an attempt to do what you mean
jnthn, On both starting points (old=2020.01 new=170add2) the exit code is 1 and the output is identical as well
jnthn, Output on both points: «This continuation has already been invoked␤ in block <unit> at /tmp/OyLvv5qWxL line 1␤␤»
lizmat R#3570 mentions 87226876a2d06c8 as the last good commit, but that also fails for me ? 12:01
linkable6 R#3570 [open]: github.com/rakudo/rakudo/issues/3570 Lazy lists result in variety of errors, usually fatal
(2020-03-21) github.com/rakudo/rakudo/commit/87226876a2 Convert `nqp::istrue` into `nqp::elems`
lizmat going back to 80f2aebff482da6e6758 , which was the last commit before my work on SEQUENCE, also shows the problem 12:05
linkable6 (2020-03-20) github.com/rakudo/rakudo/commit/80f2aebff4 Fix performance issue on native shaped arrays
12:05 SqrtNegInf joined
SqrtNegInf You are right surely about commit 87226876a2d06c8 12:07
linkable6 (2020-03-21) github.com/rakudo/rakudo/commit/87226876a2 Convert `nqp::istrue` into `nqp::elems`
SqrtNegInf Looking at the timeline again, I think that commit happened after my last pull/build/test cycle 12:08
12:15 MasterDuke left 12:41 MasterDuke joined
Geth nqp: f6eeaf74bf | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get recent OSR fixes
 13:03
13:08 MasterDuke left
Geth rakudo: 35488134c0 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get latest MoarVM OSR fixes
 13:15
rakudo: b7b9358fc5 | (Elizabeth Mattijsen)++ | src/core.c/Seq.pm6
Simplify Seq.Numeric/Int

The code in question would call Seq.elems in the end anyway, so why not do that directly.		 13:26
13:37 MasterDuke joined 13:46 upupbb-user3 left 13:50 squashable6 left 13:53 squashable6 joined
Kaiepi for Trait::Traced, would it be sane to handle tracing of assignments to scalar values by wrapping their container descriptor with a custom one? 13:59
it seems to behave ok with `is copy`, `is raw`, other variables bound to traced variables, but this is a bit out of my realm
lizmat Kaiepi: feels to me that's a valid approach and one of the reasons a container descriptor is just code nowadays, rather then being some hidden C code :-) 14:00
Kaiepi perfect! 14:02
variable and attribute tracing coming soon then (tm)
jnthn Umm....container descriptor is certainly still an impl detail so far as I'm concerned. 14:14
As in, you can do it, but if a future opt breaks it, then it's for you to fix your module.
The reason to write it in high level code, not C, was to make things faster. 14:16
[Coke] loves that that works. :) 14:19
jnthn When your optimizer gets smart enough, it really wants to know everything :)
14:19 lucasb joined 14:24 MasterDuke left
[Coke] I know I said this ages ago about the JVM, but: do we think we'd get any more adoption if we had a .net core backend for Rakudo? 14:31
Geth rakudo: vrurg self-assigned &nextcallee can misbehave with wrapped routines in threaded code github.com/rakudo/rakudo/issues/3569
1e0474d4fc | (Jonathan Worthington)++ | src/Perl6/Actions.nqp

We would elide this for forms made from quote constructs. It's unclear why we did this; there are no spectests whatsoever that depend on such behavior and we'd clobber what was in the $/ in most cases anyway. The real issue this caused, however, was in `m:g/... {}/`, where the `{}` causes a match object sync into `$/`. When it used the outer one, it ... (5 more lines)
[Coke] when I wanted the JVM backend, we eventually ended up avoiding the issue by running in docker when we needed it.
but I wonder if .net core *interop* would be a selling point
14:32 hoelzro joined
lizmat I guess the one to answer the question on technical feasability, would be jnthn, having built 2 VM's and having experience with .Net 14:34
14:37 MasterDuke joined
[Coke] ofc. 14:37
I think for most of my stuff, being able to run moarvm in a docker container if needed is fine.
jdv79 is a .net backend worth it? does anyone use the jvm backend for real? 14:55
timotimo java interop hasn't really been advertised anywhere near enough 14:56
lizmat TIL where TimToady stole :foo syntax from: www.tutorialspoint.com/lisp/lisp_file_io.htm 15:14
jnthn github.com/rakudo/rakudo/issues/3554 is an odd one (trying to debug it, mostly just getting confused...) 15:23
nine Today I've spent several hours trying to debug memory leaks in Inline::Perl5. So far I've failed to identify them. What I have found however was a memory leak in good ol' Data::Dumper: github.com/Perl/perl5/pull/17673 15:35
Has been there since at least 1998 :)
[Coke] nine: Nice! 15:36
nine The other lesson of today is that it is notoriously hard to determine whether something leaks or not. Simple examples reach a plateau within a couple of minutes. 15:38
But do they stay there? Apparently not
I've seen RSS staying constant for such processes for half an hour before they suddenly grew again
That's half an hour of just: raku -e 'use lib:from<Perl5> "t/lib"; use TestMemory:from<Perl5>; loop { test_return_string; }' 15:39
jdv79 how much mem are you seeing leaked and over what time period - i'm assuming in prod?
jnthn Ahhh. It turns out that a /foo/ style regex does *not* get its own $/ - intentionally, but I've no idea *why*. 15:40
nine A simple REST API implemented using Cro and Inline::Perl5 grows to > 6 GiB after just 20K requests 15:41
jnthn Giving it its own one does fix the issue.
15:41 Kaiepi left, Kaiepi joined
jnthn But now I need to see what the spectests think of that, 'cus surely that was being elided for a reason... 15:41
jdv79 nine: that's crazy 15:42
jnthn nine: Does the leak go away with Inline::Perl5 isn't used? 15:43
`make test` passes with the "give /foo/ its own $/" match, now for spectest... 15:45
15:46 sena_kun joined, sena_kun left 15:47 sena_kun joined
nine If it were easy to remove Inline::Perl5 we wouldn't use it at all :) But the frontend application uses it much less and also leaks much less. 15:47
[Coke] match, now for spectest... 15:48
11:47 < nine> If it were easy to remove Inline::Perl5 we wouldn't use it at all :) But the frontend application uses it
Oops. managed to cut and paste instead of scroll down. :)
jnthn nine: ooc, did you look at how often it's doing full collections and maybe at the decision making around github.com/MoarVM/MoarVM/blob/mast...ate.c#L396 if that looks a bit off? 15:54
nine not yet 15:55
400M RSS and only one full collection so far 16:10
That was on GC run 2698 (currently > 7K runs) 16:11
Second full collection at GC run 11553 16:14
700M RSS
jnthn Hm, seems I can fix #3554 without any broken spectests by simply deleting some code... :) 16:15
MasterDuke wonders if jnthn++ can turn that into a streak, and if so, how many bugs he can solve by just deleting code... 16:18
nine all of them!
roast: 200f41af68 | (Jonathan Worthington)++ | S05-modifier/global.t
Test m:g/... { code block }/ gets the $/ correct

Covers github.com/rakudo/rakudo/issues/3554.
16:26 Altai-man_ joined
jnthn That took longer to find than I'd have hoped... 16:27
16:28 sena_kun left
[Coke] jnthn++ 16:29
nine jnthn: forcing a full collection every 100 GC runs does help quite a bit with ~530M RSS at GC run 12K compared to 700M before 16:30
I find it odd that we keep promoting objects when the program is just: use lib:from<Perl5> "t/lib"; use TestMemory:from<Perl5>; loop { TestMemory.new; } 16:31
Do we have a working memory profiler again? 16:37
[Coke] does the promotion only happen with that module? (I assume it's hanging on to a ref somewhere?) 16:39
nine TestMemory.new is just: sub new { return bless {}; } 16:40
[Coke] O_o; 16:43
MasterDuke nine: i've used heaptrack successfully before, but it only gives information at the moarvm level 16:49
nine MasterDuke: github.com/KDE/heaptrack? 16:53
MasterDuke yep
16:54 unclechu joined, rba[m] joined
jnthn nine: Is --profile=heap and looking at the output broken, or just too much data to be useful? 16:55
uh, using the analysis tool to look at the output
16:56 CIAvash joined
MasterDuke i usually use --full_cleanup so the leaked numbers are better, but programs don't always exit cleanly with it. at one point i spent a little while trying to figure out what was causing the problem, but i don't understand those parts of moarvm well enough 16:56
btw, it's --profile-kind=heap now 16:57
nine Oh, got it to work with --profile=testmemory.mvmheap 16:59
MasterDuke oh right, i think timotimo suggested (and i guess i implemented?) setting the kind based on the filename 17:00
17:05 MasterDuke left
Geth rakudo: vrurg self-unassigned &nextcallee can misbehave with wrapped routines in threaded code github.com/rakudo/rakudo/issues/3569
49d1dcd30c | (Jonathan Worthington)++ | src/Perl6/Optimizer.nqp

We know that is always decontainerized already.		 17:18
Altai-man_ releasable6, status 17:23
releasable6 Altai-man_, Next release in ≈3 days and ≈1 hour. 5 blockers. Changelog for this release was not started yet
Altai-man_, Details: gist.github.com/a4f0a0822d7bcf2de2...8b8364dbb3
nine This is interesting: according to moar-ha the heap size stays pretty much the same between 48,009,681 and 48,087,105 bytes yet according the the GC debug output, we promote bytes to gen2 all the time 17:24
jnthn nine: Interesting. So is the heap profile missing a reachable thing, or not accounting for something unmanaged that is growing, or are we actually mismanaging memory somewhere that causes us to eat more even when the volume of reachable object isn't growing? 17:26
(Not asking 'cus you'll know, just wondering out loud...) 17:27
nine 40M of heap already sounds suspicious in a program with 240M RSS 17:29
17:34 FROGGS joined 17:48 MasterDuke joined
MasterDuke vrurg: spesh is not really my area of expertise, jnthn is probably the best bet (re R3569) 17:50
R#3569
linkable6 R#3569 [open]: github.com/rakudo/rakudo/issues/3569 [BLOCKER][MoarVM][regression] &nextcallee can misbehave with wrapped routines in threaded code
vrurg MasterDuke: remind me, pls, does MVM_SPESH_DISABLE does something to moar itself? Or it's only turns off spesh plugin invokation? 17:51
MasterDuke i think it turns off more than just the plugins, but i'm not 100% sure of that 17:52
nine It turns off all of spesh (including the JIT) 17:53
We do not collect any statistics and do not start the spesh thread
vrurg JIT isn't guilty, this I tested. Ok, it does look like I need somebody with spesh expertise to look at 3569. 18:03
SqrtNegInf t 18:13
18:17 leont joined 18:27 sena_kun joined 18:29 Altai-man_ left 18:48 squashable6 left 18:50 Altai-man_ joined 18:51 squashable6 joined 18:53 sena_kun left
MasterDuke vrurg: i don't really understand your recent dispatcher changes, but in src/spesh/facts.c there is a case for nextdispatcherfor and in src/spesh/inline.c there is a case for takenextdispatcher. why don't both those files have both cases? 19:06
lizmat jnthn: re 49d1dcd30c reminds me on how difficult it would be to add (--> self) as allowable in a signature 19:11
linkable6 (2020-03-25) github.com/rakudo/rakudo/commit/49d1dcd30c Optimize out return decont check on returning self
AlexDaniel lizmat: is linkable useful or annoying in cases like this? 19:12
lizmat just fine as far as I'm concerned...
MasterDuke i like it
AlexDaniel btw it supports all repos
lizmat AlexDaniel++ # didn't know that 19:13
MasterDuke i did notice that yesterday when i posted a count from a spesh log and it linked to some repo i'd never heard of
AlexDaniel hahaha
colabti.org/irclogger/irclogger_lo...-03-24#l70 19:14
haha
yeah I should probably make it ignore all-numeric shas that are weirdly too long 19:15
it already does that, if I'm not mistaken, just not enough I guess
vrurg MasterDuke: because I was half-blindly cloning what was done for setdispatcherfor/takedispatcher 19:19
MasterDuke hm, probably need jnthn, timotimo, or nine to take a look 19:20
vrurg MasterDuke: What I did not understand I didn't do.
MasterDuke: most likely. 19:22
19:42 MasterDuke left
Geth rakudo: 136087e774 | (Ben Davies)++ | src/core.c/control.pm6
Correct error string passed to nqp::p6finddispatcher in &nextcallee
 19:53
19:55 MasterDuke joined, MasterDuke left, MasterDuke joined
Geth rakudo: 0f97a7f5fe | (Elizabeth Mattijsen)++ | src/core.c/Seq.pm6
Remove undocumented Seq.new-consumed

And replace it with a Seq.new() candidate. Its existence was only needed to create an EVALlable representation of a Seq of which the iterator had already been taken. This created a documentation issue, as the method was *not* an implementation detail. Yet documenting it would only cause more questions, as it strayed very ... (9 more lines)		 20:03
roast: 80326a9742 | (Elizabeth Mattijsen)++ | S24-testing/9-is_deeply.t
Adapt Seq.new-consumed tests

To follow github.com/rakudo/rakudo/commit/0f97a7f5fe		 20:04
20:16 squashable6 left 20:17 squashable6 joined 20:25 camelCaser left 20:26 camelCaser joined 20:29 SqrtNegInf left 20:37 MasterDuke left 20:41 FROGGS left 20:51 sena_kun joined 20:53 Altai-man_ left 21:04 MasterDuke joined 21:07 patrickb joined 21:29 lucasb left 21:33 leont left
patrickb .tell rba I have a new rakubrew release: version 7. As always patszim.volans.uberspace.de/patclo...EJLQDZcjbf Can you upload? 21:38
tellable6 patrickb, I'll pass your message to rba
21:40 patrickb left 21:48 upupbb-user3 joined 21:59 upupbb-user3 left 22:44 patrickb joined
patrickb .tell rba I just uploaded a last minute bugfix release of rakubew: version 8. Can you upload both releases (7 and 8)? Same URL. Thank you! 22:45
tellable6 patrickb, I'll pass your message to rba
patrickb tadzik: Rakubrew is (slowly) getting to the point of working reliably. What's your stance wrt rakudobrew? Should it officially be deprecated? 22:48
tellable6 patrickb, I'll pass your message to tadzik
22:49 patrickb left 22:50 Altai-man_ joined 22:53 sena_kun left 23:29 Kaiepi left 23:32 Kaiepi 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!