00:25 Xliff joined 01:05 patrickz left 01:19 MoniAlvarez joined 01:22 MoniAlvarez left 06:34 jjmerelo joined
nine patrickb: what kind of commit message is "asdf"?? Please write useful commit messages that tell us what the user visible effect is and why a change was needed. 06:48
tellable6 nine, I'll pass your message to patrickb
nine patrickb: and please develop in a branch or your own fork and only push working results to master 06:49
tellable6 nine, I'll pass your message to patrickb
07:09 patrickb joined 07:17 jjmerelo left 07:19 Altai-man_ joined
patrickb .tell vrurg I'm hunting a JVM / Windows build error. Here is the failure: github.com/Raku/nqp/issues/629 Any ideas? 07:20
tellable6 patrickb, I'll pass your message to vrurg
patrickb .tell bartolin I'm hunting a JVM / Windows build error. Here is the failure: github.com/Raku/nqp/issues/629 Any ideas?
tellable6 patrickb, I'll pass your message to bartolin_
nine Looks like it's not actually $*UNIT that leaks into the EVAL. But the EVAL's $*UNIT picks up the outer $*UNIT's statements somehow 08:02
08:11 jjmerelo joined
jjmerelo Nice 08:11
(some CSV benchmark below 1.8) 08:12
08:23 ufobat_ left 08:26 sena_kun joined 08:27 Altai-man_ left
Geth rakudo/master: 5 commits pushed by (Patrick Böker)++ 08:56
nine patrickb: oh, those were actually in your own fork and you did everything right! But why did I get notifications about those commits from Github? It says rakudo/rakudo in the mails 09:00
patrickb nine: How many did you receive?
tellable6 2020-05-15T06:48:04Z #raku-dev <nine> patrickb: what kind of commit message is "asdf"?? Please write useful commit messages that tell us what the user visible effect is and why a change was needed.
2020-05-15T06:49:15Z #raku-dev <nine> patrickb: and please develop in a branch or your own fork and only push working results to master
patrickb nine: I'm not sure why they leaked out actually... 09:02
nine patrickb: oh, I think, I understand now. You created the pull request and pushed more commits to your branch after that and Github sent notifications to rakudo devs because they became part of the PR
I even clicked on the link, made sure it pointed to the rakudo repository and looked at the commit tab, to ensure the commits actually landed in rakudo master before saying anything 09:03
Geth rakudo: 42c37997a7 | (Patrick Böker)++ (committed using GitHub Web editor) | README.md
Add a build badge for Azure Pipelines

This will show the commit test status of the master branch as reported by Azure Pipelines.		 09:09
nine Clarification: the EVAL doesn't pick up statements, but the top level QAST::Block objects that get added to the $*UNIT block after the QAST::Stmts
Now where do those get added?
Geth rakudo: 4085cfdc64 | (Patrick Böker)++ | azure-pipelines.yml
Fix CI failures when commits are added fast

