00:27 lucasb left 01:34 Altai-man_ joined 01:36 sena_kun left 03:27 leont left 03:35 sena_kun joined 03:36 Altai-man_ left
vrurg I can now .wrap a candidate of a multi method with a multi sub... And it works with inheritance... Finally... 04:01
04:03 hungrydonkey joined 05:34 Altai-man_ joined 05:36 sena_kun left 06:01 sena_kun joined 06:02 Altai-man_ left 06:24 Altai-man_ joined 06:26 sena_kun left 07:10 cognominal joined 07:14 cognomin_ left 07:27 hungrydonkey left 07:30 hungrydonkey joined 07:35 sena_kun joined 07:36 Altai-man_ left
rba lizmat, MasterDuke: If you both are in Lausanne Friday evenging 13 March, is there a chance for a dinner together? I can setup a meetup for this too and then let's see who is able to join from the Swissisch side? 08:05
08:15 hungryd41 joined 08:19 hungrydonkey left, hungryd41 left 08:26 jmerelo joined 08:27 hungrydonkey joined, Geth left 08:28 Geth joined
rba tyil: Try to do a windows rakudo star build now... 08:29
tyil rba: nice 08:31
don't overwork yourself, though :)
I updated the raku.org website to refer to 2020.01 on the downloads page 08:32
rba tyil: nice.
08:44 hungrydonkey left 08:45 hungrydonkey joined
rba Using gcc from strawberry perl. Is this recommended or should I use Visual Studio? 09:09
tyil rba: strawberry perl should work fine 09:30
that's what hankache has been using iirc
hankache did mention he had to change some things, but I don't have any details on what needed updating :/ 09:32
09:34 Altai-man_ joined
jmerelo Just a reminder that the call for ideas for Outreachy is still open github.com/perl-foundation-outreac...2020-ideas 09:36
09:36 sena_kun left
rba tyil: Aha. windows 'gmake install' : gmake: *** [Makefile:55: rakudo-install] Error 2 09:38
tyil: gist.github.com/rba/8b936b99981e91...d8dcc34208 09:39
tyil: maybe this where hankache had do some changes?
tyil that's the exact same error hankache encountered
I suspected that, on windows, there should be a .exe behind the perl6 (line 87 in your gist)
rba tyil: would guess too. 09:40
tyil: patrickb did some circle-ci builds. Will check the them... 09:43
09:44 hungryd4 joined
rba github.com/rakudo/rakudo/blob/mast...config.yml 09:45
github.com/rakudo/rakudo/blob/mast...indows.ps1 09:47
09:48 hungrydonkey left 09:49 jmerelo left
tyil heh, never knew there was a --relocatable flag for rakudo 09:51
lizmat Files=1303, Tests=111207, 211 wallclock secs (28.49 usr 7.90 sys + 2952.19 cusr 277.82 csys = 3266.40 CPU) 09:52
rba tyil: --relocatable doesn't seem to work for 2020.01 yet. 09:55
tyil :( 09:56
--relocatable is not in the main Makefile, but I can add it to the stage where it builds rakudo and see what happens 09:57
do NQP and MoarVM also support a --relocatable? 09:58
also, are there downsides to building rakudo with --relocatable?
lizmat there shouldn't be, I'd say :-) 10:19
.ask chloekek could you give a reply on www.reddit.com/r/rakulang/comments...e_in_raku/ with regards to the status of your GSOC project of last year ? 10:25
tellable6 lizmat, I'll pass your message to chloekek
tyil lizmat: I would think it should be a default if its possible, but I would also assume that the Rakudo devs have a reason not to make it a default yet 10:28
lizmat m: use nqp; my $h := nqp::hash; my $a = "a"; my $p = start { loop { nqp::bindkey($h,++$a,1); nqp::print(" " ~ nqp::elems($h)) } }; loop { nqp::existskey($h,"a") } # why does this stop execution in the "start" block ?? 10:35
evalable6 (signal SIGHUP) 1«timed out after 10 seconds»
lizmat jnthn ^^ ?? 10:36
is that final loop "too tight" ?
FWIW, I was trying to determine whether it was ok for a thread to do an nqp::existkey on a hash that may be changed by other threads 10:37
without locking
10:42 hungrydonkey joined 10:47 hungryd4 left
rba is unable to build successfully on windows :-( 11:05
tyil rba: perhaps best to wait for a reply from hankache 11:06
rba tyil: ok 11:07
tyil (mostly because I don't do Windows so I can't help you out in any significant way)
Altai-man_ got a reply from dyncall folks 11:08
tellable6 2020-02-25T07:02:46Z #raku <jmerelo> Altai-man would you be interested in including a GitHub action in MoarVM repo that test-compiled in Alpine and maybe other environments?
lizmat closed the PR
Altai-man_ lizmat++ 11:09
ok, so we're waiting for a robust fix, cherry-pick that && point 11:11
Also, while we're on it... Anyone here objecting me doing moarvm releases routine (signing tags, updating website etc, except changelog, I think) which samcv usually does? 11:15
jnthn lizmat: It's not OK for a thread to do that, but that program likely won't prove it because I believe spesh knows existskey is pure and will just throw it away. Then you have an empty loop and have the expression JIT fails to insert GC check bug that's already reported 11:17
Altai-man_: No objections from me 11:18
lizmat Altai-man_: nor from me :-) 11:19
jnthn: ok, I think I understand :-)
rba tyil: back on macosx: run spectest with the rakudo-star-2020.01-01-macos-x86_64.dmg - hopefully this gives me a feeling if the build is fine on osx. 11:28
tyil rba: I had one flappy test on GNU+Linux iirc 11:31
it failed once, and 4 consevutive runs after that showed no problems
11:34 sena_kun joined 11:36 Altai-man_ left
Geth rakudo: 83fed5543e | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Use a low level hash for resolved info
 11:56
