🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
Geth rakudo: vrurg++ created pull request #4721:
Implement smartmatch as a dispatcher		 03:26
Geth nqp/fix_unsigned_for_merge: 6 commits pushed by (Elizabeth Mattijsen)++, niner++, (Stéphane Payrard)++, (Stefan Seifert)++ 08:50
nqp: niner++ created pull request #757:
Fix handling of unsigned native integers		 08:53
gfldex Signature.new and Parameternew are not in roast. Are those implementation details or is this an ENOSPEC? 11:13
Signature.new and Parameternew are not in roast. Are those implementation details or is this an ENOSPEC? 11:14
I'm asking because Template::Classic takes a Signature-object in a function you have to call all the time and without speccing Signature.new one has to EVAL. 11:18
nine m: say :($a, $b).^name 11:19
camelia Signature
nine I guess it's just ENOSPEC 11:21
moon-child has anyone tried checking a code coverage report of compiler/core on spectest? 11:27
lizmat m: class A { has Int:D $.a is rw = 0 }; my $a = A.new; $a.a = True; dd $a # I understand why, but it feels meh 12:10
camelia A $a = A.new(a => Bool::True)
Voldenet aaaa 12:14
oops
Geth rakudo/fix_unsigned_for_merge: 11 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/1...0c1c9e5d70		 13:08
ugexe zef seems to be randomly getting a "No such private method 'SET-SELF' on Map" error in CI fairly often 15:46
app.circleci.com/pipelines/github/...ep-103-119 15:47
something like 20% of the CI runs give this error
lizmat line in question: with try Zef::Distribution.new(|%($meta)) -> $dist { 15:55
so, is the exception leaking out of the try ?
ugexe i dont think that error should be occuring at all
releasable6 Next release in ≈4 days and ≈23 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 19:00
Geth nqp: 22e80c33fb | (Stéphane Payrard)++ | .github/workflows/markdown-link-checker.yml
add action to check up markdown liinls
 20:00
nqp: c72ed7a5bc | (Stéphane Payrard)++ | 45 files
Merge branch 'master' of github.com/Raku/nqp
nqp: c72ed7a5bc | (Stéphane Payrard)++ | 45 files
Merge branch 'master' of github.com/Raku/nqp
cognominal Oops how come viscose pushed that without asking 20:04
lizmat that's indeed quite an oops :-( 20:06
in light of recent mixups, /me pages nine 20:08
Geth rakudo: gfldex++ created pull request #4723:
implement sub hyper/race
cognominal I want to experiment with actions but I was supposed to to that on my local copy. 20:09
japhb Cairo test failure: gist.github.com/japhb/efb7da856b06...2b57f10864 20:13
lizmat could your gist raku --ll-exception t/text.t ? 20:14
japhb lizmat: give me a sec, I'll see what I can manage 20:16
japhb lizmat: Added to the gist. 20:21
lizmat japhb: wow: that does not rung any bell with me... feels more like something in #moarvm 20:22
japhb Yeah, could be, trying over there
Xliff \v 21:50
\o, even
Getting this error when attempting to brew a fresh raku: /home/cbwood/Projects/rakudobrew/versions/moar-blead/install/include/moar/moar.h:29:10: fatal error: mimalloc.h: No such file or directory
github.com/microsoft/mimalloc ?? 21:51
[Coke] should have been picked up in your moar config step 21:54
MasterDuke Xliff: yeah, moarvm just switched to using mimalloc by default. lizmat also had a similar problem when building from her already-checked-out repo. i'm not sure why (it's been fine for me), but a fresh clone worked for her
moon-child try 'git submodule init; git submodule update' 22:09
Xliff (MasterDuke moon-child).»succ 22:15
Xliff suddenly realizes that might not sound as complimentary as intended... 22:16
moon-child haha
MasterDuke Xliff: heh. btw, i'm curious to see if there's any sort of noticeable improvement in your compile times now we're using mimalloc
Xliff MasterDuke: Funny that. I was rebuilding with the intent of making the next weekly run. 22:17
Xliff Still having issues with this .SET-SELF crap. I'm wondering why I'm the only one running into it, and if that would explain the lack of urgency in fixing it. 22:18
MasterDuke ugexe just mentioned something similar 22:18
Xliff I haven't been able to do Parallel timings for over 9 weeks because of it.
MasterDuke you do also stress compilation (compared to runtime) more than most...
Xliff The non-Parallel times take a hit because of the double or even triple recompilations.
MasterDuke: Yep. I get it. 22:19
And... their off! [Timings started]
MasterDuke istr, there was some talk that in-process precomp might be easier to get working now that new-disp has landed 22:21
Xliff Yeah, but that still might not solve the issue. 22:22
And... there it is.
So... 10 weeks. No Parallel timings.
MasterDuke: First project in timing list suffered 30 second increase with 1 recompile due to SET-SELF error 22:52
Last week it was 3 recompiles.
That
means that whatever performace increase was expected from mimalloc might have been eaten by recent commits.

Powered by Cro and the Raku® Programming Language.

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

Thank you!