With a fetch depth of 1 azure pipelines will always clone the master branch with only the top most commit and then try to check out the commit that is to be tested. This fails when commits are added quickly, because then test jobs that weren't fast enough to start will check clone only the newly added commit and then checking out the commit to test fails because that's not part of the cloned repository.		 09:29
timotimo nine: is it broken without the optimizer, too? it's not impossible that the optimizer may play it a little fast and loose with modifying qast nodes's child lists and perhaps not cloning deep enough etc 09:30
nine timotimo: yes. I already see that we took a wrong turn when running the outer unit's comp_unit action 09:31
timotimo OK 09:32
nine The outer and inner compiler's Worlds do share some state in the Perl6CompilationContext object. This state even includes the lex pads. But I can't find any code that would use this state when adding blocks to the unit 09:34
timotimo OK 09:35
09:46 andreoss joined
nine There is something we share that we really shouldn't: CHECK blocks - like the one NativeCall exports to its user 09:47
Unsharing them actually fixes my reduced test case! Alas, not the similar error in Inline::Perl5 09:48
09:58 ufobat joined
patrickb It's absolutely necessary that JVM build errors do not cause a CI run to fail, correct? 10:10
sena_kun patrickb, why? 10:14
patrickb, passing tests is another matter, but to be able to at least _build_ JVM build - I'd say that's mandatory. 10:16
patrickb That's what we have been doing for a long time now. I think the idea is that JVM tends to fail and is not fixed immediately and we do not want to hide moar build failures this way. 10:17
sena_kun: State of the Azure CI is that JVM is built and tested, but JVM failures are *not* ignored. They do cause the build to fail. It's difficult to make it a warning. Azure misses that feature. 10:18
sena_kun patrickb, test failures or build failures? 10:19
patrickb Now I'm unsure whether this is a "just accept" or "make it work no matter the cost" case.
At the moment both.
sena_kun Sacrifice test failures, but not build failures, I'd say.
patrickb need to leave... Back in ~1.5h 10:20
sena_kun o/
patrickb, there is no need to ignore build failures for any cases. I don't see a real issue with it "hiding moar build failures". Devs are building moar a lot anyway. 10:22
10:25 Altai-man_ joined 10:27 sena_kun left
timotimo we could potentially turn rakudo-moar and rakudo-jvm into different "projects" on azure or whatever, so that they report as two individual build statuses 10:36
Geth nqp: andreoss++ created pull request #630:
[jvm] Rename s/perl6/raku/ & rebootstrap		 10:39
andreoss MasterDuke: i took a shortcut by not having two sets of packages for bootstraping, and directly altered stage0 jars at bytecode level 10:42
i hope it's fine. I tried to extend existing classes with new package, but it produced a lot of issues on NQP side 10:46
lizmat Files=1306, Tests=111291, 214 wallclock secs (28.88 usr 8.60 sys + 3009.43 cusr 276.10 csys = 3323.01 CPU) 10:58
Geth ¦ rakudo: lizmat self-assigned slurp routine with :enc("utf16") broken github.com/rakudo/rakudo/issues/3691 10:59
roast: tbrowder++ created pull request #644:
Add test for Rakudo issue GH #3682		 11:17
MasterDuke andreoss: do you have a companion PR for rakudo in the works? 11:22
andreoss MasterDuke: yep, I'm working on it rn. They need to be merged at the same time? 11:24
MasterDuke yeah, kind of 11:26
11:27 evalable6 left
MasterDuke once you have the rakudo PR ready, i would suggest merging the nqp pr, then updating the rakudo pr to bump the nqp version required so it pulls in the new nqp at the same time 11:28
11:28 evalable6 joined 11:33 Kaiepi left, Kaiepi joined
Geth rakudo: eeb4f43f87 | (Stefan Seifert)++ | 2 files
Fix BEGIN time EVAL accidentally running CHECK phasers of the outer comp unit

This could cause wird compilation errors about missing static code refs for closures. Fix by simply not sharing the list of CHECK blocks with a nested compiler.		 11:36
MasterDuke nice. think there are any open issues this might have fixed? 11:39
nine No idea....truth is I don't look at the issue list much since I get a steady supply of things to fix from my own work ;) 11:48
lizmat nine: I'm afraid you forgot to push BeginTimeEvalAndNativeCall 11:57
nine oh darn 11:58
Geth rakudo: b874c68eb7 | (Stefan Seifert)++ | t/packages/02-rakudo/lib/BeginTimeEvalAndNativeCall.rakumod
Add missing test module
 11:59
