00:02 sena_kun joined
[Coke] o/ 00:02
00:03 Altai-man_ left 00:18 vrurg joined, vrurg left 00:27 vrurg joined, vrurg left
Xliff Oi, [Coke]. 00:36
Is it possible to add .WHY.trailing to enums?
At least the entries?
02:01 Altai-man_ joined 02:04 sena_kun left 02:36 chansen_ left 02:38 chansen_ joined 04:02 sena_kun joined 04:03 Altai-man_ left
ShimmerFairy m: enum Foo «Bar #=(explanation) Baz #=(this one's obvious)»; say Bar.WHY.trailing 04:08
camelia Nil
ShimmerFairy Darn, was hoping that would work.
04:46 squashable6 left 04:47 squashable6 joined 06:01 Altai-man_ joined 06:03 sena_kun left
lizmat Altai-man_ : yes please :-) 07:02
07:11 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined
lizmat bisectable6: VM.request-garbage-collection 07:11
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, Output on all releases: gist.github.com/3e31389cb9b5784825...14eeeb6e3d
lizmat, Bisecting by exit code (old=2020.02.1 new=2020.05.1). Old exit code: 1 07:12
lizmat, bisect log: gist.github.com/5f4e627936a29f990a...c2e9a7ca52
lizmat, (2020-04-24) github.com/rakudo/rakudo/commit/e2...5585468532
lizmat, Bisecting by output (old=2016.09 new=2016.10) because on both starting points the exit code is 1
lizmat, bisect log: gist.github.com/60b62c70ccfd29d5d7...107a8d3016
lizmat, (2016-09-27) github.com/rakudo/rakudo/commit/22...0f14b9c05c
lizmat, Output on all releases and bisected commits: gist.github.com/b708aa0a7476554737...aac8646dee
lizmat m: dd VM.request-garbage-collection 07:17
camelia Nil
lizmat ah, the gist is a bit confusing... the «exit code = 1» belongs to the previous list 07:18
so it was in in 2020.05 07:19
07:31 MasterDuke left
AlexDaniel yeah, accepting pull requests for a markdownified version :) 07:37
08:02 sena_kun joined 08:03 Altai-man_ left 08:10 softmoth_ left
lizmat m: use nqp; dd nqp::isconcrete(*) # TIL 08:12
camelia 1
lizmat jnthn: why is that ??
m: use nqp; dd nqp::objectid(*); dd nqp::objectid(*) # appears to be a singleton though 08:13
camelia 70067232
70067232
ShimmerFairy AlexDaniel: on what? 08:23
AlexDaniel ShimmerFairy: bisectable
ShimmerFairy ah, I see. Wasn't sure what you were referring to.
AlexDaniel some bots already produce markdown output in some cases, it's just that bisectable/commitable don't 08:25
I thought it was fine, but lizmat pointed out that it's a bit confusing, I agree 08:26
ShimmerFairy Yeah, I took a peek and it's a bit terse at the moment :)
08:38 unclechu left, AlexDaniel` left 08:40 Summertime left 08:41 Summertime joined 08:49 unclechu joined 08:52 Summertime left 08:53 Summertime joined
sena_kun lizmat, gist.github.com/Altai-man/e9021b2f...e3216ddc83 08:53
09:05 AlexDaniel` joined
jnthn lizmat: * is a Whatever instance; were it just represented by the type object, and we want everything to smartmatch True against it, then for example Int ~~ Whatever would come out true 09:11
lizmat m: dd Int ~~ Whatever 09:12
camelia Bool::False
lizmat m: dd Int ~~ *
camelia WhateverCode.new
jnthn Well yes, it promotes in that particular syntactic case, but there's implicit places too
lizmat I'm not sure I'm following ?
in any case, there was a reason for it 09:13
*is
jnthn m: dd Int ~~ Whatever.new
camelia Bool::True
jnthn But consider a case like `when * { }` (though nobody really writes that because it's spelled `default`)
Or .grep(*) (again, you'd likely not write it directly, but if you were selecting a matcher dynamically, you could end up with it) 09:14
lizmat yeah, I see now 09:15
m: dd Whatever.new =:= Whatever.new # perhaps we should make that True ?
camelia Bool::False
jnthn No 09:19
I don't even know if it's a true singleton or a singleton per compilation unit
m: dd Whatever.new === Whatever.new
camelia Bool::False
jnthn That could arguably be True
09:20 stoned75 left
lizmat ok, that should be easy to fix :-) 09:20
jnthn Though I'm not sure i see the value
lizmat well, arguably internally testing could be using an nqp::eqaddr against *
jnthn Just use istype, I think
lizmat that's what's being used now, but isn't that a lot more involved ? 09:21
jnthn It's not that expensive anyway, and it specializes away
lizmat ok
then I'll stop meddling with that :-)
it's just that I was very suprised to learn about the difference between * and WHatever
jnthn We're pretty good at optimizing out istype whenever there's some amount of stability around it
Because it's the op used in the compiled signatures 09:22
09:22 stoned75 joined
jnthn And we certainly want to optimize the type checking cost out there 09:22
lizmat ack
jnthn OK, time for some RakuAST work... :) 09:29
10:01 Altai-man_ joined 10:03 sena_kun left
AlexDaniel has anybody tried looking into modules listed in CyclicDependency row? 10:17
Geo::Hash build-depends on Geo::Hash::CustomBuilder which is provided by Geo::Hash 10:19
so… it depends on itself?
is this allowed?
same for MeCab
jnthn That sounds odd to me; I thought *-depends was all about stuff to be installed in order to install the current distribution 10:20
So I suspect it's confused
nine It shouldn't be allowed 10:25
ShimmerFairy I could see that being helpful if you need to compile modules in a certain order, if there isn't already a way to specify that. 10:39
AlexDaniel okay, so, it doesn't work any other way 10:42
[Algorithm::HierarchicalPAM] Could not find Algorithm::HierarchicalPAM::CustomBuilder in:
lizmat hmmm.. I'm seeing that Regex.ACCEPTS uses a braid and a fail_cursor sentinel, yet Str.match does not
jnthn: is there any reason why Str.match shouldn't use a sentinel braid and fail_cursor as well ?
AlexDaniel so I should make Blin ignore modules that depend on themselves? 10:43
lizmat
.oO( --solipsism=off )
Altai-man_ It seems like people were wrongly assuming that custom module builder won't be called for you by zef automagically and you need to specify that. 10:44
AlexDaniel Altai-man_: no, it seems like it doesn't work otherwise
Altai-man_ AlexDaniel, oh? Zef handles them fine? 10:45
Or, the other way, zef doesn't handle them either way?
AlexDaniel Altai-man_: hmm not sure I understand. Point is, removing that line from META6.json results in zef being unable to install the module
Altai-man_ AlexDaniel, is it installable with the line? 10:46
AlexDaniel yes
Altai-man_ Does Blin have a custom check for cyclic dependencies detection?
AlexDaniel yes 10:47
it handles dependency resolution by itself because it needs to decide on the order it'll be trying to install the modules 10:48
I didn't want it to hang on wrong META6.json's so I added the check
and it did hang, IIRC :) 10:49
Altai-man_ Zef itself handles `zef install Foo::Dependencies::A-on-B` correctly. I think Blin should be patched to not mark those modules as wrong.
AlexDaniel what? it can install that???
how
Altai-man_ Just tried that. 10:50
Honestly I expected it to say "Cycle, won't do" but it just installed. :)
AlexDaniel … weird
Altai-man_ I am not sure if that's expected, likely yes, but I don't think that's weird. I mean, we allow mutually recursive e.g. class definitions, why not mutually recursive modules. 10:51
AlexDaniel well, uh, zef is still testing them separately 10:52
Geth rakudo/rakuast: 873c1e1639 | (Jonathan Worthington)++ | 6 files
Compile lexical named subroutines via RakuAST

