timotimo cool library 00:13
Geth rakudo: fa355a26d2 | (Elizabeth Mattijsen)++ | lib/BUILDPLAN.rakumod
Add support for the new 13/14 object build opcodes

13 = same as 0, but bind instead of assign 14 = same as 4, but bind instead of assign
Note that native attributes were already being bound, rather than assigned, so we don't need extra object build opcodes for that.
00:23
rakudo: 19b820d8fe | (Elizabeth Mattijsen)++ | src/core.c/Mu.pm6
BUILDPAN build opcode 13/14 (runtime version)

This implements BUILDPLAN opcodes 13/14, to *bind* to atributes rather than assign to them.
13: same as 0, but bind instead of assign 14: same as 4, but bind instead of assign
00:28
lizmat argh s/BUILDPAN/BUILDPLAN/
the compile-time portion should be done tomorrow 00:34
for now, some sleep& 00:35
Geth nqp: 57a65f0a1b | (Daniel Green)++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java
Java's BigInteger.modPow can take exponents < 0
01:38
AlexDaniel Dynamic variable %*COMPILING not found 01:52
huh?
travis-ci NQP build passed. Daniel Green 'Java's BigInteger.modPow can take exponents < 0' 01:54
travis-ci.org/perl6/nqp/builds/638991031 github.com/perl6/nqp/compare/c7f4d...a65f0a1b72
AlexDaniel that's something in HTTP::UserAgent 01:56
does it sound familiar? I'm not sure I'm very interested in figuring this out right now
dumarchie Should List.new-from-iterator be documented (and covered by a spectest) or should it be hidden? 09:09
lizmat Files=1301, Tests=109805, 210 wallclock secs (28.17 usr 8.05 sys + 2939.19 cusr 267.98 csys = 3243.39 CPU) 10:29
seems like yesterday's bump was a fluke
nine releasable6: status 10:56
releasable6 nine, Next release will happen when it's ready. 1 blocker. 0 out of 499 commits logged
nine, Details: gist.github.com/99470faf1adc321797...18004b6d0b
nine I thought overload::constant and ADT were fixed by a revert on the release branch? 10:58
sena_kun nine: yes, I am now running blin for the latest cut. `1382 out of 1384 modules processed (left: PDF::API6 IRC::Client::Plugin::Github)`, if there are no regressions, it's a green light for the moarvm release. 11:01
nine Err....we already got a MoarVM release :) 11:03
sena_kun nine: yes, but it was made kind of prematurely and now one has to sync in terms of tags, bumps and so on. 11:04
sena_kun will look at the release soon
nine There's been just 1 bugfix and a couple of warning fixes (which are not associated with any known actual bugs) since the 2020.01 MoarVM release 11:06
sena_kun nine: but this 1 bugfix fixes severe segfault for cro::websockets, no?
nine It does fix a segfault, yes. Though I can't seem to remember where exactly it showed up 11:08
sena_kun in cro::websocket tests. and if simple tests are failing, showing up in a production environment is likely and we don't want that 11:09
nine Ah, now I remember! The segfault occured only on a somewhat older libopenssl version 11:14
And I upgraded to a newer libopenssl on our production VMs which is why we don't encounter that issue anymore.
FWIW we haven't had a rakudo segfault on our production machines in weeks :) 11:16
So yes, a point release of MoarVM would be nice indeed. But rakudo need not depend on that point release. 11:18
sena_kun has finally finished with the morning routine and can look at blin results 11:24
Geth rakudo: ecf8a3f4ce | (Elizabeth Mattijsen)++ | 2 files
Add support for Attribute is built(:bind)

  - add "is_bound" attribute handling to Attribute in bootstrap
  - add support for ":bind" to "is built" trait
11:51
rakudo: 7bbb76da19 | (Elizabeth Mattijsen)++ | src/Perl6/World.nqp
Support for binding attributes in BUILDPLAN processing

This adds support for binding attributes (with "is built(:bind)", opcodes 13 and 14)) to the object build logic compiler services.
12:18
rakudo: Altai-man assigned to vrurg Issue Regression related to AUTOGEN signature github.com/rakudo/rakudo/issues/3433
8ab53027e2 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/BUILDPLAN.nqp