lizmat whee! 12:00
12:26 sena_kun joined 12:27 Altai-man_ left 12:29 travis-ci joined
travis-ci Rakudo build failed. Stefan Seifert 'Fix BEGIN time EVAL accidentally running CHECK phasers of the outer comp unit 12:29
travis-ci.org/rakudo/rakudo/builds/687398435 github.com/rakudo/rakudo/compare/4...b4f43f875b
12:29 travis-ci left
lizmat should be fixed in the next commit :-) 12:34
12:50 jjmerelo left
tbrowder can anyone knowledgeable of the dev of sprintf give me some help on the NYI features, particularly the int modifiers like 'l', 'll', 'L', etc.? 12:59
[Coke] lizmat: oh no, more os x code names! (I made that script so I could decode them, because I never remember what they are!) 13:01
lizmat I think this list is quite enough :-) 13:02
I mean, the oldest is more than 10 years ago, no ?
2001 even 13:03
also, then PowerPC, so any hardware from then running Raku would be abysmally slow, if it even had enough memory to run Raku :-) 13:04
tbrowder i would like to implement them with raku numerics behind the scene but i want to ensure the "semantics" are okay. in my experience, those modifiers in the C world were to ensure sprintf could handle a number of up to that size. i think we are able to do that while letting the raku number handlers take care of the native side. 13:06
i guess i need to look at the details of the c lib... 13:11
[Tux] Rakudo version 2020.05.1-117-gb874c68eb - MoarVM version 2020.05-12-g3605efdbf
csv-ip5xs0.853 - 0.878
csv-ip5xs-208.044 - 8.903
csv-parser25.743 - 26.816
csv-test-xs-200.386 - 0.405
test7.463 - 7.569
test-t1.871 - 1.961
test-t --race0.839 - 0.877
test-t-2031.717 - 32.737
test-t-20 --race8.744 - 9.764
 13:13
tbrowder ok, a refresh look at perl's sprintf doc helps enough, thnx 13:18
13:24 vrurg_ joined 13:26 vrurg left 13:28 vrurg joined 13:31 vrurg_ left
Geth rakudo: c2e8b22f7b | (Elizabeth Mattijsen)++ | src/core.c/Str.pm6
Fix "١٢٣".Numeric and "١٢٣".Int

  - a0e5841 broke this, apparently MoarVM only uses 0..9 for implicit conversion
  - makes "123".Numeric.Int about 1.7x **slower**
  - perhaps we need a CCLASS_DECIMAL class to quickly check for 0..9
   This would allow the speedup to be brought back again
  - fixes R#3694		 13:34
linkable6 R#3694 [open]: github.com/rakudo/rakudo/issues/3694 Unicode numeric digit strings no longer coercible to Numeric
nine Oh, the remaining missing static code ref in Inline::Perl is actually one from the EVALed code: Serialization Error: missing static code ref for closure '<unit-outer>(nested)' (/home/nine/test/precomp2/lib/A.pm6 (A):1) 13:37
Geth ¦ rakudo: vrurg self-assigned INSTALL.txt out of date github.com/rakudo/rakudo/issues/3693
roast: 0172bf5bb5 | (Elizabeth Mattijsen)++ | S02-literals/numeric.t
Add tests for R#3694
 13:48
linkable6 R#3694 [open]: github.com/rakudo/rakudo/issues/3694 Unicode numeric digit strings no longer coercible to Numeric
nine I think I know where the static code ref issue about <unit-outer> is coming from: One is just not supposed to be keeping that object around but run it exactly once before we start serialization 13:51
MasterDuke there are some weird issues around BEGIN, precomp, etc. e.g., github.com/rakudo/rakudo/issues/2592 13:52
nine MasterDuke: is that one reproducible at HEAD? It may have been fixed by the $*OUT.flush additions to precompilation code. But really, using say that way in precompiled code is not a good idea. 13:53
MasterDuke i just tried it, exact same behavior 13:54
but why does .note() work?
and .print
but not .put 13:55
nine Precompilation uses STDOUT for communicating between the precompilation process and it's parent 13:56
MasterDuke ah 13:58
lizmat afk for a few hours& 14:01
14:25 Altai-man_ joined 14:27 sena_kun left 15:10 jjmerelo joined 15:27 [Tux] left 15:41 [Tux] joined 15:42 domidumont joined 16:16 Voldenet left 16:22 Voldenet joined, Voldenet left, Voldenet joined 16:25 sena_kun joined 16:27 Altai-man_ left 17:02 domidumont left 17:21 patrickb left 17:23 patrickb joined 17:24 patrickz joined 17:27 patrickb left 18:13 jjmerelo left, lichtkind joined 18:25 Altai-man_ joined
Geth rakudo: 5b4faed304 | (Patrick Böker)++ | azure-pipelines.yml
Fix build artifact publishing

