00:55 Kaeipi joined 00:56 Kaeipi left
Geth rakudo: Leont++ created pull request #4063:
Construct CUR::Distribution correctly in CU!WHICH		 00:58
roast: vrurg++ created pull request #704:
Add tests for nominalizables		 01:24
01:38 lucasb left 01:44 leont_ left
Geth rakudo: d37906d039 | (Vadim Belman)++ (committed using GitHub Web editor) | 8 files
Implement metmodel transparency of nominalizables (#4058)

As a matter of fact, a nominalizable is a wrapper around a nominal or another nominalizable. As such, it makes sense to have their MOP classes transparent, similar to how their typeobjects are transparent down to the final nominal type. I.e., it means that for
   role R[::T] {
   my subset RS of T;
   method foo(RS() $v) {...}
... (14 more lines)		 03:50
linkable6 RAKUDO#4058 [closed]: github.com/rakudo/rakudo/pull/4058 [type captures] Implement metmodel transparency of nominalizables
roast: e6dfbaff2b | (Vadim Belman)++ | 2 files
Add tests for nominalizables

Test for subsetting a coercion and nested coercers.
In support of rakudo/rakudo#4058
roast: 79bd3ecb5f | (Vadim Belman)++ (committed using GitHub Web editor) | 2 files
Merge pull request #704 from vrurg/rakudo_2446

Add tests for nominalizables		 03:51
04:26 Kaiepi joined 06:33 sena_kun joined
Geth rakudo: 7d0813c3a0 | (Leon Timmermans)++ | src/core.c/CompUnit.pm6
Construct CUR::Distribution correctly in CU!WHICH

Without this $compilation-unit.perl fails with
  «Too few positionals passed; expected 2 arguments but got 1»		 07:14
rakudo: 2a44729d61 | niner++ (committed using GitHub Web editor) | src/core.c/CompUnit.pm6
Merge pull request #4063 from Leont/compunit-which

Construct CUR::Distribution correctly in CU!WHICH
08:11 Altai-man joined 08:13 sena_kun left 09:47 MasterDuke joined
Geth rakudo/fix-compiler-services-concurrency-issue: d0de76647f | (Stefan Seifert)++ | src/Perl6/World.nqp
Fix unwanted references to other compilations by CompilerServices

CompilerServices used several lexical variables to store often used supposedly constant QAST nodes and hashes. Turns out these nodes do get modified, i.e. references get added or maybe it's just that they get added to a serialization context. Anyway turning them into attributes and initializing them newly for every compilation fixes issues with references to outer compiler's SCs.
This not only affects cases where multiple comp units are precompiled in the same process but also cases where multiple compilations run in parallel.		 10:27
rakudo: niner++ created pull request #4064:
Fix unwanted references to other compilations by CompilerServices		 10:28
rakudo: b58510ffc2 | (Stefan Seifert)++ | src/core.c/Process.pm6
Fix RAKUDO_MODULE_DEBUG output when the message contains meta characters
 10:37
rakudo: 3d4634199b | (Stefan Seifert)++ | src/core.c/IO/Spec/Unix.pm6
Revert "[io grant] Make IO::Spec::Unix.splitdir 7.7x faster"

This reverts commit 6ca702fa3d6caff5c094a08cd016dde94d34e77d.
While faster, the commit made splitdir also return a List instead of a Seq and not just a List but always the same List object leading to action at a distance issues.		 10:38
rakudo/fix-name-of-stub-packages: aab4f55a7f | (Stefan Seifert)++ | src/core.c/Stash.pm6
Give stub packages created by package_at_key a proper longname

Stub packages created by simply accessing them like &Foo::Bar::note = sub { }; only got the last part of their name ("Bar"). Now they know who they really are
  (Foo::Bar).		 10:40
rakudo: niner++ created pull request #4065:
Give stub packages created by package_at_key a proper longname
lizmat bisectable6: dd IO::Spec::Unix.splitdir("foo/bar").^name 11:02
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, Output on all releases: gist.github.com/a18753ee998838fea8...979b6f17d4
lizmat, bisect log: gist.github.com/eca76a710f104a3008...dddbd4a7d6
lizmat, bisect log: gist.github.com/8650f28c7c87c88089...4597a475d6
lizmat, Output on all releases and bisected commits: gist.github.com/cec541881d86ef9bca...47f46d2252
lizmat bisectable6: old=2016.01 dd IO::Spec::Unix.splitdir("foo/bar").^name 11:03
bisectable6 lizmat, Bisecting by output (old=2016.01 new=3d46341) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/a78f604e9a268fe7de...0b32662a43 11:04
lizmat, (2020-11-28) github.com/rakudo/rakudo/commit/3d...ea51e45244
AlexDaniel` 6c: dd IO::Spec::Unix.splitdir("foo/bar").^name 11:05
11:05 domidumont joined
AlexDaniel` yeah, bisectable does it a bit differently… and it's wrong :) 11:05
committable6 AlexDaniel`, gist.github.com/a880397d9d0628a9cd...cbd582aea5
AlexDaniel` that is much clearer 11:06
Geth rakudo: f154244c6e | (Elizabeth Mattijsen)++ | 3 files
Properly fix improper use of () in p6bindattrvinres

  () is *NOT* a new instance of the empty List, it *is* the empty List
and should as such not be used to put things into. The reason this wasn't spotted before, is probably because this functionality is not used an awful load in most use cases. Spotted by Stefan Seifert++		 11:08
lizmat *lot *sigh* :-)
11:16 domidumont1 joined 11:18 domidumont left
Geth rakudo: dumarchie++ created pull request #4067:
Accept Mu as cas target and values		 11:47
12:12 sena_kun joined 12:14 Altai-man left 12:25 raku-bridge joined, raku-bridge left, raku-bridge joined
Geth rakudo/fix-concurrent-heredoc-compilation: 147bae3bbc | (Stefan Seifert)++ | 2 files
Fix concurrency issue in compilations with heredocs

Using a lexical variable for the herestub queue could lead to all sorts of unwanted sharing between indepenedent compilations and could lead to errors in parallel compilations. Put it into the World instead to avoid sharing.		 12:27
rakudo: niner++ created pull request #4068:
Fix concurrency issue in compilations with heredocs
rakudo: d0de76647f | (Stefan Seifert)++ | src/Perl6/World.nqp
Fix unwanted references to other compilations by CompilerServices

CompilerServices used several lexical variables to store often used supposedly constant QAST nodes and hashes. Turns out these nodes do get modified, i.e. references get added or maybe it's just that they get added to a serialization context. Anyway turning them into attributes and initializing them newly for every compilation fixes issues with references to outer compiler's SCs.
This not only affects cases where multiple comp units are precompiled in the same process but also cases where multiple compilations run in parallel.		 12:29
rakudo: e90ed75796 | niner++ (committed using GitHub Web editor) | src/Perl6/World.nqp
Merge pull request #4064 from rakudo/fix-compiler-services-concurrency-issue

Fix unwanted references to other compilations by CompilerServices
12:41 leont_ joined 13:46 lucasb joined
Geth rakudo: Altai-man unassigned from vrurg Issue Performance regression after merge of new coercion semantics github.com/rakudo/rakudo/issues/4056
147bae3bbc | (Stefan Seifert)++ | 2 files

Using a lexical variable for the herestub queue could lead to all sorts of unwanted sharing between indepenedent compilations and could lead to errors in parallel compilations. Put it into the World instead to avoid sharing.		 14:05
rakudo: 22c4bb5cd7 | niner++ (committed using GitHub Web editor) | 2 files
Merge pull request #4068 from rakudo/fix-concurrent-heredoc-compilation

Fix concurrency issue in compilations with heredocs
14:52 leont_ is now known as leont 15:00 domidumont joined 15:03 domidumont1 left 15:16 domidumont1 joined, domidumont left
Geth nqp/fix-multithreaded-mixins: b46a4cacb5 | (Stefan Seifert)++ | src/how/NQPClassHOW.nqp
Make mixins concurrency safe

Multiple threads creating mixins on the same type of object could step on each other's toes as the mixin cache was not protected against concurrent access. Instead of adding locks, we now use the VM's parameterization mechanism, which is already concurrency safe and used for mixins in Rakudo.
Fixes "Iteration past end of iterator" when running: raku -e '(^10000).race.map({EVAL "q[];\n"}).sink'		 15:35
nqp: niner++ created pull request #684:
Make mixins concurrency safe
nine Found that when trying my heredocs concurrency fix.
I may not have succeeded with in-process precompilation, but at least I gained a pretty solid understanding of parametrics and mixins on the way :) 15:36
15:37 leont left 15:39 leont joined
sena_kun nine++ # nice fixes 15:44
15:49 leont left
MasterDuke nine: not succeeded yet? or think it's not reasonably possible? 15:49
nine I've given up last Sunday. I was stuck in a perpetual circle of "fix one case, break another" 15:51
MasterDuke ah
15:52 leont joined
Geth nqp/fix-multithreaded-mixins: 6449effe24 | (Stefan Seifert)++ | src/how/NQPClassHOW.nqp
Make mixins concurrency safe