rakudo: 2cc509c08f | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Make RMD an attribute

So that we only need to look up %ENV<RAKUDO_MODULE_DEBUG> once, when the PrecompilationRepository object is created. Also make the actual RMD messages stand out more in the code for readability.		 12:24
nine lizmat: I wonder if our optimizer is smart enough to make $!RMD := $*RAKUDO_MODULE_DEBUG || sub ($) {}; faster than all the `if $!RMD`. In theory it could optimize away the whole call to the empty sub. 12:30
lizmat you mean the static optimizer ? 12:31
nine no, spesh 12:33
lizmat I have no idea if spesh is smart enough for that
in any case, I don't think it gets called enough to be marked hot enough for spesh to do anything with it 12:34
nine true 12:35
Geth rakudo: f1cdfb1809 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Fix non-lethal typo
 12:37
nine lizmat: but that makes me wonder if the optimizations are actually worth it. Could you measure an improvement? 12:38
lizmat my benchmark atm is the install core modules step, and running that several times and see if the amount of time goes down 12:39
basically run "make install" a few times 12:40
I'm pretty sure most of these opts will not make much of a difference for me...
but I've heard stories of people seeing precomp times of upto an hour in production 12:41
so pretty sure it makes a difference there
nine Well those could be solved by my commits from yesterday. If not then time is probably best spent improving our compilation times in general
Considering that my example application that took almost 2 minutes to compile after a trivial change is really just 6KLOC in 140 modules, I'd not be surprised if really large production code bases with large dependency trees took forever. 12:47
lizmat true, but I'm afraid my qualifications to improve compilation in general, or precompilation particularly, are insufficient 12:49
Geth rakudo: 9d1b3f635c | (Elizabeth Mattijsen)++ | 2 files
Make compiler-id a class variable

Also add Compiler.id as class method for esier access to the compilation ID of the compiler.		 12:51
rakudo: db6d2306d0 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Forgot to changes one occurrence of stagestats
 12:54
