00:00 MasterDuke joined 00:25 hungrydonkey joined
Geth rakudo: 4de852e4e5 | (Vadim Belman)++ | 2 files
Set attribute's rw status when added to a container

It was previously set in `compose_attributes` which is called by
  `ClassHOW` only. This was causing roles always ignoring the default `rw`
status and thus `is rw` trait not having effect on them. This fix presumes that the trait is always applied before attributes are thrown in.
Fixes #3495		 00:30
linkable6 RAKUDO#3495 [closed]: github.com/rakudo/rakudo/issues/3495 [attributes][objects][roles] `is rw` trait applied to roles does not work
Geth rakudo: 85660c8fa2 | (Vadim Belman)++ | 2 files
Apply late `also is rw` trait to the existing attributes

This handles the following case:
  ```
class C {
   has $.a;
... (8 more lines)
rakudo: 40352398db | (Vadim Belman)++ (committed using GitHub Web editor) | 2 files
Merge pull request #3496 from vrurg/rakudo_3495

Support of `is rw` trait applied to roles.
roast: b12064dff5 | (Vadim Belman)++ | 2 files
Add tests for `is rw` trait on roles

In support of rakudo/rakudo#3496 and following rakudo/rakudo#3495
roast: f63ef08b6a | (Vadim Belman)++ | 2 files
Added tests for late applied `also is rw`

No matter when `is rw` is applied, attributes without explicit `is readonly` trait have to repsect it:
  ```