Multiple threads creating mixins on the same type of object could step on each other's toes as the mixin cache was not protected against concurrent access. Instead of adding locks, we now use the VM's parameterization mechanism, which is already concurrency safe and used for mixins in Rakudo.
Fixes "Iteration past end of iterator" when running: raku -e '(^10000).race.map({EVAL "q[];\n"}).sink'		 15:53
nine ^^^ same commit sans the commented code. MasterDuke++
MasterDuke nine: does ^^^ fix any todos in roast? there are a lot of rakudo issues that mention EVAL and/or race/hyper 15:54
Geth nqp: 630bc1d19c | (Nicholas Clark)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get changes since 2020.11

This brings in these pull requests:
1c7358004 Merge pull request #1350 from MoarVM/hash-single-allocation f3e9e356d Merge pull request #1390 from MoarVM/exception-in-spesh-should-oops bfce05394 Merge pull request #1331 from Kaiepi/lego-jit-rv ... (6 more lines)		 15:55
nine maybe, but there are definitely issues left
nwc10 however, I don't have permission to push to rakudo/rakudo 15:59
16:00 leont left 16:03 leont joined
Geth rakudo: 998cae5749 | (Peter du Marchie van Voorthuysen)++ | src/core.c/atomicops.pm6
Accept Mu as cas target and values
 16:03