This is a little cheaty so far, in that it doesn't really properly handle scope declarators. However, it's enough to pass the subs sanity test.
AlexDaniel so they're installable simply because there are no proper tests that attempt to use the other module
in real world I don't know what's gonna happen 10:53
but OK, blin should be relaxed a bit, fine
Altai-man_ Yes, regardless of the case above. I mean, if something can be installed with `zef install ...` and Blin says its invalid, then I would bet on zef. 10:54
AlexDaniel well, I'd say blin is a bit smarter and is able to detect questionable practices :P 10:56
Geth nqp: e181c207c2 | (Elizabeth Mattijsen)++ | src/QRegex/Cursor.nqp
Micro optimize !cursor_fail

And let them be all bound as one.		 11:21
nqp: d45df11b96 | (Elizabeth Mattijsen)++ | docs/ops.markdown
Merge branch 'master' of ssh://github.com/Raku/nqp
nqp: 1027da8eae | (Elizabeth Mattijsen)++ | src/QRegex/Cursor.nqp
Simplify braid initialization in cursor_init

It's not much, but it's done for *every* match
lizmat hmmm.. not sure where that second commit came from 11:22
nine AlexDaniel: we certainly didn't think of distributions that bring their own builder. We only though about using an external one like Distribution::Builder::MakeFromJSON 11:24
AlexDaniel: I really don't see a reason for Algorithm::HierarchicalPAM to bring its own in the first place though. It seems to be subclassing Distribution::Builder::MakeFromJSON but for no apparent reason 11:25
AlexDaniel nine: yeah but Foo::Dependencies::A-on-B ?
like, why is zef fine with that 11:26
although, yeah, not saying that it should do any extra checks 11:27
nine Well it is weird that it can install that. It should do extra checks. And circular dependencies should not be allowed. They are not needed and will cause issues. 11:29
AlexDaniel nine: so what should Blin do? That's the only question I have now 11:30
if a module depends on itself, then it's OK and ignore that?
if it depends on something else and it ends up being a case of circular dependencies, then it should complain? 11:31
like, then Blin should say something about it
nine Well since Blin is a tool to regression test rakudo, it should ignore modules with clearly wrong dependency information.
AlexDaniel that's arguable. But either way, what is wrong exactly? 11:32
like, define “wrong dependency information”
nine Circles definitely are wrong. Dependencies need to form a tree. 11:33
AlexDaniel nine: as for “it should ignore”, it's kinda the opposite. Since it is a tool to regression test rakudo, it should attempt to use as much code as possible to find as many regressions as possible. This includes trying to install modules with broken META6.json because their tests can still show issues in rakudo 11:35
but it's easier said than done :X
Geth nqp: e6ef8a4e50 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get native return JITting
 11:36
