🦋 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.
00:07 reportable6 left 00:08 reportable6 joined 01:34 RakuIRCLogger left, Geth left 03:28 frost joined 06:03 releasable6 left, coverable6 left, greppable6 left, bisectable6 left, bloatable6 left, linkable6 left, shareable6 left, committable6 left, reportable6 left, notable6 left, statisfiable6 left, evalable6 left, sourceable6 left, nativecallable6 left, unicodable6 left, quotable6 left, benchable6 left 06:04 shareable6 joined, benchable6 joined, bloatable6 joined, quotable6 joined, greppable6 joined, linkable6 joined 06:05 coverable6 joined, notable6 joined, sourceable6 joined, bisectable6 joined, committable6 joined 06:06 nativecallable6 joined, reportable6 joined, releasable6 joined, evalable6 joined 06:07 unicodable6 joined, statisfiable6 joined
nine japhb: can vs does 06:27
japhb nine: Fair enough. Is anyone yet working on turning 'can' into 'does'? (IIUC, that's what Xliff is asking for.) 06:37
nine Not that I'm aware of 06:40
japhb OK, so it sounds like the current status is "The data is there, there may even be an internal API for it, but either that API is not exposed externally and/or Zef is not currently using that data to communicate to the end user." So I guess the next question is whether there actually is any work to be done to expose that data in an official API, or whether it's just a matter of hacking Zef to expose what 06:44
it already knows.
nine It is rather simple: the workhorse for installation is CURI's install method. It takes a Distribution object and installs this distribution, i.e. copying bin and resource files and precompiling modules. The Distribution object is essentially the META6.json in form of an object. 06:55
Since the META6.json contains information like what distro it is and how many and what modules it contains and zef is the thing that reads this information and passes it to the install method in the first place, zef already knows how many modules are going to be installed. 06:57
And of course it could easily take timings for how long it takes to install that distribution.
And if the installer was really keen on giving more fine grained information like what modules is currently being precompiled, it could even do that right now. It would just have to set RAKUDO_LOG_PRECOMP in the environment and replace $*STDERR with an object that intercepts the "Precompiling $id ($_.key())" message and uses it to e.g. drive a counter 07:01
lizmat that's exactly what I want to do, in a slightly different way 07:07
however, that counter doesn't really keep track
take the example of NativeCall: it uses NC::Types, ::Compiler::GNU and ::Compiler::MSVC 07:08
so that's 4 files
because CURI sorts the provides keys, it will precomp NativeCall first 07:09
*but* because of its use statements, that means it will also recursively precompile those modules as well 07:10
so suppose it would be the only things being installed, then it would start with 1/4 NativeCall, and then be done
because the other 3 modules would be precompiled already by the time CURI is even thinking of precompiling them 07:11
nine We ought to get rid of that recursion as it blocks proper parallelization
lizmat agree
so that's what I've been doing the past week or so, trying to grok the whole process and try to come up with a way for proper reporting and parallelization 07:12
and not break anythinhg
and type correctly :-)
nine The latter is probably the hardest
lizmat ineed 07:13
:-)
07:28 [Coke] left 07:31 [Coke] joined
MasterDuke oh, Geth is down? 08:59
lizmat again? 09:02
09:02 Geth joined, RakuIRCLogger joined 09:03 TempIRCLogger joined
lizmat MasterDuke: which repo should I replay commits ? 09:04
MasterDuke nqp and rakudo
Geth rakudo: 91185079e0 | (Elizabeth Mattijsen)++ | src/Perl6/World.nqp
One unncessary return at the end of a method
 09:06