rakudo: 1ccfb095d1 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/atomicops.pm6
Merge pull request #4067 from dumarchie/cas-target

Accept Mu as cas target and values
16:11 Altai-man joined
dogbert17 will lizmat do the lat piece of the bump process? 16:11
*last
lizmat sure 16:12
dogbert17 yay
lizmat just NQP I guess
dogbert17 yup
16:13 sena_kun left
lizmat building and spectesting now 16:14
nine nwc10: you sure, 2020.11-71 is correct? I only get 2020.11-47 on master 16:15
lizmat yeah, I saw that as well, yet NQP and Rakudo appear to build fine with that describe 16:16
Previous HEAD position was 058b8377b Bump VERSION for release 16:17
HEAD is now at fecfad191 Add `MVM_index_hash_allocated_size` for MVMStaticFrame's `unmanaged_size`
linkable6 (2020-11-21) github.com/MoarVM/MoarVM/commit/058b8377b7 Bump VERSION for release
nine I get Found /home/nine/rakudo/install/bin/moar version 2020.11-47-g1c7358004, which is too old. Wanted at least 2020.11-71-gfecfad191 at /home/nine/rakudo/nqp/3rdparty/nqp-configure/lib/NQP/Config.pm line 192.
lizmat so, should I rebump NQP ? 16:18
nine please
lizmat oki 16:19
hmmm.... my NQP now says: 16:20
No --prefix supplied, building and installing to /Users/liz/Github/nqp/install
Found /Users/liz/Github/nqp/install/bin/moar version 2020.11-71-gfecfad191, which is new enough.
nine ???
But, there are only 47 commits between 2020.11 and master in MoarVM? 16:21
lizmat maybe a too-high a value will just use HEAD ?
still rebump NQP ? 16:22
dogbert17 could the difference somehow be connectet to: MoarVM/hash-bits-in-metadata: 24 commits pushed by (Nicholas Clark)++ 16:23
nine I don't understand this
lizmat those commits are not listed in the list of PRs merged 16:24
in the NQP commit
but I guess they were in nwc10's checkout
[Tux] Err, not good
sh: line 1: 28112 Segmentation fault (core dumped) raku -Ilib csv-parser.pl < empty.csv 2> /dev/null
lizmat I'll bump NQP back 16:25
[Tux] and the last warning I see:
3rdparty/libuv/src/unix/linux-core.c:381:10: warning: ‘user_timeout’ may be used uninitialized in this function [-Wmaybe-uninitialized]
if (timeout == 0)
^
Geth nqp: 87ee9469d7 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Correctly bump MoarVM
[Tux] src/core/interp.c:3318:36: warning: variable ‘coderef’ might be clobbered by ‘lo ngjmp’ or ‘vfork’ [-Wclobbered]
MVMObject *coderef;
^~~~~~~
Unhandled exception in code scheduled on thread 4 16:26
Unhandled exception in code scheduled on thread 7
This type (Int) does not support positional operations
all kinds of everything
lizmat yeah, that feels... wrong 16:27
[Tux] 3rdparty/libuv/src/unix/process.c:144:7: warning: implicit declaration of functi on ‘pipe2’; did you mean ‘pipe’? [-Wimplicit-function-declaration]
if (pipe2(fds, flags | O_CLOEXEC))
^~~~~
pipe
I'll skip this timing then
lizmat yeah, gimme 10 mins or so
[Tux] ok, I'll see if I remember to try again :) 16:28
lizmat nukes install dir to be sure 16:29
dogbert17 nine: have you managed to get hold of a new Ryzen CPU yet? They seem to be in short supply. 16:33
nine No, I guess it'll take another month 16:34
dogbert17 have you decided on which parts you'll get, i.e. MB, cpu-model etc? 16:35
Geth rakudo: 1b26983199 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get latest MoarVM goodies
lizmat [Tux]: ^^ 16:36
afk for dinner&
nine I'll go for the 5950X, but don't know which board yet
dogbert17 a 16 core monster :-) your compile and spectest timings will be way down 16:39
nine I figure it will have about 4 times the oomph of my 1800X 16:42
16:42 travis-ci joined
travis-ci NQP build passed. Elizabeth Mattijsen 'Correctly bump MoarVM' 16:42
travis-ci.com/Raku/nqp/builds/205041375 github.com/Raku/nqp/compare/630bc1...ee9469d717
16:42 travis-ci left 16:43 travis-ci joined
travis-ci Rakudo build failed. niner 'Merge pull request #4064 from rakudo/fix-compiler-services-concurrency-issue 16:43
travis-ci.org/rakudo/rakudo/builds/746417770 github.com/rakudo/rakudo/compare/f...0ed7579677
16:43 travis-ci left
dogbert17 that's a very nice improvement 16:45
16:48 leont left
nwc10 nine: I'm confident that I goofed 16:55
2020.11-47-g1c7358004 was what I had locally, but I failed to realise that I had not ammended my local commit (properly) before pushing it 16:58
as in, did `git commit --amend` but had not done `git add` before
thanks for fixing this 16:59
17:05 leont joined
lizmat nwc10: you're welcome :-) 17:05
thank you for all those cool MoarVM improvements 17:06
17:22 leont left 17:32 leont joined
nwc10 are they cool? I have no idea if they make anything measurable. 17:37
They do (I think) enable jnthn to address some concurrency issues
at least, I meant, this lot, not sure if they make anything particularly measurable. The first lot did 17:38
17:40 leont left, leont joined
lizmat :-) 17:52
18:21 leont left, leont_ joined 18:36 Xliff joined
[Tux] Rakudo v2020.11-53-g1b2698319 (v6.d) on MoarVM 2020.11-47-g1c7358004
csv-ip5xs0.814 - 0.836
csv-ip5xs-207.695 - 8.216
csv-parser25.419 - 25.537
csv-test-xs-200.383 - 0.383
test7.913 - 8.026
test-t1.830 - 1.932
test-t --race0.823 - 0.842
test-t-2031.689 - 32.441
test-t-20 --race9.298 - 9.494
 18:48
👍
18:49 domidumont1 left 19:01 leont_ left 19:02 leont_ joined 19:05 leont_ left, leont_ joined 20:12 sena_kun joined 20:14 Altai-man left 20:45 patrickb joined
Geth rakudo: patrickbkr++ created pull request #4071:
Adapt filenames in binary release scripts		 21:39
23:32 patrickb left
Geth ¦ rakudo: vrurg self-assigned Performance regression after merge of new coercion semantics github.com/rakudo/rakudo/issues/4056 23:42
23:54 sena_kun left, sena_kun joined 23:58 sena_kun 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!