nine An edge case would be e.g. if A-on-B depends on B-on-A and B-on-A depends on A-on-B, but only one of them build-depends on the other. Because in such a case we can at least determine a proper order of installation.
Geth rakudo: 8d2156b007 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get some MoarVM/NQP micro-opts

  - JIT native return ops
  - micro-optimize creating cursors		 11:48
lizmat have I said recently that I hate git branches? 11:55
so I just committed ^^^ to the main branch
I go back to my "match-refactor" branch and do a "git rebase master" right? 11:56
how can I get conflicts then???
Altai-man_ Something was changed in the files on master and now your branch can't be rebased? 11:57
lizmat master and match-refactor were both up-to-date
the bump was the first commit in almost a week! 11:58
AlexDaniel so why not just fix the conflicts?
lizmat there are *many* with a refactor of Match, which basically rewrote 70% of the file
AlexDaniel if there are many conflicts then there are many conflicts? 12:00
you can maybe try --strategy-option patience to have it attempt to resolve some of them by itself, but actually I don't understand the question :) 12:01
12:02 sena_kun joined 12:04 Altai-man_ left
sena_kun lizmat, can you please show your file with conflicts? If nothing was changed on master in this area, you should have no issues with rebasing your branch. 12:12
lizmat well, I fixed up all of the conflicts
what I don't understand is how 1 change in master, can cause conflicts in my branch, when the changed file in master wasn't touched in the branch 12:13
sena_kun That's exactly what I am wondering about, it sounds impossible. Conflicts give you comparison between the branch you rebase onto and currently applied commit results, so that's what is interesting. 12:14
Geth rakudo/match-refactor: 24 commits pushed by (Elizabeth Mattijsen)++
review: github.com/rakudo/rakudo/compare/0...1f6c01835b		 12:17
lizmat maybe that will help 12:18
timotimo lizmat: i think the rebase problme could come from the fact that it puts your commits from the branch that are not on master yet on top of the newest master commit one-by-one; whether the versions at the very newest point are the same isn't as important since it replays the whole change history 12:45
you could rebase it by "squashing" all commits from match-refactor into one; that removes the history of how it came to be, but should lead to conflict-free results almost all the time? 12:46
lizmat so that means I need to go through the same rigamarole I do a rebase from master ? 12:47
sena_kun timotimo, this is hardly a good solution because all the history is lost.
lizmat the hacky fix is to copy the files in question before the rebase, ignore all of the conflicts, and put the files back afterwards 12:48
yuck
sena_kun lizmat, no, usually there are no problems. I mean, there are conflicts if e.g. 1)someone changed Foo.pm6 on master; 2)You changed Foo.pm6 on branch-foo earlier; 3)You rebase branch-foo on master and get conflicts in Foo.pm6 because the file changed on master was not that one you edited originally in the branch. 12:49
lizmat what I don't understand then is that apparently git is not able to squash all the work in the branch in a single commit, and the apply that ?
timotimo it is, but only if you ask for it
which will kill the history
if you don't do that, it will try to give you a sensible history at every step of the way
sena_kun But if nobody has touched those files on master, something is fishy. I mean, it is just impossible. Git will just re-apply your commits on untouched files, that's all. 12:50
timotimo if you only merge, then you see both histories as they were, and then just a single spot where conflicts had to be resolved, at which point you can use --strategy=ours to say "if there's a conflict, just paste my file over everything"
lizmat will try --strategy=ours next time 12:51
timotimo++
timotimo rebase makes the history nicer by pretending you've started your work after whatever changes on the other branch have already happened, but the cost is that it has to make sense of your work "in the new context" at every commit 12:58
nine lizmat: do you have rerere active?
lizmat que?
I guess that'd be a no ? 12:59
timotimo hehe
nine man git-rerere
timotimo it's a funny name ofr a good feature
nine rerere = reuse recorded resolution
It means git remembers how you solved a conflict and will auto apply the same solution in the future
lizmat now, that seems like a very valid option, why isn't that the default? 13:00
nine Don't know. Maybe because there's the tiny chance that the resolution doesn't apply and it silently breaks your code this way. But that's never happened to me. 13:01
lizmat hmmm... this seems to apply to "git merge master", not "git rebase master" ?
nine no, it's for merges and rebase
Geth rakudo/rakuast: 8dfaa39388 | (Jonathan Worthington)++ | 7 files
Prepare declaration model for multiple scopes