Artifacts names must be unique. When trying to publish an artifact with a name that already exists an "ArtifactExistsException" is thrown and the job fails. To solve this we don't explicitly specify the artifact name which should then default to a name autogenerated based on the job name. See github.com/MicrosoftDocs/azure-dev...-541875716		 18:27
18:27 sena_kun left
Geth roast: b5603799fa | (JJ Merelo)++ | integration/advent2010-day03.t
Fixes integration test

And this one really closes #640		 18:39
roast: a011d15283 | (JJ Merelo)++ | integration/advent2010-day03.t
Convert to IO paths as requested
linkable6 ROAST#640 [closed]: github.com/Raku/roast/issues/640 Roast depends on Rakudo when it shouldn't
Geth roast: b995655d95 | (Vadim Belman)++ (committed using GitHub Web editor) | integration/advent2010-day03.t
Merge pull request #642 from JJ/master

Fixes integration test
patrickz vrurg: wrt the gmake bug: AFAIK the build process has both nmake and gmake available. How can I force it to prefer nmake over gmake? 18:41
vrurg patrickz: it looks reasonable to just disable gmake on Win altogether. 18:42
tellable6 2020-05-15T07:20:06Z #raku-dev <patrickb> vrurg I'm hunting a JVM / Windows build error. Here is the failure: github.com/Raku/nqp/issues/629 Any ideas?
patrickz vrurg: Won't we kill building with the mingw/cygwin pipeline then? 18:43
vrurg Does it work now? 18:44
Geth roast: 8d30d3af57 | (Tom Browder)++ (committed using GitHub Web editor) | S32-str/sprintf.t
Add test for Rakudo issue GH #3682 (#644)

The issue was an LTA error for interpolated '$' symbols in sprintf format strings.
This commit:
... (7 more lines)
vrurg patrickz: actually, nmake is given preference over gmake in autodetect if msvc compiler is found too.
patrickz vrurg: Interesting! Then something I didn't expect is happening. I'll look deeper. Thank you! 18:53
lizmat .tell jjmerelo looks like integration/advent2010-day03.t is severely broken 19:11
tellable6 lizmat, I'll pass your message to jjmerelo
Geth rakudo: 799d627a48 | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Restructure IO::Path.slurp a bit

  - mostly for readability, using ternaries instead of nqp::if
  - don't store the blob in the method, pass it on as is		 19:13
19:21 MasterDuke left 19:30 [Tux] left 20:01 Kaeipi joined 20:02 Kaiepi left 20:26 sena_kun joined 20:28 Altai-man_ left 20:40 andreoss left 20:43 MasterDuke joined
Geth rakudo: adfa192bc1 | (Patrick Böker)++ | azure-pipelines.yml
Partially fix building the JVM in AzureCI

Installation still fails with a different error.
Windows has a maximum PATH variable length of 2048 (depending on how it's accessed). The length of PATH in AzureCI is already really tight. When building the JVM backend we run into the limit when we add Java and the MS BuildTools to the path. To work around this, we remove a bunch of stuff we won't need from PATH.		 20:59
patrickz ^ The joys of using Windows. :-P 21:05
vrurg And they still call it an OS... 21:18
I'm considering removing mentions of '--with-moar' and '--with-nqp' from INSTALL.txt. These are rather advanced stuff for those who understand what they're doing. 21:27
vrurg is afk for couple of hours
21:43 [Tux] joined 21:44 [Tux] left 21:47 [Tux] joined 21:52 ufobat_ joined 21:56 ufobat left 22:00 sena_kun left
[Tux] system up-and-running again on SSD 22:01
new timings tomorrow 22:05
22:07 patrickz left
MasterDuke system feels faster? 22:08
23:42 lichtkind 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!