00:21 leont left 01:34 Altai-man_ joined 01:37 sena_kun left 01:47 hankache joined 01:52 hankache left 03:35 sena_kun joined 03:37 Altai-man_ left 05:34 Altai-man_ joined 05:37 sena_kun left 07:35 sena_kun joined 07:37 Altai-man_ left 08:10 discord6 left, discord6 joined, discord6 left, discord6 joined 08:24 domidumont joined 08:31 leont joined 08:37 domidumont left 08:52 titsuki joined
|Tux| Rakudo version 2020.02-76-geb19a3d2e - MoarVM version 2020.02-25-g69951892a
csv-ip5xs0.696 - 0.702
csv-ip5xs-205.791 - 5.798
csv-parser23.234 - 23.632
csv-test-xs-200.363 - 0.370
test7.527 - 7.857
test-t1.841 - 1.873
test-t --race0.781 - 0.812
test-t-2030.667 - 31.400
test-t-20 --race8.871 - 8.900
 09:16
09:18 titsuki left 09:34 Altai-man_ joined 09:37 sena_kun left 09:40 titsuki joined 10:00 hankache joined 11:10 |Tux| left 11:16 |Tux| joined
lizmat Files=1304, Tests=111210, 207 wallclock secs (28.50 usr 8.33 sys + 2914.57 cusr 271.56 csys = 3222.96 CPU) 11:24
tellable6 2020-02-27T23:29:37Z #raku-dev <vrurg> lizmat Here is the gist: gist.github.com/vrurg/7f190ded041b...57576dbc4e ; interesting that I can only reproduce it with classes.
lizmat that's a 3 second drop with the latest MoarVM optimizations, sadly not visible in the test-t numbers :-( 11:25
11:35 sena_kun joined 11:37 Altai-man_ left 12:16 hankache left 12:25 lucasb joined 12:53 Voldenet left 13:09 Voldenet joined, Voldenet left, Voldenet joined
Geth rakudo: ffcc61986b | (Patrick Böker)++ | tools/build/binary-release/build-windows.ps1
Fix two errors in CircleCI Windows release build script
 13:17