Many elements can accept a range of scopes, so a "this is a lexical declaration" role doesn't really model things well. Instead, remove it and just have RakuAST::Declaration carry a scope. Also, nodes can now specify their default scope and their acceptable scopes; the latter will be used for generalized error checking of mis-scoped things later on. ... (5 more lines)		 13:09
13:20 vrurg joined
Geth rakudo/rakuast: 16b0bda3ee | (Jonathan Worthington)++ | 2 files
Parse and attach various scope declarators

However, we don't yet respect what they mean in the RakuAST nodes.		 13:24
rakudo/rakuast: fd4b88c8b3 | (Jonathan Worthington)++ | 4 files
Rename variable declaration node

To better following the naming approach taken elsewhere in RakuAST.
nine What the?! If I give the CompilerServices class a BUILD method, this suddenly doesn't list the BUILDALL method anymore which makes one of our tests fail: 13:26
m: class { has $.bar }.^methods».name.sort.say
camelia (BUILDALL bar)
jnthn ...huh :) 13:27
jnthn is currently trying to remember how our-scoped vars work 13:28
nine Oooh...of course. I simply forgot the pre-exsting attributes. They want initialization from BUILD arguments 13:31
I'm kinda surprised that this didn't explode much more violently 13:32
jnthn That makes much more sense 13:33
Just discovered that `our $x` in the current compiler goes and makes a container descriptor and all that lot...only to not use it *at all* because it just binds a symbol from the stash over it at block entry
Another one of those little bits of wasted work 13:34
13:38 vrurg left 13:39 vrurg joined
[Coke] jnthn++ nine++ timotimo++ lizmat++ # various 13:39
timotimo we have barely any "our" vars in the core setting, right? what a waste of throwing out wasted work :) :) 13:41
nine
.oO(Isn't lamenting the waste of throwing out waste...waste?)
 13:42
lizmat counts 12
bur aren't unqualified classes not "our" as well ? 13:43
jnthn Yes, but this is only about our-scoped variables
Test has a bunch of them, I think 13:44
lizmat counts 0 in the core setting
jnthn Or at least, it better do, because they're in the sanity tests
13:44 Xliff left
jnthn To be clear, I'm not expecting a big saving from this, it's just another example where the current compiler code is being suboptimal 13:45
[Coke] go faster by standing still! 13:48
timotimo right :) 13:52
14:01 Altai-man_ joined 14:04 sena_kun left
Geth rakudo/match-refactor: 54dfd63d48 | (Elizabeth Mattijsen)++ | src/core.c/Match.pm6
Simplify the capture vivification check logic

