01:10 sena_kun joined 01:11 Altai-man_ left 02:23 camelCaser left 02:25 camelCaser joined 03:09 Altai-man_ joined 03:12 sena_kun left 05:10 sena_kun joined 05:11 Altai-man_ left 06:00 Altai-man_ joined 06:03 sena_kun left
raku-bridge <DataKinds> the "I'm feeling lucky" button on modules.raku.org/ leads to a 404 page 07:04
07:15 JJMerelo joined 08:01 sena_kun joined 08:03 Altai-man_ left 08:05 patrickb joined 08:19 JJMerelo left 08:24 JJMerelo joined 08:33 JJMerelo left
lizmat Files=1307, Tests=113013, 218 wallclock secs (29.02 usr 8.19 sys + 3041.01 cusr 288.77 csys = 3366.99 CPU) 08:33
09:07 squashable6 left, squashable6 joined 09:29 lichtkind joined 10:01 Altai-man_ joined 10:03 sena_kun left
Geth rakudo/match-refactor: 254cd94592 | (Elizabeth Mattijsen)++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
Remove the Raku specific bits from RegexCaptures

And also make the setup of the capnames derived info lazy.		 10:16
jnthn lizmat: Seeing that reminds me: be careful to test a module that involves a slang (mixing into Perl6::Grammar), since I broke that last time I tinkered with this stuff. 10:18
(Maybe you'll have been more careful. But worth a check.)
lizmat I'm also testing Inline::Perl5, and it indeed broke a test
10:19 JJMerelo joined
lizmat looks like I will either need to rewrite the NQP version of Match object as well, or keep that alive :-( 10:21
ok, I think the Inline::Perl5 issues is now down to Inline::Perl5 10:25
Slang::Tuxic is ok
Geth rakudo/match-refactor: d5927855f7 | (Elizabeth Mattijsen)++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
Oops, need to check tyhe right attribute

Inline::Perl5 now down to just failing tests, instead of bombing. Slang::Tuxic clean now		 10:30
lizmat fwiw, CircleCI is spamming me again, telling me my builds fail on Linux 10:38
Altai-man_ lizmat, I think the original bug was not fixed? 10:49
Not github.com/MoarVM/MoarVM/pull/1317 nor github.com/MoarVM/MoarVM/pull/1318 are merged.
Geth rakudo/match-refactor: 08ec3f167b | (Elizabeth Mattijsen)++ | src/core.c/Str.pm6
Make matching slightly more optimal

  - returning a Match object is now a no-op
  - returning a string is now just calling .Str
Altai-man_ Without this moarvm fails to build there, so it is a valid check failure.
lizmat I guess :-( 10:50
not sure how that situation could be improved, but it is pretty annoying now :-)
Altai-man_ I would just fix the offending loop var declaration, to be honest. I mean, we are using this style everywhere and there is a single case which goes the other way and fails and still. 10:51
lizmat, I wholeheartedly agree with you here. :)
Geth nqp: 3cc1f805ea | (Elizabeth Mattijsen)++ | src/QRegex/Cursor.nqp
Simplify Cursor!cursor_pass

  - don't check for $backtrack twice
  - Cursor!reduce returns self, so we can use a ternary		 11:07
patrickb I merged the MoarVM fix for this. Review was still missing but we can revert. 11:10
nine lizmat: so did I do anything wrong? 11:18
Or rather what did I do wrong?
Geth rakudo/match-refactor: 19f0f53e0b | (Elizabeth Mattijsen)++ | src/core.c/Match.pm6
Remove now superfluous Match.STR

Unfortunately, Match.MATCH can *not* be removed, as some types of cursor (specifically cursor_pass, which is used by INTERPOLATE) are still trying to call MATCH from nqp.		 11:19
nqp: bbdfe50b51 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get latest build fixes
 11:27
11:35 JJMerelo left
Geth rakudo: f1960baa9f | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get MoarVM build fixes

And a tiny regex opt as well.		 11:38
lizmat hmmm... one linux build now passes 11:44
12:01 sena_kun joined 12:03 Altai-man_ left
lizmat jnthn: tryfindmethod is one of the methods that the GDO will make obsolete, right ? 12:22
sena_kun: could you schedule a Blin run for the "match-refactor" branch ? 12:27
sena_kun lizmat, can do tonight, if you're not in a hurry. 12:28
lizmat not in a hurry, I know I borked Inline::Perl5, but that one is hard to debug 12:29
hoping for another borked module that will be easier to debug :-)
sena_kun lizmat, fair enough. Will do! 12:30
dogbert17 lizmat: are you refactoring, optimizing or both? 12:33
12:33 timotimo left 12:35 timotimo joined
lizmat dogbert17: both 12:41
basically going from: vivify anything possible in a Match object always, to not vivifying anything and just looking things up when needed 12:42
the new Match object does *not* have $!list or $!hash attributes
so it its a lot easier on the garbage collection side, at the possible expense of more CPU 12:43
spectest at the moment seems not to suffer from it, and that's with still a lot of the old scaffolding in place 12:45
Str.match will need another refactor as well, but that's ok
dogbert17 I'm stresstesting it now :-) 12:46
lizmat cool! 12:47
afk for a few hours, "enjoying" the 30 degree heat while cycling&
dogbert17 will take a little longer than usual, have lots of debug flags enabled in MoarVM
bring some water :) 12:48
jnthn lizmat: correct 13:11
13:13 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 13:18 greppable6 left 13:19 sena_kun left, sena_kun joined
nine nine's empirical approach to software developement. It doesn't burn yet? Poke at it till it explodes. Then poke at it some more and take note of how it burns differently. When the flame goes out, commit. I swear, that's literally what I do all day. 13:36
timotimo i hope your fireproof gloves are comfortable 13:37
random idea that occured to me just now: a cro middleware that looks for a "X-TakeMVMHeapDump" header; if present, a mvm heap dump can be taken relative to the processing of the request 13:39
i can think of a bunch of different conditions you could pass; "before", "after", "start + 1s", "start + 100kB", etc 13:40
14:01 Altai-man_ joined 14:03 sena_kun left 14:14 notable6 left, coverable6 left, evalable6 left, benchable6 left, statisfiable6 left, nativecallable6 left, reportable6 left, quotable6 left, bloatable6 left, linkable6 left, committable6 left, tellable6 left, sourceable6 left, releasable6 left, shareable6 left, bisectable6 left, squashable6 left 14:19 coverable6 joined, reportable6 joined, quotable6 joined 14:20 notable6 joined, bisectable6 joined, unicodable6 joined, sourceable6 joined, benchable6 joined, evalable6 joined, shareable6 joined, bloatable6 joined 14:21 greppable6 joined, squashable6 joined, releasable6 joined, linkable6 joined, nativecallable6 joined, statisfiable6 joined 14:22 committable6 joined, tellable6 joined
nine Hm...there are a couple of spec tests failing with messages like "reference to context outside of SC for 'parameterize' (SETTING::src/core.c/Hash.pm6:766)" 14:23
But these errors only happen on the first try. Once their dependencies are precompiled the errors disappear 14:24
timotimo statisfiable6: libmoar 14:37
statisfiable6 timotimo, OK! Working on it…
[Tux] Rakudo version 2020.06-7-gf1960baa9 - MoarVM version 2020.06-6-gbf6af07de
csv-ip5xs0.816 - 0.833
csv-ip5xs-208.023 - 8.403
csv-parser24.311 - 25.952
csv-test-xs-200.387 - 0.396
test7.544 - 7.692
test-t1.914 - 1.934
test-t --race0.819 - 0.922
test-t-2030.549 - 32.282
test-t-20 --race9.288 - 9.490
 14:49