13:34 Altai-man_ joined 13:37 sena_kun left
lizmat looking at gist.github.com/lizmat/5b060be7ac0...79fdea3719 13:44
is that sane? loading the .c setting *and* the .d setting?
I was under the impression that loading setting.d would be enough to get 6.d semantics?
jnthn nine ^^ ? 13:45
jnthn .o( Why does that text pluralize settings when it's asking for one? ) 13:46
Yes, it's correct, because 6.d is built atop of 6.c
lizmat hmmm... so the 6.d setting file is *not* 6.c + 6.d, but they need to be merged at every startup ? 13:47
jnthn There's not much in the way of merging going on, it's just that 6.c is the setting for the 6.d setting 13:48
e.g. it's all just lexical scopes 13:49
It's like `my $a; if 1 { my $b; }` and inside the block you can see $a and $b, but I don't think we'd say they're merged. Or at least, I wouldn't. :)
But yes, the 6.d setting file is just the 6.d additions
Were it not, we'd have all sorts of problems (like a 6.d Int not being a 6.c Int)
tbrowder i'm lobbying for a quick resolution for my rakudo PR #3615 to enable env var RAKULIB so we can get in the next release and advertise it in the docs. the PR has become a bit entangled with the status of RAKUDOLIB which is holding up approval. i believe the PR should be able to be approved by treating the RAKUDOLIB issue separately. 13:50
see my comment just added to vrug's problem-solving issue mentioned above. 13:52
lizmat jnthn thanks for the explanation 13:55
afk for a few hours& (before it really starts to rain) 13:56
14:23 titsuki left 15:08 patrickb joined 15:20 patrickz joined 15:36 sena_kun joined 15:37 Altai-man_ left 15:39 titsuki joined
Kaiepi releasable6, status 16:10
releasable6 Kaiepi, Next release in ≈29 days and ≈2 hours. 1 blocker. Changelog for this release was not started yet
Kaiepi, Details: gist.github.com/4a27e2a16411fd6ec1...a000d83eb7
Kaiepi sweet 16:11
*poke* github.com/rakudo/rakudo/pull/3491 github.com/rakudo/rakudo/pull/3451 16:12
16:16 patrickz left
patrickb rba: I have created precomp archives for the 2020.02 release. Can you put them on rakudo.org? (as usual: patszim.volans.uberspace.de/patclo...JLQDZcjbf) 16:17
tellable6 2020-02-25T14:39:33Z #raku-dev <rba> patrickb: Got the message. Will try using msvc later this week.
2020-02-26T15:22:46Z #raku-dev <rba> patrickb: Playing around with Azure DevOps Pipelines. May this be something we like to have a look together?
rba patrickb: Sure. put them. 16:19
patrickb: hankache is building using gcc from strawberry perl. So what is better msvc or gcc for Windows? 16:21
patrickb rba: Some time ago I had a discussion with ugexe about this. I can see if I manage to dig it up again. 16:22
rba patrickb: In irc? Might be in the logs. 16:23
patrickb rba: Unsure. Might also have been in some GitHub ticket
rba patrickb: Other topic. Azure DevOps Pipelines have no limits for public projects. 16:24
patrickb: dev.azure.com/infra0037/raku 16:25
patrickb I have taken a short look at those earlier today. They do seem attractive (by being limitless). 16:26
rba patrickb: I realised that I had to learn what software is offered on the specific build agent image first. Took me a while... 16:27
patrickb: I'm open for discussion. Just think we need to somehow align all the different build automation. 16:28
patrickb: And I like to make sure a release is built exacltly the same way each time and more important it's built for all the platform based on the exact same source code. 16:29
patrickb Thing is I just finished setting up the build pipeline with CircleCI. I'm still waiting for the CircleCI support team to fix up the problem with Windows builds not working, but apart from that it's working.
rba patrickb: What are the windows build problems on circle-ci? May I see? 16:30
patrickb My motivation to start from the beginning and get it set up on a different platform is kind of low at the moment. :-/
I do think it's a good idea and we should really have a good look though!
rba patrickb: I have played with star build on AzurePipelines: github.com/rba/build-rakudo-star/b...elines.yml 16:31
patrickb Problem with Windows builds: github.com/rakudo/rakudo/issues/3462 16:32
rba patrickb: So the problem actually is the limit in circle-ci. 16:53
patrickb rba: Yes, but it seems they mis-count the credits somehow as we don't do any other Windows builds. I have been in contact with CircleCI support for several weeks now and it's possible they fix it. 16:56
rba patrickb: Got it.
patrickb Still azure pipelines seem very attractive as they are unlimited. :-)
rba patrickb: And you can build on linux and macos as well. So kind of similar to circle-ci. 16:57
patrickb True. As already said, I'm all for it, it's just that I'm currently not really motivated to go through all this again. 16:58
tbrowder vrug: rakudo PR #3516 has been updated 17:01
patrickb: rakudo PR #3516 has been updated
rba patrickb: I have holiday next week and I might work on it after skiing. Just want to collect details about how to build on the different platforms. 17:03
patrickb: And I don't like to take build thing out of someone else's hands. 17:04
patrickb: Let me know if you find the discussion with ugexe about gcc/msvc. And if I managed something next week I will come back anyway... 17:05
patrickb rba: I asked El_Che about the very same thing and he told me that he is not territorial about this and more different solutions are a good thing.
I feel the same. So go ahead! 17:06
rba: I think most of the knowledge I have of how building for the respective platforms works is encoded in the tools/build/binary-release/build-* scripts. So maybe they can be of help. 17:07
rba patrickb: I took a look at this already. Is it right that the main ci is still travis on rakudo? 17:08
patrickb rba: It's difficult to say. We started with travis, then appveyor and CircleCI joined the merry group. Currently we are testing things redundantly. I think it's difficult to say what makes a system the "main" one. 17:10
I do think we shouldn't do redundant testing though. That's simply a waste of resources. So rather sooner than later either Travis or CircleCI should go. 17:11
sena_kun releasable6, status 17:31
releasable6 sena_kun, Next release in ≈29 days and ≈1 hour. 1 blocker. Changelog for this release was not started yet
sena_kun, Details: gist.github.com/1382d39bd7eff2bb6e...0a9118c173
17:34 Altai-man_ joined 17:36 Kaiepi left 17:37 sena_kun left 17:40 Altai-man_ left 17:41 sena_kun joined 17:51 sena_kun left 17:52 sena_kun joined
lizmat jnthn: this kept playing in my head when cycling: It's like `my $a; if 1 { my $b; }` and inside the block you can see $a and $b 18:05
and "we'd have all sorts of problems (like a 6.d Int not being a 6.c Int)"
I'm not sure how these two statements can be reconciled 18:06
I mean, Int in the outer is the same as Int in the inner, is it not ?
jnthn I meant: if you took all of the sources for the 6.c setting and compiled them, then took those again, added the 6.d stuff, and compiled it afresh, then you'd have the problem. 18:07
18:09 titsuki left
lizmat hmmm... 18:12
vrurg nine the precomp breakage is caused by c909258273b09c526463b68d22 18:26
linkable6 (2020-02-24) github.com/rakudo/rakudo/commit/c909258273 Avoid re-resolving the same dependencies multiple times
18:32 Kaiepi joined
Geth rakudo: e6044dfcd2 | (Patrick Böker)++ | tools/build/update-submodules.pl
Fix buiding when git reference dir has spaces in its path
 18:45
rakudo: 358c5a810f | (Patrick Böker)++ | tools/build/update-submodules.pl
Code aesthetics: Don't unnecessarily escape " in a build script
 18:47