A nano-optimization at best		 14:16
lizmat Altai-man_ : did you post a link for a recent blin run ? 14:20
Altai-man_ lizmat, yes?
lizmat, colabti.org/irclogger/irclogger_lo...-06-30#l65 <- 14:21
lizmat I was looking for Altai-man_ not sena_kun :-)
Altai-man_ Sorry. :(
14:31 krunen left, krunen joined
lizmat Altai-man_: no pb ++! 14:38
Altai-man_ releasable6, status
releasable6 Altai-man_, Next release in ≈18 days and ≈4 hours. There are no known blockers. Changelog for this release was not started yet
Altai-man_, Details: gist.github.com/317f33fc0864ab33f5...d51a676beb
Geth rakudo/rakuast: 3ca740d7a7 | (Jonathan Worthington)++ | 5 files
Add RakuAST support for our-scoped vars

These don't actually work in the RakuAST-based compiler yet, however, because it doesn't declare an implicit $?PACKAGE.		 14:40
jnthn Ah, a yak tower... :) 14:42
Well, not so bad, but it turns out I need to deal with implicit declarations before this can really work out in the RakuAST-based compiler
And also to set up a GLOBALish and so on
15:33 softmoth_ joined 15:50 leont_ joined, leont left 15:52 jmerelo joined 16:02 sena_kun joined 16:04 Altai-man_ left
lizmat ok, this took me a few hours to figure out, but it looks like he half-lazy approach to vivifying Match objects won't work 16:31
as apparently they can currently get vivified *during* parsing of a grammar 16:32
which then misses additional Matches, because the get added to the cstack *after* having been vivified 16:33
so it looks like it needs to go back to calling .MATCH on each Match object anyway
and do the vivification there 16:34
timotimo ah, dang 16:38
but we should be able to know whether we're mid-parse or post-parse actually?
lizmat not inside the Match object you don't
afaik ? 16:39
afk for a bit&
timotimo hmm. dynamic vars don't have the best performance
lizmat there's a reason the say sub caches them so $*OUT doesn't need to be looked up twice
Geth rakudo/rakuast: f40f9740e9 | (Jonathan Worthington)++ | 4 files
Support interpolating closures in RakuAST
timotimo and calling a method on the match object when the corresponding match has finished would be possible, but perhaps also too much of an impact; and setting an attribute directly wouldn't be too bad perhaps, but makes match objects bigger again
lizmat well, that's exactly what .MATCH does 16:40
everywhere, when a cursor is ready, the .MATCH method is called
and it was *that* overhead I was trying to get rid of in the first place
Geth rakudo/match-refactor: 98ee23e46f | (Elizabeth Mattijsen)++ | 4 files
Revert "Remove the most obvious uses of Match.MATCH"

This reverts commit 3a759869462e0ff590b32be4e4448e61ab4e807c.		 16:42
lizmat *sigh& 16:43
timotimo ah dang 16:44
16:46 jmerelo left
Geth rakudo/rakuast: ff6567d90a | (Jonathan Worthington)++ | src/Raku/ast/scoping.rakumod
Add a mechanism for implicit declarations