class C { ... (7 more lines)
linkable6 RAKUDO#3496 [closed]: github.com/rakudo/rakudo/pull/3496 Set attribute's rw status when added to an AttributeContainer
roast: c7ecb2d748 | (Vadim Belman)++ (committed using GitHub Web editor) | 3 files
Merge pull request #620 from perl6/rakudo_3495

Add tests for `is rw` trait on roles
01:25 hungrydonkey left 01:34 sena_kun joined 01:36 Altai-man_ left 02:13 ufobat__ joined 02:17 ufobat_ left 02:51 cognomin_ joined 02:54 cognominal left 03:33 Altai-man_ joined 03:35 sena_kun left 04:30 hungrydonkey joined 04:31 hungrydonkey left 04:37 hungrydonkey joined 05:32 hungryd66 joined 05:34 sena_kun joined 05:36 Altai-man_ left, hungrydonkey left
releasable6 Next release in ≈2 days and ≈11 hours. 4 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 07:00
07:33 Altai-man_ joined 07:35 sena_kun left 07:40 cognominal joined 07:44 cognomin_ left
lizmat Files=1303, Tests=111145, 211 wallclock secs (28.80 usr 7.99 sys + 2943.57 cusr 277.35 csys = 3257.71 CPU) 07:52
07:53 domidumont joined
Geth rakudo: 9217b1c763 | (Elizabeth Mattijsen)++ | src/core.c/Hash.pm6
Reduce number of lookups for Hash.DELETE-KEY

If an existing key is removed, it will only do 2 hash lookups
  (atkey and deletekey), whereas before it would do 3 (existskey,
atkey and deletekey). Should make a noticeable difference on larger hashes.		 08:46
lizmat this in reference to github.com/Raku/problem-solving/is...-588535467
afk for a few hours& 09:21
09:34 sena_kun joined 09:35 Altai-man_ left 10:06 hungryd66 left 10:10 hungrydonkey joined 10:12 hungryd10 joined, hungrydonkey left 10:17 hungrydonkey joined, hungryd10 left 10:18 |Tux| left 10:20 hungryd72 joined, hungrydonkey left 10:31 |Tux| joined
sena_kun releasable6, status 10:35
releasable6 sena_kun, Next release in ≈2 days and ≈8 hours. 4 blockers. 60 out of 242 commits logged (⚠ 2 warnings)
sena_kun, Details: gist.github.com/ae7acdd2d2efb3e55e...265faf059a
10:37 hungrydonkey joined
sena_kun I am doing a kind notification the release date is close and we still have some serious blockers. 10:37
10:40 hungryd72 left 10:51 hungrydonkey left 10:52 hungrydonkey joined 11:33 Altai-man_ joined 11:36 sena_kun left
lizmat has annotated her commits of the past month in github.com/rakudo/rakudo/wiki/ChangeLog-Draft 11:45
Altai-man_ ^^ 11:46
Altai-man_ saw it, lizmat++
11:53 MasterDuke left 12:08 hungrydonkey left, hungryd52 joined 12:12 hungryd52 left 12:13 hungrydonkey joined
|Tux| Rakudo version 2020.01-242-g9217b1c76 - MoarVM version 2020.01.1-41-gb0604e575
csv-ip5xs0.694 - 0.705
csv-ip5xs-205.814 - 5.841
csv-parser22.415 - 23.041
csv-test-xs-200.377 - 0.394
test7.476 - 7.510
test-t1.772 - 1.805
test-t --race0.797 - 0.844
test-t-2028.704 - 30.182
test-t-20 --race8.607 - 8.764
 12:18
Altai-man_ is that just me or these numbers are increasing every time I see them? 12:41
lizmat they're fluctuating, but generally haven't been going down for a long time now :-(
12:46 patrickb joined
patrickb Altai-man_, lizmat: tux.nl/Talks/CSV6/speed4.html 12:48
12:52 patrickb left
jnthn bisectable6: 2020.01 HEAD say :($ is raw where True, $ is copy, Int $ is rw, $ is raw where True = 2).perl 13:13
bisectable6 jnthn, Using old=2020.01 new=HEAD in an attempt to do what you mean
jnthn, Bisecting by output (old=2020.01 new=9217b1c) because on both starting points the exit code is 0
jnthn, bisect log: gist.github.com/b7992194f19d10fc26...225cc2dd15
jnthn, (2020-01-17) github.com/rakudo/rakudo/commit/3f...10da3cd756
Altai-man_ jnthn, errata was clean on release. maybe something later influenced the change to start making weird things 13:14
jnthn Altai-man_: It's a straightforward regression that somehow isn't caught by our current tests 13:15
Caused by the commit bisectable6 found
m: say :($).raku 13:16
camelia :($)
jnthn m: say :($ where 42).raku
camelia :($ where { ... })
jnthn m: say :($ is raw where 42).raku
camelia :(\ where { ... })
lizmat bingo
ok, shall I fix that one ?
jnthn committable6: 2020.1 say :($ is raw where 42).raku
committable6 jnthn, ¦2020.1: «Cannot find this revision (did you mean “2020.01”?)»
jnthn committable6: 2020.01 say :($ is raw where 42).raku
committable6 jnthn, ¦2020.01: «:($ is raw where { ... })␤»
jnthn Yes
Please :)
I'll see if I can figure out the other Rakudo blocker, though it's not well golfed... 13:18
lizmat looks like 21b809745d is the one 13:24
linkable6 (2020-01-30) github.com/rakudo/rakudo/commit/21b809745d Actually fix Parameter's handling of default values
lizmat jnthn: should $SIG_ELEM_IS_RAW be set on such a parameter ? 13:27
jnthn No idea 13:29
At a guess, yes
Since it has the `is raw` trait 13:30
lizmat aaah...
duh
jnthn I think the problem largely is that normalzing to \foo is fine in general, but *not* if it's anonymous
lizmat yup, gotcha
13:34 sena_kun joined
lizmat running spectest now 13:35
13:36 Altai-man_ left
Geth roast: d0ee46628c | (Elizabeth Mattijsen)++ | S06-signature/introspection.t
Add test for $#3492
 13:39
rakudo: 2aa4d09596 | (Elizabeth Mattijsen)++ | src/core.c/Parameter.pm6
Make sure unnamed raw parameters have the '$' sigil

Fixes R#3492		 13:40
linkable6 R#3492 [open]: github.com/rakudo/rakudo/issues/3492 [BLOCKER][regression] 6.c/d-errata and S06-signature/introspection.t
sena_kun releasable6, status 13:41
releasable6 sena_kun, Next release in ≈2 days and ≈5 hours. 3 blockers. 139 out of 242 commits logged (⚠ 2 warnings)
sena_kun, Details: gist.github.com/9f45d08ebaf21aba58...e013e61df0
sena_kun lizmat, errata tests run clean?
lizmat runs spectest again :-) 13:42
sena_kun: a lot of TOD passed, but otherwise clean 13:48
sena_kun lizmat++
lizmat *TODO :-)
13:50 pmurias joined
jnthn *sigh* OO::Plugin is a *lot* of code, and somewhere - maybe in Rakudo, maybe in the module - hash randomization causes a behavior change. 14:05
lizmat one obvious hash is the export hash 14:21
jnthn Not sure how it's ordering would come into it though 14:27
I am bumping the back trace every time we do a hash iteration and throwing in `.sort`s in various places to see if it makes a difference... 14:31
14:39 lucasb joined
lizmat jnthn: sanity question: is prefix ⚛ supposed to work on anything else than a atomicint ? 14:41
jnthn Well, or anything of the same size 14:42
lizmat also, what does it mean combined with binding ?
jnthn That's also a native int
lizmat but Holder is *not* a native int ?
jnthn Though what it actually works on is an intlexref or intattrref I guess
lizmat my $holder := ⚛$!holder;
jnthn Oh, I misread :) 14:43
No, it can work on a reference too
It's just an atomic read
Somehow my brain inserted a ++ :P
lizmat so it would also work on an Opaque ?
jnthn Opaque?
lizmat a non-native object
jnthn Typically it's on a Scalar, which has P6opaque representation, if that's what you mean
And it's an atomic read of the $!value of the Scalar 14:44
lizmat ok, that's not clear from the doc: docs.raku.org/type/atomicint#prefix_⚛
jnthn Woudln't that page be about the candidate for atomicint only? 14:45
docs.raku.org/type/Scalar#prefix_%E2%9A%9B
The other candidate is documented there
lizmat ok, I guess that could be cross-referenced 14:46
jnthn Going through all these hash iterator sites will take forever... 14:50
vrurg jnthn: I left a comment on the issue, but there is not much to add. I'll try to do more when over with my daytime work. 14:55
jnthn vrurg: OK. If you build a MoarVM where you tweak `#define MVM_HASH_RANDOMIZE 0` then you'll get the failure very time 14:56
*every time
Or at least, I do :)
I note that the thing it bisects to can make a big difference in the nubmer of hashes that get allocated when doing matching 14:57
So it may be a legit bisect in terms of "yes, the behavior changes here", but not actually to blame. 14:58
I did look through that code to see if there was anything obviously sensitive to hash ordering, but also nothing in Match.pm6 ever shows up in the stack traces of the places we do a hash iteration 14:59
vrurg: I'll leave it for you to look a bit further, with this new info. 15:02
[Coke] jnthn: Could I interest you in github.com/rakudo/rakudo/issues/3057 ? (need to free up file descriptors when using Proc::Async to pipe processes) 15:03
I am happy to offer a pint and a curry in exchange. :)
vrurg jnthn: Sure. Don't waste your time. Thanks!
15:10 hungrydonkey left
jnthn [Coke]: Well, gist.github.com/jnthn/f660e30516a1...a3d082c336 seems to fix it, though need to see what spectest etc. thinks 15:18
15:20 moritz_ is now known as moritz
[Coke] jnthn: I can do the testing bit. 15:21
let me know where to send the curry. :)
jnthn I cant htink of 15:22
oops
I can't think of a reason this patch would cause problems
Though...hmm
Geth rakudo: d18d6e9a35 | (Elizabeth Mattijsen)++ | src/core.c/Lock/Async.pm6
Change cas to nqp::cas in Lock::Async.lock