12:57 leont joined
lizmat around 3pm 13:19
oops, ww 13:20
13:20 patrickb joined
patrickb tyil, lizmat: --relocatable is an option that can be passed to the `Configure.pl` of rakudo, nqp and moar. It's automatically forwarded. 13:21
tyil, lizmat: From all I know relocatable builds are working fine also in the latest release. The only thing that broke a while ago and only recently got fixed is unicody paths on Windows.
tyil patrickb: neat
patrickb tyil, lizmat: Disadvantages of using --relocatable: You have to build rakudo, nqp and moarvm in the same prefix (so no separate install directories for the three). Also it's not supported on all platforms (e.g. OpenBSD is unsupported). It's also not used much yet and thus not as widely field-proven.
rba: The gcc vs msvc decision is one with many subtile consequences. It influences which libraries you are able to link to. ugexe knows a fair bit about this. I came to the conclusion that it makes more sense to go for msvc (even though installation is a real pain). That's also what I do to create the precompiled packages that are featured on 13:22
rakudo.org.
tyil I can at least add optional support for it in the next Rakudo Star, then 13:23
patrickb tyil: One of the "do it when there are spare tuits" things is changing the Rakudo Star installer (so not the source release, but the compiled one) to be relocatable and enabling selecting the install location. 13:32
tyil: If we are not confident enough with the stability of the relocatable builds we could still create non relocatable builds of star, but I'm not sure that's worth the investment tbh. 13:33
13:34 Altai-man_ joined
patrickb off again 13:34
13:34 patrickb left 13:36 sena_kun left
lizmat nine: is there a specific reason why RAKUDO_PRECOMP_LOADING is using JSON? Wouldn't a string with "\0" joiners suffice ? 13:48
nine lizmat: no, it just was convenient 13:53
lizmat but using JSON is adding a quite bit of overhead
nine A bit...to precompilation which takes forever anyway ;)
lizmat well, looks like "\0" doesn't survive in %*ENV 's passed on with run anyway 13:54
nine bummer 13:55
jnthn Null termination is everywhere at that level, I guess...
lizmat yeah, I gues
Geth rakudo: 7c9951cc52 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Streamline setting up of environment for precompilation

  - use native hash to set up values, nqp::cloned from %*ENV
  - don't use JSON to set up precompilation modules
  - don't actually create a Set for circularity check, use (elem)
  - access dynamic variables only once		 14:04
lizmat nine: shouldn't github.com/rakudo/rakudo/blob/mast...y.pm6#L193 also need a $*OUT.flush ? 14:13
nine lizmat: oh, yes indeed! Nice catch! 14:17
lizmat I'm wondering whether using nqp::say wouldn't make a lot of sense there... 14:18
Geth rakudo: 83ddbabaf6 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Reduce number of $*W lookups

and also make sure we flush precompile-dependencies always		 14:24
14:28 masak joined
lizmat afk for a few hours& 14:32
rba patrickb: Got the message. Will try using msvc later this week. 14:39
tellable6 rba, I'll pass your message to patrickb
rba I have run spectest on macosx using rakudo-star-2020.01-01-macos-x86_64.dmg. Got some errors back. May one with more spectest experience let me know if this is a good or a bad result, please: gist.github.com/rba/a06a6bea615d4f...fa5d915f26 14:41
lizmat t/spec/S32-str/utf8-c8.t always fails for me on MacOS 14:47
the others are TODO's that pass, so also ok 14:48
as in non unexpected
really afk&
15:19 AlexDaniel left, AlexDaniel joined, AlexDaniel left, AlexDaniel joined
japhb lizmat, jnthn: Instead of null-byte separation, what about some other byte from the ASCII control block, like "\x01"? 15:33
15:35 sena_kun joined 15:37 Altai-man_ left
Geth rakudo: 196db682bc | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Fix booboos spotted by nine++
 16:15