We'll have the AST produce and take care of these. So, for example, if you make a `RakuAST::Sub`, then it will automatically have `$/`, `$!`, and `$_` set up (unless they get declared in the signature). This will also deal with the `$?PACKAGE` and friends that are declared inside of packages.		 17:05
17:07 softmoth_ left 17:39 squashable6 left
Geth rakudo/rakuast: f9b1b4a144 | (Jonathan Worthington)++ | src/Raku/Actions.nqp
Locate the EXPORTHOWs, in preparation for packages
 17:40
17:41 squashable6 joined 18:01 Altai-man_ joined 18:04 sena_kun left 19:04 MasterDuke joined 19:38 lichtkind joined 20:02 sena_kun joined 20:04 Altai-man_ left
lizmat moritz jnthn something I don't understand about Match.MATCH in its current incarnation 20:51
at the end of it, it sets the flag that it has been vivified ($!match <- NQPdidMatch)
which implies that vivification will never happen for that Match object anymroe
however, the cstack and regexsub are only nulled if there is no bstack 20:52
but how can it ever vivify again if the flag has been set?
so why aren't cstack and regexsub not reset always ? 20:53
moritz totally spitballing here, but it could it be due to backtracking maybe happening even after a match has been formed? 20:54
like / ( .*) { say $/ } <thing-that-can-cause-backtracking> / ?
lizmat moritz: but that would not change anything on @!list and %!hash ?
so even if the backtrack would remove stuff from the cstack, they would still be visible with AT-POS and AT-KEY ? 20:55
moritz hmmm 20:56
no idea; just the thought that you could try to add nulling them, and see what kind of tests break (if any)
moritz barely even coherent anymore, and likely not helpful 20:57
sleepy time here, hugs all around &
lizmat moritz++ # sleep well! 21:00
sena_kun lizmat, o/ 21:03
Want another run?
lizmat no, not yet
sena_kun Oki. Have a good night. o7
lizmat didn't push the fix for the last fails yet
good night! 21:04
21:33 softmoth_ joined
jnthn lizmat: Backtracking into a failed cursor actually makes a new cursor, and the old one (with any created match object) is discarded 21:33
From memory, !cursor_next is the place to look
(I'm as tired as the rest of you, so this is the answer to the question I think is being asked.. :)) 21:34
lizmat jnthn++ 21:35
21:53 softmoth_ left
timotimo is finally doing everything necessary to get his blog back up 21:59
22:01 Altai-man_ joined 22:04 sena_kun left
timotimo i wonder what (if at all) 6guts should be renamed to ... ragout? rakuts? raguts? rakuguts? 22:14
lizmat entrails? 22:16
rakoontrails
rakutales
Altai-man_ assumes 6guts content is smart enough for the readers to handle a name with some history 22:24
22:31 lichtkind left
lizmat m: .say for "abc" ~~ /(.)(.)/ 22:34
camelia Died with X::Method::NotFound
in block <unit> at <tmp> line 1
lizmat that's not very informative, now, is it ?
22:35 stoned75 left
AlexDaniel timotimo: raku-guts :P 22:37
22:37 stoned75 joined
AlexDaniel what's with this desire to obfuscate x) 22:38
Geth whateverable: 55cfbe31b0 | (Aleks-Daniel Jakimenko-Aleksejev)++ | 13 files
Make sure Reply is mixed in

Otherwise a gisted reply will lack some basic information (bot name, query, etc.).		 22:39
rakudo: 0a86798fe2 | (Elizabeth Mattijsen)++ | src/core.c/Exception.pm6
Make method not found error reporting a little more resilient
 22:40
timotimo raku'guts 22:42
lizmat m: .say for "abc" ~~ /(.)(.)/ 22:43
camelia Died with X::Method::NotFound
in block <unit> at <tmp> line 1
lizmat that should become: No such method 'package' for invocant of type 'NQPRoutine'
to fix that, I'm going to sleep on that one... 22:45
&
timotimo have a good sleep!
who wants to have a look and see if wakelift.de appears functional or has some kind of bug somewhere? 23:00
MasterDuke articles seem to work 23:03
23:13 reportable6 left, tellable6 left, bisectable6 left 23:14 bisectable6 joined, tellable6 joined 23:15 reportable6 joined
timotimo thanks 23:30
i may not even bother setting up a not-the-default theme 23:39

Powered by Cro and the Raku® Programming Language.

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

Thank you!