This appears to at least work around the problems as reported in:
   github.com/MoarVM/MoarVM/issues/1237
With this fix the t/spec/S17-promise/lock-async-stress2.t test runs more than 1000x without breaking. ... (7 more lines)		 15:25
[Coke] jnthn: should I wait or can I start making branches to try this out? :) 15:26
jnthn [Coke]: I'll push it to make things easier to test with
spectest...passed, but I had still got 6.c-errata checked out :P
(from earlier bug hunt)
So now waiting on the proper one :) 15:27
sena_kun releasable6, status
releasable6 sena_kun, Next release in ≈2 days and ≈3 hours. 2 blockers. 141 out of 243 commits logged
sena_kun, Details: gist.github.com/b1cecdbcf80d25d566...f24f7ab3bb
[Coke] jnthn++ 15:29
jnthn dran, it seems to cause a test failure...
*darn
[Coke] I was trying to find a place in Proc::Async::Pipe to fix this, and was coming up empty, thanks.
jnthn Yeah, double closes happen. So it can't be quite that simple. 15:30
language class, bbl 15:31
[Coke] you getting those failures in moarvm itself?
~~
jnthn No, it seems we get them 'cus MoarVM now does a close but then we also .close 15:32
So yeah, needs more thought
15:33 Altai-man_ joined
[Coke] still, thanks for checking. 15:34
15:36 sena_kun left 15:39 hungrydonkey joined
Geth rakudo: 2854144462 | (Elizabeth Mattijsen)++ | src/core.c/Lock/Async.pm6
Change other cas to nqp::cas in Lock::Async
 15:58
