sjn saw it 00:00
github.com/orgs/raku-community-modules/teams should probably be explicitly pinged :-)
don't see jnthn on that list; maybe not drop this in his lap (I guess he has enough to do) 00:01
AlexDaniel can't do it from another org
sjn: I can assign it to myself but it's not as useful this month 00:02
I can also assign it to rba but they tend to deal with other kind of problems
jnthn: just feel free to reassign it to anybody else 00:03
00:13 sena_kun joined 00:15 Altai-man_ left
cfa AlexDaniel: cool, thanks 00:40
01:21 toddr joined 02:12 Altai-man_ joined 02:15 sena_kun left 04:13 sena_kun joined 04:15 Altai-man_ left 05:15 releasable6 left, sourceable6 left, statisfiable6 left, benchable6 left, coverable6 left, greppable6 left, bisectable6 left, linkable6 left, bloatable6 left, committable6 left, nativecallable6 left, tellable6 left, quotable6 left, notable6 left, reportable6 left, squashable6 left, shareable6 left, unicodable6 left, evalable6 left, coverable6 joined 05:16 linkable6 joined, sourceable6 joined, notable6 joined, committable6 joined, greppable6 joined, benchable6 joined 05:17 tellable6 joined, shareable6 joined, reportable6 joined, bisectable6 joined, evalable6 joined, unicodable6 joined, nativecallable6 joined 05:18 quotable6 joined, statisfiable6 joined, bloatable6 joined, squashable6 joined, releasable6 joined 05:27 Kaeipi left 05:28 Kaeipi joined 05:31 Kaeipi left, Kaeipi joined 06:05 Kaeipi left, Kaiepi joined 06:13 Altai-man_ joined 06:15 sena_kun left 08:14 sena_kun joined 08:15 Altai-man_ left 08:42 camelia left 08:51 Kaiepi left 08:52 Kaiepi joined
lizmat Files=1305, Tests=111214, 207 wallclock secs (28.49 usr 8.02 sys + 2892.44 cusr 267.50 csys = 3196.45 CPU) 09:54
8 CPU seconds less than yesterday 09:55
sena_kun nice 09:57
10:13 Altai-man_ joined 10:15 sena_kun left
[Tux] Rakudo version 2020.02.1-169-g355b520bf - MoarVM version 2020.02.1-44-g04005cf43
csv-ip5xs0.704 - 0.715
csv-ip5xs-206.116 - 6.244
csv-parser24.583 - 25.592
csv-test-xs-200.362 - 0.364
test8.182 - 8.883
test-t1.920 - 2.136
test-t --race0.919 - 0.956
test-t-2031.821 - 33.335
test-t-20 --race9.837 - 10.142
 10:31
working from $home due to corona, so box is in use
11:31 MasterDuke left 11:45 camelia joined
lizmat [Tux]: those timings feel off 11:46
[Tux] they do 11:47
but I'm working from home, so I do use the resources 11:48
Geth rakudo: jnthn self-assigned User Defined Chain function not working in reduction metaoperator github.com/rakudo/rakudo/issues/3541
jnthn self-assigned Declarator blocks not working for unit-declared roles. github.com/rakudo/rakudo/issues/3521

Ensure meta-ops respect user-defined chain ops
Fixes #3541.		 11:55
lizmat [Tux]: understood 12:08
12:13 sena_kun joined 12:15 Altai-man_ left
linkable6 RAKUDO#3541 [closed]: github.com/rakudo/rakudo/issues/3541 [metaop][operators] User Defined Chain function not working in reduction metaoperator
Geth roast: 031d18311e | (Jonathan Worthington)++ | 2 files
Test reduce with user-defined chain assoc ops