AlexDaniel timotimo: I don't know if this is going to work, I haven't tried it in months
statisfiable6 is one of those bitrotted bots, but it should be kinda functional
timotimo yeah 14:50
rba: do we have any WIP or docs or ideas about monitoring all our servers and apps and bots and such? 14:52
it looks like infrastructure-docs has been nommed into problem-solving?
AlexDaniel there's still a repo: github.com/Raku/infrastructure-doc 14:54
but yeah, sort of
timotimo wtf
i swear i put in search terms that should really have found that repo
but yeah that looks to be sufficiently out of date 14:58
[Coke] oh, I fixed the readme *then* noticed that that really was perl6 and I'm not sure any of those hosts are still a thing 15:13
timotimo what is? 15:14
[Coke] the repo. I just reverted. 15:15
15:27 JJMerelo joined 16:02 sena_kun joined 16:03 Altai-man_ left
gfldex raku: say @a[0..10]; say @a[5]:exists; 16:05
evalable6 (exit code 1) 04===SORRY!04=== Error while compiling /tmp/WicOu8VaN1
Variable '@a' is not declared
at /tmp/WicOu8VaN1:1
------> 03say 08⏏04@a[0..10]; say @a[5]:exists;
gfldex raku: my @a is default('fill') = 1,2,3; say @a[0..10]; say @a[5]:exists; 16:06
evalable6 (1 2 3 fill fill fill fill fill fill fill fill)
False
gfldex raku: my @a is default('fill') = 1,2,3; say @a[5].defined; @a[5]:exists;
evalable6 True
gfldex raku: my @a is default('fill') = 1,2,3; say @a[5].defined, @a[5]:exists;
evalable6 TrueFalse
gfldex :D 16:07
this is a fine riddle!
MasterDuke bisectable6: my @a is default('fill') = 1,2,3; say @a[5].defined, @a[5]:exists; 16:09
bisectable6 MasterDuke, Will bisect the whole range automagically because no endpoints were provided, hang tight
MasterDuke, ¦6c (44 commits): «TrueFalse␤» 16:11
MasterDuke, Nothing to bisect!
gfldex raku: my @a is default('fill') = 1,2,3; @a = @a[5]:delete; say @a[5].defined, @a[5]:exists; 16:12
evalable6 TrueFalse
statisfiable6 timotimo, gist.github.com/2411ac644103b7e73d...a416d065c5
gfldex This is so cool. We delete it, it's still defined but never existed. 16:13
timotimo i mean you have a default, right? 16:15
[Coke] DIHWIDT 16:19
raku: my @a = 1,2,3; @a = @a[5]:delete; say @a[5].defined, @a[5]:exists;
evalable6 FalseFalse
16:48 sivoais left 17:00 sivoais joined 17:13 MasterDuke left
AlexDaniel timotimo: wait what, it worked?? 17:16
statisfiable6: core 17:18
statisfiable6 AlexDaniel, OK! Working on it…
18:01 Altai-man_ joined 18:03 sena_kun left 18:07 JJMerelo left
timotimo wait what what worked? 18:13
was that the same request i had started a few hours ago? :) 18:14
AlexDaniel timotimo: yes 18:45
timotimo lmao, oh crap 18:46
AlexDaniel well, it actually makes sense. It had to unpack every archive and look inside. Now that it finished, the results are cached so next query for the same stats won't take as long 18:48
83b7acd2 18:49
linkable6 (2017-05-13) github.com/rakudo/rakudo/commit/83b7acd265 Run the Perl6::Compiler.verbose-config when sinking
AlexDaniel so a 50% increase in 3 years :)
statisfiable6 AlexDaniel, gist.github.com/5df4f6f89d895cc4cc...2b63791e3a 18:50
AlexDaniel to the moon! 18:51
ok it's actually linear so not that bad :)
statisfiable6: install 18:52
statisfiable6 AlexDaniel, OK! Working on it…
19:14 lichtkind left 19:41 sivoais left
dogbert17 lizmat: I get the impression that your new branch is a few percent faster than master 19:43
19:44 sivoais joined
lizmat dogbert17: that's promising :-) 19:44
dogbert17 indeed 19:45
timotimo damn 19:54
20:01 sena_kun joined 20:03 Altai-man_ left 20:06 lichtkind joined
statisfiable6 AlexDaniel, gist.github.com/d84b13d00e2bd85d10...06d38bf796 20:27
AlexDaniel timotimo: All three graphs: gist.github.com/2411ac644103b7e73d...a416d065c5 gist.github.com/5df4f6f89d895cc4cc...2b63791e3a gist.github.com/d84b13d00e2bd85d10...06d38bf796
soooo… on that last graph we just jumped by 10M ? 20:28
is it because of this? github.com/rakudo/rakudo/commit/53...b18c331b79 20:29
yes
nine: hello!
20:29 sivoais left
AlexDaniel sena_kun: can you file a ticket maybe? Sounds kinda important 20:30
Geth: ver github.com/rakudo/rakudo/commit/27...df27d49f1e 20:35
Geth AlexDaniel, version bump brought in these changes: github.com/perl6/nqp/compare/2017....0-ga6a1aa0
AlexDaniel Geth: ver github.com/Raku/nqp/commit/a6a1aa0...eee98b028a
Geth AlexDaniel, version bump brought in these changes: github.com/MoarVM/MoarVM/compare/2...3-ga4fef0b
timotimo AlexDaniel: and the "lines of core setting" thing is a future feature? :) 20:39
AlexDaniel yea but… %*BOT-ENV ? 20:40
timotimo ah
AlexDaniel the code in statisfiable is kinda old, I started making it a bit prettier but I'm blocked by that thing
timotimo well i can't reproduce that issue :(
AlexDaniel I'm not sure how to reproduce it too. Maybe it's about calling things from different files? 20:41
timotimo any reason you're not just copying / binding to a lexical?
20:41 sivoais joined 20:42 MasterDuke joined
AlexDaniel it's used in different files, it can't be a lexical 20:42
I understand that dynamic vars is a bit hacky way of doing this, but it's the path of least resistance for what I'm trying to achieve 20:43
and it works, unless I introduce `start` blocks
timotimo stuart blocks 20:50
21:00 finsternis left
lizmat enough social media for today& 21:44
21:56 softmoth joined 22:01 Altai-man_ joined 22:03 sena_kun left
AlexDaniel Altai-man_: filed it myself here: github.com/rakudo/rakudo/issues/3769 22:04
22:25 patrickb left
AlexDaniel timotimo: oooo I think I managed to reproduce it! 22:34
golfing 22:35
m: my %*BAR = :42heh; await start { dd %*BAR; await start { dd %*BAR }; } 22:42
camelia Hash %*BAR = {:heh(42)}
Failure.new(exception => X::Dynamic::NotFound.new(name => "\%*BAR"), backtrace => Backtrace.new)
AlexDaniel timotimo: ↑ that?
m: my $*FOO = 42; await start { dd $*FOO; await start { dd $*FOO } }
camelia Int $*FOO = 42
Failure.new(exception => X::Dynamic::NotFound.new(name => "\$*FOO"), backtrace => Backtrace.new)
AlexDaniel timotimo: github.com/rakudo/rakudo/issues/3770 22:50
jnthn AlexDaniel: stackoverflow.com/questions/575817...d-promises 23:02
AlexDaniel jnthn: okay, I kinda expected something like this. How do I solve it? 23:04
23:04 squashable6 left, softmoth left 23:05 lichtkind left
jnthn AlexDaniel: If you want to keep using dynamics, a fresh dynamic will do (`my $*FOO := CALLERS::<$*FOO>` or some such) 23:06
(I didn't really read the whole discussion, just saw the last bit and recognized what was going on
23:07 squashable6 joined
AlexDaniel jnthn: I don't think you're missing anything 23:07
that's exactly the issue
so… essentially… dynamic variables and start blocks are pretty much mutually exclusive features :S 23:08
maybe I can create some sort of wrapper for `start` to copy the variables I care about 23:09
jnthn The whole dynamic capture thingy sorta annoys me. I argued against doing it at all, TimToady insisted on it, I implemented it, but it turns out it only worked one level deep, and when I looked into resolving *that* I realized it was nasty leaks waiting to happen... 23:10
...so every `start` block pays for a feature that only sort of works.
And that I'm not convinced can be made to work without a memory leak risk or other costs. There may be some way I didn't think of yet, though. 23:11
AlexDaniel jnthn: if they were globals, the only issue would have been name clashing if something decides to declare the same variable again but deeper? 23:13
jnthn Yes, that's pretty much the difference; $*FOO lookups do end up looking in GLOBAL::<$FOO> as a fallback, even. 23:14
And failing that, PROCESS::<$FOO>
AlexDaniel can I declare a global variable? 23:15
jnthn They aren't declared, they just exist. You can use `our` to declare a lexical alias to one 23:16
AlexDaniel yeah but… can I make BOT-ENV global variable exist?
jnthn $GLOBAL::BOT-ENV = blah; # or whatever sigil is appropriate
AlexDaniel ah okay 23:17
great then
jnthn That'll even be found my $*BOT-ENV
Thanks to the GLOBAL fallback
AlexDaniel yeah, that's what I'm thinking, I don't care if somebody tries to use WHATEVERABLE-ENV too
jnthn I agree the dynamic var / start situation is LTA, I just don't know quite what to do about it.
AlexDaniel jnthn: I don't really know what's the use case for all that. Dynamic variables are not really popular 23:18
I just need a total hack and I'll get it with GLOBAL 23:19
jnthn Dynamic variables are occasionally really useful, but I'm glad they're not popular. :) 23:21
AlexDaniel jnthn: I hope this makes sense: github.com/Raku/doc/issues/3497 23:30
what a clickbait title but still 23:31
jnthn :P
It'll do great on reddit or hackernews, I'm sure ;)
It's fine, maybe mention the other solution (rebind the dynamic in the start)
AlexDaniel jnthn: edited, thanks! 23:38
jnthn np 23:39
Guess I should sleep, I'd kinda like to write some code tomorrow, having spent the last couple of days doing slides and recording me trying to say something interesting to go with them... :)
'night o/
AlexDaniel night! 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!