15:58 hungrydonkey left 15:59 hungrydonkey joined 16:04 toddr joined 16:09 pmurias left
Geth rakudo: e81e5162d0 | (Elizabeth Mattijsen)++ | src/core.c/Lock/Async.pm6
We already have a simple method to create a kept Promise

So use that :-)		 16:19
[Coke] lizmat: is it worth pre-caching that kept promise? 16:31
s/caching/creating/
Looks like in either #ifdef it's only used the one time.
lizmat you mean, inside Promise? or in Lock::Async 16:32
the ifdef is for the JS backend, that doesn't support locking adaik
*afaik
[Coke] github.com/rakudo/rakudo/commit/e81e5162d0 - looks like you remove KEPT-PROMISE entirely.
you *could* remov...
and use Promise.kept in those two spots directly 16:33
lizmat yeah, but Promise.kept creates a new one every time
now, one could argue that should also be a singleton, but I didn't want to cross that bridge so close before the release 16:34
[Coke] ahhhh. thanks. 16:35
16:38 domidumont left
jnthn Yes, that's an important optimization :) 16:52
(caching the kept Promise for Lock::Async)
Not convinced about making Promise.kept a singleton, might cause a few too many surprises...
lizmat yeah, that's why I didn't do that :-) 17:12
jnthn: fwiw, I feel that the Promise object has become a little overweight, with a lot of unneeded baggage in some, maybe a lot, situations
jnthn: I've added some debugging info, and it looks like 1 in 3 attempts to get a lock fails 17:14
is that something you'd expect for that benchmark ?
*stress test
jnthn [Coke]: Think I've got a properer fix 17:20
lizmat: For sure, it's basically a contention handling test 17:22
lizmat indeed... anyways, for a test, I put in the cas() instead of the nqp::cas() and sure enough, 135 attempts later there was a crash
jnthn I'm not seeing any attributes one could easily remove from `Promise`; perhaps you could save 8 bytes by using a single field for vow taken and report-broken-if-sunk, if careful 17:24
[Coke] jnthn: oooh 17:26
Geth nqp: 3f99c1ba6e | (Jonathan Worthington)++ | tools/templates/MOAR_REVISION
Get MoarVM with async proc stdin close support
 17:31
17:34 sena_kun joined 17:36 Altai-man_ left
Geth rakudo: cdbd60c1c4 | (Jonathan Worthington)++ | 2 files
Fix handle leak when chaining Proc::Async