Covers github.com/rakudo/rakudo/issues/3541.
sena_kun jnthn, have some time for rakudo? :) 12:21
jnthn Time, yes. Brain? Well, mostly for relatively easy (for me) bug hunting... :) 12:22
sena_kun jnthn, m-maybe blocked grant PRs... 12:23
jnthn Such as?
lizmat Kaiepi 's PR's 12:24
sena_kun github.com/rakudo/rakudo/pull/3451 12:25
also probably github.com/rakudo/rakudo/pull/3491
but there are a lot of them
github.com/rakudo/rakudo/pull/2478 12:26
^ this one is probably more important
Geth rakudo: a093b7fa6a | (Elizabeth Mattijsen)++ | 2 files
Make IO::Path.mode about 14x as fast

  - create a Rakudo::Internals.FILETEST-MODE plumbing method
   just like all of the other filetest methods
  - don't use sprintf in creating the IntStr		 12:27
nine lizmat: we know that the other process cannot be writing anymore. We don't know that it actually succeeded writing. 12:30
lizmat nine: so what does the .s check then give us in security ? 12:31
if we don't know if it succeeded in writing, we don't know whether it succeeded in writing all of what it needed 12:32
and any case, the .s check is checking what the directory knows about the file, not necessarily up-to-date yet with the actual size of the file 12:33
nine Well we know more than without it, even if it's not 100 %
lizmat so, we're writing the file at its final destination?
if so, maybe we should write it with a temporary file name, and then rename it in place ?
Kaiepi github.com/rakudo/rakudo/pull/2478 is something i want to revise
3451 and 3491 are the main ones that need attention 12:34
nine We already write to a temporary file (the .bc file) and rename in place 12:36
I remember reading on lwn.net about file system issues where a system crash in the wrong moment could have led to the rename being successful but the file still lacking its contents. I guess the .s protects us against that 12:37
lizmat feels to me there would be bigger problems by then ? 12:41
nine Nah, it's really just you have a power outage and end up with a zero sized file or two. It's nice to not stumble over them if we can avoid it and the test is cheap. 12:42
Mind that in the by far most common case, we will precompile at that point and compared to that the check is really just a tiny drop. 12:43
lizmat true, but this is all code that will never get hot enough to be optimized, I'd say 12:44
so I wanna make sure we do as little as possible to make larger projects be able to scale up faster 12:45
after a source update anywhere 12:46
nine Reviving my precomp-singleprocess-resurrection branch would have much higher impact :)
Geth rakudo/precomp-singleprocess-resurrection: 8 commits pushed by (Arne Skjærholt)++, (Stefan Seifert)++ 12:49
lizmat nine: do we have tools to investigate whether precomps gained stuff that they shouldn't? 12:55
nine You mean those objects that leak into precomp files that my commit messages talk about? Can't remember really good tools. 12:57
lizmat :-( ok
nine Actually the heap analyzer may come in handy there, since it can tell you about references to objects.
lizmat I looked at the diff with the single-process effort... I think it's past resurrection as such 12:58
but I will look at the ideas behind it
nine OMG sometimes, I can be unbelievably stupid. Like now as I'm wondering why I'm already hungry when breakfast wasn't that long ago. Only that I didn't actually eat breakfast. I just prepared it and packed it for eating at the office. 12:59
lizmat: yeah, I figured as much. Lot's of change in that code since then
lizmat once I grok enough of what's going on there, I'll mount another attack on making it single-process *and* threaded 13:00
Geth rakudo: d4231b1ffc | (Elizabeth Mattijsen)++ | 2 files
Make precomp existence test slightly faster

  - introduce a fast R:I.FILETEST-ES method
  - use that
13:07 lucasb joined 13:12 travis-ci joined
travis-ci Rakudo build failed. Jonathan Worthington 'Ensure meta-ops respect user-defined chain ops 13:12
travis-ci.org/rakudo/rakudo/builds/661939450 github.com/rakudo/rakudo/compare/3...012f18bef8
13:12 travis-ci left
lizmat restarted the one failing build that mattered 13:13
hmm.. looks like one of my changes borked the JVM build :-( 13:14
nine: looks like adding a LEAVE phaser to precompile causes "Multiple exceptions were thrown by LEAVE/POST phasers" 13:20
on the successful exit of precompile :-)
:-( rather 13:21
dogbert11 lizmat: I thought you were going to 'trick' jnthn into taking a look at R#3540
linkable6 R#3540 [open]: github.com/rakudo/rakudo/issues/3540 [QAST][codegen][needs research][performance] WhateverCode appears to clone when it shouldn't
dogbert11 :-)
Geth rakudo: c2a1ee9574 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Only lookup .store once during precompile

  - and some additional typechecking
  - and removal of unnecessary default values: Bool is also False		 13:55
13:56 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Make IO::Path.mode about 14x as fast 13:56
travis-ci.org/rakudo/rakudo/builds/661941516 github.com/rakudo/rakudo/compare/a...93b7fa6a39
13:56 travis-ci left
lizmat dogbert11: already tried that 13:56
restarted the one failing job
Geth rakudo/WHY-on-role-group: a8f1e97a92 | (Jonathan Worthington)++ | src/Perl6/Metamodel/ParametricRoleGroupHOW.nqp
Make .WHY on role group delegate to default role

Roles have a two-level structure: the role name is a parametric role group, which in turns contains the parametric role. In the case of there being many roles of the same short name, they are within the one group. Declarator docs correctly attach to the parametric role. However, that means .WHY on the group doesn't actually result in those docs. You have ... (10 more lines)		 14:04
rakudo: jnthn++ created pull request #3549:
Make .WHY on role group delegate to default role
jnthn Please leave opinions on the PR
I thought it was an easy thing to fix, but it turns out we have spectests that break, so... 14:05
sena_kun once attempted to look at it, thinking it may be an easy fix, but 14:06
jnthn The fix was fine, I'm just a bit thrown by the spectests that expected it not to be fixed :) 14:07
14:13 Altai-man_ joined 14:15 sena_kun left
dogbert11 m: say say <0 0 0 0 0 0 0> X|| $++ 14:23
camelia (0 0 0 0 0 0 0)
True
jnthn That doesn't thunk 14:24
Geth rakudo: 6d3f1c1270 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Look up $*REPO only once during precompile
 14:25
dogbert11 should it? 14:26
jnthn No
dogbert11 m: say Bool.pick Xxx ^5 # so this shouldn't thunk either I guess 14:29
camelia (() (True) (True True) (True True True) (True True True True))
jnthn Well, that one more reasonbly could 14:33
But evidently doesn't. That or you should go and buy a lottery ticket :P 14:34
dogbert11 I'm looking at some old bugs, in order to see if they might have been fixed. In this case it was github.com/Raku/old-issue-tracker/issues/6005 14:35
Geth rakudo: bd9d7c1cc3 | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Restore IO::Path.abspath semantics on the JVM backend

Well, hopefully so, Travis will tell.		 14:39
14:48 cfa left
dogbert11 m: say [\Z+] (1, 2, 3), (10, 20, 30), (100, 200, 300) 15:01
camelia ((6) (11 22 33) (111 222 333))
Geth rakudo: dceef85f3b | (Elizabeth Mattijsen)++ | 3 files
Make sure we use same checksum method everywhere

  - add IO::Path.CHECKSUM internal method
  - use this where appropriate		 15:05
15:34 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Only lookup .store once during precompile 15:34
travis-ci.org/rakudo/rakudo/builds/661972490 github.com/rakudo/rakudo/compare/d...a1ee957481
15:34 travis-ci left
lizmat restarted the one failing job 15:39
Geth rakudo: 859d8f048a | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Move variables closer to where they're needed

A cosmetic / readability / comprehensibility change		 15:41
15:47 squashable6 left 15:50 squashable6 joined
lizmat nine: looks like precomp file is slurped than written at proper location, rather than renamed ?? 15:51
:bytecode($bc.slurp(:bin))
nine lizmat: github.com/rakudo/rakudo/blob/mast...e.pm6#L269 15:56
lizmat: ah sorry, second time I gave you misleading information 15:57
lizmat: this is the right one: github.com/rakudo/rakudo/blob/mast...e.pm6#L277
So we're wrinting a .tmp file and rename that. Which makes more sense because the precomp file is the header + the .bc file's contents
lizmat aha, ok... that makes it clearer 16:06
16:08 ZzZombo left
lizmat so the bc file is just that: the bytecode file 16:08
would it make sense to try and have the system write to an open handle? or to have the system write to an in-memory blob 16:09
so that we could prevent needing to write / slurp / write the bytecode ?
16:13 sena_kun joined 16:15 Altai-man_ left
Geth rakudo: 5ea1c34674 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Some mixed micro opts

  - binding instead of assigning
  - check the cheapest (and most likely failing) condition first
  - use faster existence check (and also check for size)
  - another case of if foo -> \bar
  - one case of missed .store		 16:18
lizmat nine: if something went wrong with creating the precomp, shouldn't we be $bc.unlink to be on the safe side ? 16:21
nine: re writing bytecode to a blob: duh, that would require a single-process precomp setup :-) 16:23
nine Writing to an open handle would be nicer indeed. On that note using a pipe for the dependencies instead of STDOUT would be, too. The main reason for me not doing that in the first place was that I didn't know if that would work on Windows and it was almost December 2015... 16:37
lizmat aha, ok, I'll keep that in mind... 16:38
16:59 MasterDuke joined
Geth rakudo: 2a58eb3989 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Optimize setup / handling of dependencies a bit

  - deHLLize setting up of the dependencies		 17:16