16:18 Ven_de_Thiel joined
rba lizmat++ 16:21
lizmat nine: added some debug info around the react block 16:40
for some reason, CompUnit::Repository::Staging is precompiled twice with the same id
(and once as part of -Ilib I guess
so why *is* CompUnit::Repository::Staging not part of the setting ? 16:41
ah, looks like the last recomp is done explicitely 16:43
nine lizmat: well it's not something an ordinary Raku user would need. I also used it as test case for out-of-setting repository implementations which prompted me to actually fix a couple of issues with those. 16:53
lizmat: but it could also move into the setting or even fully into CURI 16:54
lizmat is testing that now :-)
I would love to save ~.5 second for each "make install" 16:55
looks like it works out ok
nine Still it's of no use to the majority of users 17:04
lizmat true 17:10
another question: why are the NativeCall submodules listed separately in the core module install script 17:11
wouldn't they get automatically precomped when NativeCall is precomped ?
nine No, installation needs all modules listed explicitly. Same as in a META6.json file
lizmat why is that ? 17:12
just curious ?
because that *does* shave off about .5 of a make install for me 17:13
and in my interpretation, modules being precomped because they're used in a module being precomped, shouldn't make a difference wrt findability ? 17:14
nine Because having tools parse module files to find out which packages they contain, didn't work out well for Perl. 17:15
lizmat but... this isn't about parsing source files? 17:16
1. NativeCall gets precompiled
2. precompilation encounters a "use NativeCall::Types"
nine That's the reason why we want modules to be listed explicitly in meta data and why installation refuses to guess
lizmat 3. search for precomped NativeCall::Types fails 17:17
4. start up another process to precomp NativeCall::Types 17:18
5. continue with precomping NativeCall
I mean, that's how it works, no ?
regardless of what is in the Distribution info
or am I missing something ? 17:19
nine That's how they would get precompiled, not how they would end up getting installed 17:20
17:22 Ven_de_Thiel left
lizmat aha... so I *was* missing something 17:23
but the precomped file is created at the place it would be to be installed, right?
it's just that the $*REPO wouldn't know about it, so a "use NativeCall::Types" would fail ? 17:24
nine Unless....you're using the Staging repo, as then the precomp file wouldn't even be in the same place
btw. I'd actually love to see install-core-dist.raku getting changed into a build-core-dist.raku and moved to the build stage with the actual installation happening with a simple cp 17:26
lizmat you would have to elaborate on that for me, if you would like me to look into that 17:28
nine Right now the script is running (and compiling) as part of the install target and installing directly into $(DESTDIR)$(RAKUDO_HOME)/core. Now the whole point of the Staging repo is to split compiling and installing, so you can compile with an unpriviledged user and need privileges only for the actual installation. 17:30
lizmat nine: BTW, in the install script, it says 'core' on line 27, and 'CORE' on line 35.... is that correct ?
nine Instead, we should compile into gen/ like we do for all other files and have the install target just copy those files to the final location
lizmat: yes, 'core' is the repository's name while 'CORE' is the distribution's name 17:31
17:34 Altai-man_ joined 17:36 sena_kun left
lizmat wow, getting a internal server error on a push to github 17:48
www.githubstatus.com 17:50
17:51 hungrydonkey left
leont They've been less stable than usual for days now 17:52
jnthn gah, got the internal server error too 17:56
lizmat nine: is there some kind of precomp inspection module, and if not, would it be a good idea for me to write one, allowing me to better grok all of this ? 18:06
nine lizmat: what exactly do you want to inspect? 18:10
lizmat not sure, actually 18:16
I guess, given a directory such as install/share/perl6/core/ 18:18
find out what it thinks is installed
coming from the files in there
(for CUR::Installation of course) 18:19
Geth rakudo: 551c157fa4 | (Elizabeth Mattijsen)++ | tools/build/install-core-dist.raku
Streamline core module install script

  - use fewer dynamic variable lookups
  - change mention of $*PERL to $*RAKU		 18:20
lizmat whee... github's back
nine m: CompUnit::RepositoryRegistry.repository-for-name("core").installed>>.meta>><provides>>>.keys.say 18:26
evalable6 ((BUILDPLAN Test newline NativeCall::Compiler::GNU MoarVM::Profiler Pod::To::Text Telemetry NativeCall::Compiler::MSVC NativeCall CompUnit::Repository::Staging experimental snapper NativeCall::Types))
nine lizmat: CURI is happy to answer that question 18:27
lizmat nine: I get that: I guess I'm more speaking about a sanity test 18:28
hmmm... not sure... but thanks for the pointer for me to further research :-)
nine: if you don't mind, another question: 18:42
github.com/rakudo/rakudo/blob/mast...y.pm6#L224 shows a $checksum is copy
and at github.com/rakudo/rakudo/blob/mast...y.pm6#L234 that's set if no set already
but then at github.com/rakudo/rakudo/blob/mast...y.pm6#L237 we have a new lexical by the same name ? 18:43
perhaps IO::Path could do with a "checksum" method ? 18:47
basically doing a nqp::sha1(self.slurp(:enc<iso-8859-1>)) 18:48
moritz sha1 is basically broken; we shouldn't encourage its use in new applications in userland 18:53
nine lizmat: yeah that second variable is poorly named. Should probably be $unit-checksum or so 18:56
lizmat but why the is-copy and //= 18:57
nine github.com/rakudo/rakudo/blob/mast...y.pm6#L250
lizmat without is copy and just // it would work?
aha!
ok, thanks for the enlightenment 18:58
Geth rakudo: 07643d373e | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Put all checksum making logic in one place

  - making sure we use the same logic everywhere
  - make sure we don't get LTA errors if the slurp failed		 19:07
19:12 lucasb joined
lizmat nine: any special reason why CompUnit::PrecompilationUnit::File only exists within CompUnit::PrecompilationStore::File ? 19:19
19:35 sena_kun joined 19:37 Altai-man_ left
nine lizmat: yes, it's an implementation detail of CompUnit::PrecompilationStore::File 19:57
As such it may know how PrecompilationStore::File works 19:58
lizmat ok, then I wonder why it is not just called "File" in there 19:59
the name with :: sorta implies outside visibility to me 20:00
Geth rakudo: e56eddd848 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationStore/File.pm6
Don't use lock if already initializedo