If an attribute is marked as "is_bound", then adapt the opcodes 0 and 4 to 13 and 14 respectively. It really was as simple as that.
12:31
sena_kun and we have one more regression to look into
Geth rakudo: 3f0dca4f4d | (Elizabeth Mattijsen)++ | lib/BUILDPLAN.rakumod
Fix stray i in method name
12:58
rakudo: taboege++ created pull request #3434:
NativeCall: add CArray[…].new(Str:D, …) candidate
13:04
Kaiepi a while ago i was working on making feed operators compliant with their original design, but stopped since the implementation i ended up with was slower than what we have now
i have some ideas on how to speed this up now 13:05
lizmat ++Kaiepi
tobs thanks lizmat, you're fast :) 13:06
lizmat hehe
tobs: I actually approved it before I saw your request for review :-) 13:08
tobs can't get any faster
Geth rakudo: d1cda8460d | (Elizabeth Mattijsen)++ | src/core.c/Attribute.pm6
An accessor on a bound attribute should not decont

As there is no container anyway in that case, so just simply return the attribute.
13:24
jnthn lizmat: I'm not sure I agree with that; why would there be "no container"? In `class A { has $.foo is init(:bind) }; my $foo = 42; A.new(:$foo)`, $!foo =:= $foo 14:03
jnthn class A { has $.foo is rw is init(:bind) }; my $foo = 41; A.new(:$foo).foo++; say $foo # I'd expect 42 14:04
And without the `is rw` I'd expect an error 14:05
And I don't see how we get that if such an accessor doesn't decont
lizmat jnthn: you use "is init" did you mean that, or did you mean "is built" ? 14:19
jnthn: also, without the "is rw", shouldn't that just decont on object creation ? 14:21
so we'd lose any container then, so we don't have to decont every attribute access ? 14:22
afk for a few hours&
nine lizmat: but then we lose the ability to bind a container on purpose (however bad such a thing may sound). If there's no container then MoarVM will optimize the decont away 14:27
jnthn lizmat: Meant "is built" 14:29
lizmat: Under *normal* object creation semantics, we assign into an attribute; :bind is meant to bind. 14:30
lizmat: There's no automatic decont anywhere except in a non-rw accessor
Well, also in that if you have `has @!foo is built(:bind)` and you pass `foo => $[foo]` then per normal binding semantics we lose the Scalar. But that just falls out of normal := semantics. 14:31
dumarchie Does anybody have an opinion on whether List.new-from-iterator should be documented and covered by a spectest or should be hidden? 17:01
Documenting it creates one more opportunity for new users to find out how to create a lazy list. 17:07
MasterDuke lizmat: istr you had a comment on a commit from the past couple weeks about wanting a fast Int.chars? i can't find it, so maybe i'm imagining things 17:15
ab5tract regarding that recent commit to doc which discussed managed char* ... thanks for that one!! it got the flaps right out of my library tests. it was clear that the flaps were due to memory management timings but it was quite unclear how i should go about addressing it. 18:16
tobs hah, amazing how a random doc change can come at just the right time 19:43
Geth rakudo: bd4b2c1487 | (Elizabeth Mattijsen)++ | src/core.c/Attribute.pm6
Revert "An accessor on a bound attribute should not decont"

This reverts commit d1cda8460d2199c6605871ecd4e3c3fb6e29863d.
19:53
lizmat m: class A { has $.a = 42 }; A.new for ^10_000_000; say now - INIT now 19:57
camelia 1.8076504
lizmat m: class A { has $.a is built(:bind) = 42 }; A.new for ^10_000_000; say now - INIT now
camelia 1.3209165
lizmat m: say 1.8076504 / 1.3209165
camelia 1.368481959
lizmat morale: make your objects with immutable attributes go 1.3x as fast with "is built(:bind)" 19:58
MasterDuke dumarchie: i don't have an informed opinion on whether it should be hidden (i'd lean towards no absent any other information), but if not, then yes it should be spectested and written up in the docs 20:50
tellable6 MasterDuke, I'll pass your message to dumarchie
lizmat .tell dumarchie I'd rather see .List and .Array coercers implemented in the Iterator role 23:02
tellable6 lizmat, I'll pass your message to dumarchie