¦ rakudo: lizmat self-assigned New class assigned to $*ARGFILES breaks "IO::CatHandle::Autolines" github.com/rakudo/rakudo/issues/3548 17:33
17:43 kawaii left 18:02 patrickb joined 18:12 Altai-man_ joined 18:15 sena_kun left 18:52 ufobat__ joined 18:55 ufobat_ left 19:24 MasterDuke left 20:13 sena_kun joined 20:15 Altai-man_ left 20:34 lucasb left, MasterDuke joined
patrickb rba: I just uploaded rakubrew v6 (patszim.volans.uberspace.de/patclo...JLQDZcjbf) 20:40
rba: Also I have a new version of the rakubrew.org website. Can you bump that?
rba: Thanks for your constant support with this! 20:41
21:53 finsternis left
MasterDuke i added `note("composed " ~ $obj.HOW.name($obj));` here github.com/rakudo/rakudo/blob/mast...W.nqp#L249 as well as notes in `type_check` and `find_method` 22:04
when i run `constant N = 10; my int @a[N]; @a[$_] = $_ for ^N; say @a[N-1]; say now - INIT now`, i see lots of `looking for type <foo> in array[int]` and `looking for method <bar> in array[int]`, but neither when building rakudo or running that example do i see `composing array[int]` 22:06
22:06 Altai-man_ joined
MasterDuke there's `composed array[int]+{array::shaped1intarray}` when running the example and `composed array+{array::intarray[int]}` when building rakudo 22:07
22:09 sena_kun left 22:19 toddr left
Geth ¦ problem-solving: ugexe assigned to jnthn Issue New public interfaces are often added without any chance for general consensus github.com/Raku/problem-solving/issues/169 22:24
lizmat calls it a day 23:17
23:19 finsternis joined 23:20 MasterDuke left
Altai-man_ lizmat, rest well. 23:20
23:37 patrickb left 23:42 MasterDuke joined
MasterDuke jnthn: don't want to bother you, but if you have any suggestions for a better way to address github.com/rakudo/rakudo/issues/3532 i'm all ears 23:44

Powered by Cro and the Raku® Programming Language.

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

Thank you!