Also bind the state rather than assigning		 20:01
nine lizmat: err...probably because I'm not 100 % sure how such nested names work :) 20:02
MasterDuke rba: that would be cool, i don't have any other plans 20:16
rba MasterDuke: Yet I realside today, that I‘m unable to join. :-( As I have company event. 20:17
MasterDuke ha
rba Uhh. 20:18
I will ask around if someone of my organiser friends like to take the chance.
[Tux] Rakudo version 2020.02-43-ge56eddd84 - MoarVM version 2020.02-4-gfee45b9b4
csv-ip5xs0.741 - 0.791
csv-ip5xs-206.090 - 6.202
csv-parser23.632 - 23.762
csv-test-xs-200.367 - 0.379
test7.643 - 8.009
test-t1.848 - 1.870
test-t --race0.869 - 0.873
test-t-2030.613 - 31.193
test-t-20 --race8.493 - 8.730
 20:21
lizmat nine: if you create CompUnit::PrecompilationUnit::File with dependencies => ... 20:28
and then call !read-depencies
those dependencies will get added... is that intentional? 20:29
20:29 [Tux] left 20:37 Xliff joined
nine lizmat: no 20:38
lizmat ok, so read-depencies should really reset the @!dependencies
nine I'd like to say that's the nice thing about this class being private: we know how the only user behaves :) 20:39
But yes, resetting @!dependencies would be cleaner
lizmat well, it isn't that clear from the |c in one of the clients :-)
is new-unit called a lot ? 20:40
nine Just once per file we precompile 20:42
lizmat and the dependencies are only direct dependencies, right ?
nine no, they're the transitive dependencies 20:43
A precomp file knows the full list of all dependencies we need to load to make it happy. 20:44
lizmat aha... so that list could become... big
20:45 [Tux] joined
nine Potentially all the modules of your application with all their dependencies. So several hundred to several thousands for really large apps 20:45
lizmat right 20:46
nine I wonder if we could even record the store we expect the dependency to be in. Then we wouldn't have to look up anything but open exactly the files we need. 20:48
20:50 [Tux] left
nine lizmat: I just realized: we call !read-dependencies on all dependencies of the precomp file we're after to get the dependency's checksum. We don't actually use the dependency's @!dependencies though (we do however need to advance the file's read position to the start of the bytecode) 20:53
lizmat so what use is @!dependencies then ? 20:54
if it is just about moving the pointer, then we could do that faster :-) 20:55
like setting the line seperator to "\n\n" and then doing a single .get ?
ah, no, because we need the checksum 20:56
hmmm... there *is* a dependencies method 20:57
20:57 [Tux] joined 20:58 [Tux] left
nine It's necessary for the top level dependency. The one that's requested by the source file we're compiling 21:00
We've got to get that list of transitive dependencies somewhere :)
21:01 [Tux] joined
nine Xliff: just curious. Do you see any change in compile times with this week's rakudo commits? 21:01
lizmat nine: I think the next patch will make a difference 21:02
Xliff nine: Your latest changes have blown up rakudo-precomp-nolock. I haven't had a chance to fix them. 21:11
Every time I try and merge my changes into a new rakudo, it hangs on the final phase of "make install" 21:12
Plus... $dayJob interference. :(
Geth rakudo: 20d3713c83 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationStore/File.pm6
Streamline CompUnit::PrecompilationUnit::File

  - use binding attribute features
  - replace BUILD by a reduced TWEAK method
  - bind instead of assign where possible
  - use nqp::push to collect dependencies (which can get to be many)
  - remove !open method, it was only used in 1 location
  - don't use deprecated slurp-rest, just slurp!
  - rename $!file by much more indicatice $!handle
  - don't read dependencies if we already have bytecode
Xliff I'll let you know when they are fixed again. I am anxious to see what progress has been made.
Latest working rakudo was 2020-1-227
Gotta go.. $dayJob intrudes... again! 21:13
21:13 Xliff left
MasterDuke would it be possible to change the circleci file to autopass instead of autofail until we get it fixed? 21:13
21:34 Altai-man_ joined 21:36 sena_kun left
Geth rakudo: 3134ec7761 | (Daniel Green)++ | src/Perl6/Compiler.nqp
Whitespace consistency fix for --help output
 21:48
MasterDuke why would `- QAST::Op(callmethod ACCEPTS) - QAST::WVal(Int) - QAST::Var(local __lowered_param__2)` cause `This type cannot unbox to a native integer: P6opaque, Str` when the WVal is 1 and the Var is "abc"? 21:51
jnthn m: 42.ACCEPTS("abc") 21:52
evalable6 21:53
jnthn I have no idea...are you looking at --target=ast when you meant to look at --target=optimize, and the optimizer has turned it into something else?
MasterDuke heh, i'm in the optimizer 21:54
github.com/MasterDuke17/rakudo/com...41a9918dbb
jnthn I suspect what you're looking at is not what is being run.
MasterDuke this is the --target=optimize output gist.github.com/MasterDuke17/28c81...2f4c985293 21:56
gist.github.com/MasterDuke17/b0aa4...d121345ff7 all of it 21:57
jnthn Hm, what are you meant to return in a QAST::ParamTypeCheck? 22:00
I thought it was an integer 1 or 0, but it looks like you're returning the parameter 22:01
MasterDuke hm, i can change that
jnthn (Actually a Bool is also fine)
And you'll want to make sure the final non-matching one is falsey also
MasterDuke but that error is occurring in that code, if i call `a(1)` it runs just fine 22:02
jnthn yeah, that'll be why
MasterDuke ? 22:03
jnthn Because it can unbox 1 to use as the "is this passing the type check"
Pass a(0) 22:04
And I bet even if 0 is in the Junction it will fail anyway
22:04 |Tux| left
MasterDuke with 0 i get the normal `Constraint type check failed in binding to parameter '$a'; expected anonymous constraint to be met but got Int (0)` 22:04
jnthn Yes, but did you put 0 into the junction? 22:05
MasterDuke ooo, but yeah, if i put a 0 in the junction i get `Internal error: inconsistent bind result`
jnthn m: sub foo($a where 0 | 1) { }; foo(0)
evalable6
jnthn Right :)
So, it all fits.
22:05 travis-ci joined
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Don't use lock if already initializedo 22:05
travis-ci.org/rakudo/rakudo/builds/655045233 github.com/rakudo/rakudo/compare/0...6eddd8486e
22:05 travis-ci left
MasterDuke hm, guess i need to make sure the whole thing is wrapped in an istrue 22:05
jnthn No, you need to return True or False when it matches or doesn't match, I think 22:06
lizmat yeah, that sometimes works :-)
restarted the one failing job
jnthn If you just wrap what you have in istrue it'll still do the wrong thing
'cus it's evaluating to the value being passed, not the outcome of the ACCEPTS 22:07
bbiab, cooking time
Geth rakudo: b4d32c97ac | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationStore/File.pm6
Streamline CompUnit::PrecompilationStore::File

  - added $!wont-lock attribute to avoid multiple $*W lookups
  - use new attribute traits
  - change BUILD to TWEAK method
  - use binding where possible
  - use foo.e instead of the roundabout foo ~~ :e
  - call .mkdir without checking for existence, we don't check success
  - replace a foo>>.unlink by .unlink for foo
  - tighten up signatures		 22:08
lizmat wow, that's late eating, jnthn
MasterDuke jnthn++ things are working again. alas, not a whole lot faster than before this optimization 22:13
Geth rakudo: 8ac2eecc23 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationStore/File.pm6
De-hllize the loaded cache
 22:22
lizmat .ask nine github.com/rakudo/rakudo/blob/mast...e.pm6#L144 feels like the last .add is in the wrong set of params 22:38
tellable6 lizmat, I'll pass your message to nine
lizmat .tell nine nvm, figured it 22:39
tellable6 lizmat, I'll pass your message to nine
MasterDuke m: my $a; $a = 1.ACCEPTS("abc") for ^1_000; say $a # heh, this creates a 6.1mb profile 22:44
evalable6 False
MasterDuke huh, and why are there 1k calls to Backtrace.new? 22:47
lizmat MasterDuke: a Failure will create a Backtrace
that's one of the things it makes it that heavy
MasterDuke ah
22:48 leont left
Geth rakudo: 4e3e937bc2 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationStore/File.pm6
De-hllize the dir-cache and the compiler-cache
 22:50
23:16 leont joined 23:22 lucasb left 23:35 sena_kun joined 23:36 Altai-man_ left 23:44 AlexDaniel left 23:47 hungrydonkey joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!