We request that the VM close the handle upon process termination.		 17:41
jnthn [Coke]: Hopefully this helps without breaking stuff :)
Passes spectest, at least :) 17:42
sena_kun jnthn, I'll check all release specs after $dayjob and launch blin tonight
lizmat jnthn: wondering if it would make sense to have a separate lock/unlock combo for Lock::Async.protect 17:43
jnthn
.oO( pancakes in orbit )
lizmat since in that case, the promises would never get out, so we wouldn't need vows on them
jnthn Don't think it'd help, given Promise.keep is just a method that does self.vow.keep anyway 17:45
In the uncontended case, you just get back the singleton Promise anyway. In the contended case, this is a drop in the ocean.
releasable6: status 17:48
releasable6 jnthn, Next release in ≈2 days and ≈1 hour. 1 blocker. 141 out of 247 commits logged
jnthn, Details: gist.github.com/d252e5542a58a0e1f7...297fb3302e
jnthn 1 blocker :D
Much better than the 4 earlier
lizmat yeah, and I think we could undo the BLOCKER there, since it may actually be in the module itself ? 17:49
jnthn Let's see what vrurg finds
We just need it removed (or fixed) before the weekend.
vrurg jnthn: Got a few minutes and got results. Writing a comment. 17:50
lizmat why does gist.github.com/Whateverable/d252e...297fb3302e mention commits from 2019 ? 17:51
hmmmm...
sena_kun lizmat, well 17:53
I can explain that
one second
vrurg jnthn: Done. The bisection looks correct and it's not about hashes, it's about the structure in Perl6::Grammar object passed to the action method.
vrurg is afk for a couple of hours.
sena_kun lizmat, they were dome in 2019 in a branch (e.g. github.com/rakudo/rakudo/pull/3286) and was merged around 22 days ago, so after 2020.01. thus these commits are from 2019, but they were not logged in a release, because they were not released. 17:54
s/dome/done/
lizmat hmmm...
sena_kun lizmat, no? this seems like the case to me.
lizmat will double-check
vrurg lizmat: I hoped it'd be a bug in the module, but still looks like a regression. :( 18:01
18:04 hungrydonkey left
jnthn vrurg: Did you replicate it being sensitive to whether hash randomization is disabled or not? 18:14
vrurg jnthn: no need for. Failure or success depended on which order of keys was returned from a hash. 18:15
The core of problem is that the rule must return a list of dependencies. But on HEAD it always return an empty list. 18:16
lizmat bisectable6: say so Match.^can("replace-with") 18:17
bisectable6 lizmat, Bisecting by output (old=2015.12 new=cdbd60c) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/76d986c22a23c9df4e...734aafc707
lizmat, There are 2 candidates for the first “new” revision. See the log for more details
vrurg I added dumps of the grammar obects as they're passed into the action method. HEAD returns incomplete list of submatches.
No I'm really away, a lot of urgent calls to place. :( 18:18
jnthn OK, thanks for the update
Umm...hmm 18:20
I wonder if it's going to be related to Rakudo/NQP match discrepancies... 18:21
18:26 domidumont joined, domidumont left
jnthn OK, I think what's wrong is this 18:27
18:28 domidumont joined
jnthn The creation of the Match structure is now done by an object attached to the regex code object 18:28
In the rakudo case it makes a Raku-level list/array thingy
In the NQP case it's an nqp::list 18:29
The cursor type when parsing Rakudo code is an NQP cursor
github.com/perl6/nqp/blob/master/s....nqp#L1149 fails (nqp::islist returns false) 18:30
This can only happen if you are trying to extend the Rakudo grammar from Raku code, which is certainly not something that is formally supported. 18:31
I've no idea how to fix it.
I don't see an easy way, at least. 18:32
Well, maybe we can have a way to ask for NQP lists instead 18:34
Quite a hack, but possible. 18:36
nine Isn't this quite similar to the issues in the MOP code?
jnthn Which issues? :) 18:37
nine Well, the mostly solved ones, but not completely, making code like this necessary: github.com/niner/Inline-Perl5/blob...W.pm6#L158 18:38
jnthn Kinda, though that one could be solved also through hllize mappings, I guess 18:39
lizmat nine: actually, that's also why there is a Rakudo::Internals::IterationSet
which is the nqp::hash equivalent of the IterationBuffer 18:40
if we would make IterationSet (or whatever the name is) a full HLL citizen, you could use that
jnthn Or at least, hllize doing raku -> nqp mapping too was originally intended, since for various cases it's just unwrapping the underlying storage
Anyway, enough for me today...maybe I can put in something for this tomorrow 18:41
lizmat fwiw, I think we need to reconsider the whole way NQP cursors / match object interact / interweave with HLL versions 18:42
we lose a *lot* of performance there
jnthn Well, ultimately I think we shouldn't build the list/hash at all in general 18:45
And just have AT-POS/AT-KEY pull the right thing(s) out of the Cursor 18:46
Since most of the time you only access things once anyway
lizmat yup, I was thinking that as well, possibly reblessing the object on the fly for caching
jnthn noooo
lizmat ok :-)
jnthn rebless = global deopt = very bad for performance
lizmat ok 18:47
jnthn It's bad enough QAST does it :)
Which we did to save memory, which it does I guess... :)
And it was done before we even had a specializer, to be fair
But these days it's probably a net loss
lizmat how about exposing the NQP cursor object? or are you saying that the NQP Cursor is the new HLL Match object ? 18:48
jnthn Cursor and Match were unified a while ago anyway
lizmat yes, but in many occasions you don't need the Match logic
jnthn But yeah, I think we can defer a lot of the work at least for Raku
For NQP it's all a bit harder because $<foo> is not a method call 18:49
lizmat github.com/rakudo/rakudo/blob/mast...r.pm6#L362 for instance
jnthn Yeah, that doesn't care for any captures etc. 18:50
Anyways, home time for me o/
lizmat safe travels!
vrurg Got a minute... jnthn, you say that extending Raku grammar from Raku is not formally supported. Does it mean than a couple of modules do something kind of illegal?
sena_kun is impudent enough to say that it is probably a borderline issue: if the user plays with how the code processing itself works, as a developer of the latter you cannot guarantee any possible thing will end up working nicely 18:54
[Coke] verified jnthn++'s fix fixes my original Raku/doc issue. Thanks! 18:55
vrurg sena_kun: that's clear. The question is wether it is allowed in general or prohibited as such? 19:23
In the latter case we better ask Damian to pull out his article on creating a slang. :) 19:25
19:33 Altai-man_ joined 19:36 sena_kun left
lizmat releasable6: status 19:38
releasable6 lizmat, Next release in ≈1 day and ≈23 hours. 1 blocker. 163 out of 247 commits logged
lizmat, Details: gist.github.com/0f8387f42c3e3cb9b0...9f145bbc5c
lizmat Altai-man_ do we have some automatic process moving the Merge commits to an ignorable lemma ? 19:39
or do we have to do that manually ?
Altai-man_ lizmat, I am doing it by hands and I'm ok with that (for now), is there something bad? 19:42
lizmat no, then I could do that now as well :-) 19:43
Altai-man_ lizmat, I'll prepare the release next Saturday giving no new issues, including complete changelog, announcement, etc. .oO ( was my 2020.01 changelog _so_ bad lizmat wants to do it instead now ) 19:44
lizmat nooo... I just want the life of a release manager easier
*make
if you'd rather have I didn't do, just say so :-)
Altai-man_ lizmat, you are doing some awesome work with compiler, so just leave it to me. And most of your commits are pleasure to document. :) 19:45
lizmat okidoki!
19:50 domidumont left
vrurg BTW, they accepted my tutorial for TPC 2020. 19:53
lizmat aahhh, that's good news!
in Houston ? right ? 19:54
vrurg lizmat: right. 20:08
lizmat cool vrurg+
+
vrurg is now looking for good tutorial for creating tutorials.
The last one I had was ~25yrs ago, it was a class of 10-13yo children... :) 20:09
Geth roast/6.d-errata: f846c15087 | (Elizabeth Mattijsen)++ (committed by Altai-man) | S06-signature/introspection.t
Fix test for unnamed named parameter in signature
 20:59
21:00 pmurias joined
jnthn vrurg: I think prohibited/illegal is too strong, it's more a case of: know you're using something that hasn't been declared a supported API, so have fun and make nice things, but if an internals change breaks it, the burden is primarily on you to fix it, not primarily on the Rakudo team as is the case for regressions when using spec'd stuff. 21:27
vrurg jnthn: reasonable. :) Though still would be nice if can pull the list of names somehow without re-parsing it. 21:28
jnthn vrurg: Yeah, I'll try and do a workaround tomorrow. Ultimately, we will need a proper/working way to do this. 21:29
vrurg jnthn: thanks! And I'll remove the blocker status as seemingly no other modules are affected anyway. 21:30
jnthn Yes, mercifully few people are so adventurous :)
vrurg In either case, I can workaround the problem by manually splitting the list since I can pull out the parsed part as a string.
jnthn Let's see if I can make an easy fix tomorrow
vrurg is away for lunch. It's damn crazy day today... 21:32
21:34 sena_kun joined 21:35 patrickb joined 21:36 Altai-man_ left 21:47 camelia left 22:19 MasterDuke joined 23:03 patrickb left 23:33 Altai-man_ joined 23:36 sena_kun left 23:38 lucasb 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!