rakudo: vrurg++ created pull request #4861:
Initial attempt with `will complain` trait		 09:08
nqp/faster_sorted_keys: 6eb2954d7e | (Elizabeth Mattijsen)++ | 2 files
Some more tweaks

  - remove now superfluous decrement (it's handled in the loop condition)
  - find out that it sorts in reverse, document that
  - fix sorting for 2 elements, it's supposed to be in reverse!
  - add tests for "sorted_keys", there weren't any		 09:09
lizmat I think that covers it
Geth nqp: b4d5848597 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 2 files
Speed up "sorted_keys" sub

  - faster collection of keys using nqp::iterator/nqp::iterkey_s
  - one check for > 2
  - one check for == 2 and order
  - decrement in while condition, account for that in initialization
  - document it's actually sorting in *reverse* order
... (7 more lines)		 09:37
rakudo: 02c59dc790 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/Repository/Installation.pm6
Make script stubs and used extensions constants
 09:39
09:43 sena_kun left
Geth rakudo: f41d5c5a74 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump nqp to get faster sorted_keys logic
 09:52
09:54 sena_kun joined
Geth rakudo: 42457734f9 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/Repository/Installation.pm6
Lose the original wrapper initializations
 10:20
[Tux] Rakudo v2022.03-196-g91185079e (v6.d) on MoarVM 2022.03-17-g794e1d589
csv-ip5xs0.823 - 0.846
csv-ip5xs-205.133 - 5.394
csv-parser3.899 - 4.490
csv-test-xs-200.400 - 0.494
test6.660 - 6.738
test-t1.428 - 1.501
test-t --race0.903 - 0.960
test-t-2020.958 - 21.112
test-t-20 --race6.600 - 6.953
 10:36
11:05 TempIRCLogger left 12:07 reportable6 left 12:09 reportable6 joined
Geth rakudo: 6b50a940af | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/Repository/Installation.pm6
Make sure $*REPO gets restored on exception

At the moment, if anything goes wrong with module installation, we completely abort anyway. But that may not be like that in the future. Make sure that $*REPO gets restored on failure. Also reduce the number of $*REPO lookups.		 12:15
rakudo: b2a8bfc9e7 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 8 files
Remove the $?COMPILATION-ID constant

  - it is not used anywhere
  - it is only tested for its existence
  - it is not documented		 12:16
13:02 frost left 13:35 sena_kun left 13:36 sena_kun joined
Geth rakudo/CUDS-lookup-id: a39ddc222d | (Elizabeth Mattijsen)++ | 2 files
Add CompUnit::DependencySpecification.lookup-id method

And use it. I guess technically any CUR can devise its own way of encoding a shortname lookup into a filename, but it feels that it being in the CUDS is more appropriate.		 13:37
rakudo: lizmat++ created pull request #4862:
Add CompUnit::DependencySpecification.lookup-id method
rakudo: 8a1e778874 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/IO/Path.pm6
Add an IO::Path.dir-with-entries method

Checking whether a directory has entries in it, can be checked by doing e.g. an "if .dir.head {". However, this will leak resources as the iterator that runs "dir" will never be finished, and thus the underlying directory handle will also never be closed.
... (8 more lines)		 14:21
18:05 sena_kun left 18:06 sena_kun joined 18:08 reportable6 left, reportable6 joined 19:36 linkable6 left 19:37 linkable6 joined 19:46 linkable6 left 19:49 linkable6 joined 19:51 sena_kun left 19:54 sena_kun joined
Xliff lizmat: I've started another run of timings, as requested. 20:11
lizmat Xliff++ 20:49
Xliff lizmat: I am noticing that prereqs are being recompiled. 20:51
Which might be why the numbers are off.
lizmat hmmm... intriguinig 20:52
Xliff GIO is compiled before soup, but the parts of GIO that are used by SOUP are adding 61 seconds to SOUPs time.
lizmat ok, then stop the timing....
Xliff Done. 20:53
lizmat I guess I need to look at why it is re-doing dependency checks (I know it re-does these for modules in the core repo)
but in that case, it doesn't actually re-precompile the dependencies
Xliff: if you could golf this, that would be brill! 20:54
Xliff lizmat: I'll see what I can do. 20:55
lizmat ++Xliff 20:56
21:29 Xliff 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!