nqp: 7c261f2c78 | (Patrick Böker)++ | tools/build/update-submodules.pl
Fix buiding when git reference dir has spaces in its path

And fix two typos		 18:48
sena_kun patrickb, o/ 18:57
patrickb o/ sena_kun
I was just about to leave...
but feel free to .tell me 18:58
I'll backlog
18:58 patrickb left
sena_kun .tell patrickb as you updated the dyncall, I think you're the fitting person to ask about some further help with it. The new revision doesn't play well with musl and we have a couple of fixes for it. If you can cherry-pick dyncall.org/pub/dyncall/dyncall/re...64957d6a46 and dyncall.org/pub/dyncall/dyncall/re...82a00c2177 in a PR that will be awesome, as it unbreaks the alpine builds for next releases. 19:01
tellable6 sena_kun, I'll pass your message to patrickb
lizmat vrurg nine 6956c0633357dffd26f665 actually is the breakage, c909258273b09c526463b68d22 was the last correct one 19:11
linkable6 (2020-02-24) github.com/rakudo/rakudo/commit/6956c06333 Avoid looking up the same precomp id multiple times
(2020-02-24) github.com/rakudo/rakudo/commit/c909258273 Avoid re-resolving the same dependencies multiple times
vrurg lizmat: I hope they can be improved? 19:19
lizmat yeah... :-) 19:24
but first: making sure we haz a working precomp 19:25
Geth rakudo: e756e622ab | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Make diamond relation in modules work in precomp again

  vrurg++ for providing the example that broke. nine++ for coming
up with the idea to make things faster. Too bad it didn't work out.
This reverts commit 6956c0633357dffd26f665569c8cd8f34d9795e1.		 19:34
19:35 Altai-man_ joined 19:38 sena_kun left 19:39 Kaiepi left 19:40 Kaiepi joined
vrurg lizmat++ 19:43
lizmat glad that I was correct that I couldn't understand that my changes had broken things
vrurg is going into the MoarVM waters again... :( 19:50
I either get a new op or I implement rather weird manipulations with dynamics in method code. :( 19:51
20:05 lucasb left
Geth roast: 381b5ed859 | (Elizabeth Mattijsen)++ | 6 files
Add tests for diamond precompilation

As given by vrurg++ to show where precompilation broke		 20:12
roast: 0761b45fa1 | (Elizabeth Mattijsen)++ | spectest.data
Make sure we run the precomp diamond test
lizmat afk for a bit&
nine lizmat: you reverted a different commit to the one you pointed out to cause the breakage? 20:13
Ah, just saw it in the backlog. 20:14
Now I'm quite happy that I split my changes into two commits :) 20:15
Altai-man_ goes blin 20:22
20:24 domidumont joined 20:36 domidumont left
dogbert17 lizmat: did you ever merge your reimagined sprintf implementation? 21:12
japhb lizmat: Here was the minified script I used to recreate the Test::Mock failure: gist.github.com/japhb/8588c009de25...9cae15e905
However, I ran that before heading to lunch (just minutes before you did the diamond relation related revert. 21:13
So I'll try again with HEAD as of now
Failed again. Different failure mode this time (gist updated), but still one of the failure modes I've seen while trying the last couple days. 21:22
This one was 'double free or corruption (!prev)'
jnthn huh, those both look like race symptoms 21:30
The test probably covers when the monitor was added here: github.com/jnthn/test-mock/blob/ma...ock.pm6#L4 21:31
dogbert17 ied with the exception: 21:32
Array may not be used concurrently
in method log-method-call at /home/dogbert/repos/test-mock/lib/Test/Mock.pm6 (Test::Mock) line 8
jnthn It's in a monitor, it can't possibly be used concurrently, unless a change has broken OO::Monitors 21:33
21:36 sena_kun joined
dogbert17 FWIW gist.github.com/dogbert17/d2a4d8c6...c084b2e65f 21:36
also note: #define MVM_ARRAY_CONC_DEBUG 1 21:37
21:38 Altai-man_ left
dogbert17 I have OO::Monitors:ver<1.1.1> 21:38
japhb posits that a change has in fact broken OO::Monitors, but its local tests don't catch whatever failure mode it is 21:48
dogbert17
.oO(are we being mocked by OO::Monitors)
 21:49
jnthn japhb: I've negative time to look into it at the moment, but it'd be my first guess too
I wonder if vrurg++'s changes to delegation - which I believe it uses - could possibly have done it...
japhb Yeah, understood.
Oh, that's an interesting idea 21:50
lizmat dogbert17: no, it went back to the drawing board, soon to be revidited 21:53
*revisited
dogbert17 ah, thx for the info
lizmat is tired and gets some sleep& 22:32
23:35 Altai-man_ joined 23:37 sena_kun left 23:41 cognomin_ joined 23:45 cognominal 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!