00:33 HarmtH left 01:26 kvw_5 joined 01:29 kvw_5_ left 02:41 greppable6 left, quotable6 left, linkable6 left, committable6 left, evalable6 left, coverable6 left, shareable6 left, nativecallable6 left, bloatable6 left, squashable6 left, sourceable6 left, unicodable6 left 02:42 linkable6 joined, statisfiable6 joined, greppable6 joined, sourceable6 joined, evalable6 joined, nativecallable6 joined, unicodable6 joined 02:43 squashable6 joined, notable6 joined, shareable6 joined, bisectable6 joined, benchable6 joined 02:44 bloatable6 joined, quotable6 joined, tellable6 joined, committable6 joined, coverable6 joined 02:45 releasable6 joined
[Tux] Rakudo v2021.03-91-g496f986e6 (v6.d) on MoarVM 2021.03-18-ga64e1a432
csv-ip5xs0.797 - 0.826
csv-ip5xs-208.001 - 8.166
csv-parser26.429 - 26.976
csv-test-xs-200.372 - 0.387
test7.477 - 7.671
test-t1.920 - 1.928
test-t --race0.875 - 0.950
test-t-2032.558 - 34.415
test-t-20 --race9.508 - 9.949
 06:16
07:01 Xliff left 07:20 linkable6 left 07:21 linkable6 joined 07:49 squashable6 left 07:50 squashable6 joined 07:57 Kaiepi left 07:59 domidumont joined 08:01 squashable6 left 08:02 squashable6 joined 08:06 Kaiepi joined 08:52 linkable6 left 08:54 linkable6 joined 09:21 sena_kun joined 09:58 frost-lab joined 10:27 linkable6 left 10:28 linkable6 joined 10:37 linkable6 left, linkable6 joined
Geth rakudo: b88e1ca3bf | (Elizabeth Mattijsen)++ | src/core.c/unicodey.pm6
Hopefully fully unbreak JVM backend

usev6++ for guidance		 10:43
10:46 linkable6 left 10:47 linkable6 joined 11:11 linkable6 left 11:13 linkable6 joined 11:24 linkable6 left 11:26 linkable6 joined 11:31 linkable6 left 11:33 linkable6 joined 11:34 linkable6 left
tbrowder lizmat: any objections to merging my PR #4288? 11:35
11:35 linkable6 joined 11:36 linkable6 left 11:37 linkable6 joined
lizmat no, but I will add some optimization later 11:37
Geth rakudo: 6841ed5ecf | (Tom Browder)++ | src/core.c/DateTime.pm6
Add new methods to DateTime
rakudo: 457925e9b0 | (Tom Browder)++ | src/core.c/DateTime.pm6
changed method names per @ugexe's suggestion
rakudo: 353334fdb9 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/DateTime.pm6
Merge pull request #4288 from tbrowder/juliandate

Add new methods to class DateTime
tbrowder ok, can
lizmat and also make it take leap-seconds into account
tbrowder thnx
i'm interested in how that works. i thought the current object would have that included in its seconds 11:40
11:42 linkable6 left
Geth rakudo: usev6++ created pull request #4292:
Add test for repl handling junction correctly		 11:43
11:43 linkable6 joined
lizmat it would need to check the date 11:43
tbrowder but aren't they cumulative? 11:44
the new methods are on an instantiated object, so shouldn't the existing values be correct? 11:45
Geth roast/master: 4 commits pushed by (Tom Browder)++, (Elizabeth Mattijsen)++
tbrowder my roast tests run against NASA's time out to 4000 and agree to hundreds of a second 11:48
hundreths
hundredths :-) 11:49
that's using jpl's iso date, converting to jd, and comparing the two julian-dares 11:53
*dates
11:54 linkable6 left
Geth rakudo: 3926026213 | (Elizabeth Mattijsen)++ | src/core.c/DateTime.pm6
Optimize DateTime.day-fraction a bit
 11:54
11:57 linkable6 joined
tbrowder ok, i see what you did, but my tests also check nasa's day-fraction, so your's is a speed option, yes? 11:57
*speed optimization
"the squeaky day-fraction gets the nqp grease" 11:58
i'll try to remember that, thanks for never forgetting optimization! 12:01
lizmat yes, purely for speed 12:05
needed since people working with these usually had a *lot* of data points
12:06 linkable6 left 12:07 linkable6 joined
lizmat looking at making the leap second issue more efficient now 12:09
12:09 Kaiepi left 12:10 Kaiepi joined 12:17 brown121407 left 12:18 brown121407 joined
tbrowder ok, now i'm going to see if i can get posix as a real number AND satisfy roast...there be dragons, bye 12:26
12:45 domidumont left 12:47 linkable6 left 12:49 linkable6 joined 12:55 ggoebel left
bartolin_ lizmat: unfortunately, there is still a problem with Rakudo::Unicodey.ords after your latest commit. But I think I have a fix. Do you have some minutes to look at the last three commits in github.com/usev6/rakudo/commits/jvm_unicodey_2 ? 13:19
r: use nqp; my @foo; nqp::push(@foo, 42) 13:20
camelia This type (Array) does not support positional operations
in block <unit> at <tmp> line 1
java.lang.RuntimeException: This type does not support positional operations
in block <unit> at <tmp> line 1
bartolin_ r: use nqp; my @foo; push(@foo, 42); dd @foo
camelia Array @foo = [42]
Geth rakudo: c07639e64a | (Elizabeth Mattijsen)++ | src/core.c/Dateish.pm6
Make Datish.daycount calculation about 30% faster

  - don't need a separate local int $d as it's only mentioned once
  - initialize year and month first always, good for 10 months of the year
  - refer to each attribute only once, use (lowered) lexicals otherwise		 13:21
bartolin_ nqp::push and nqp::unshift don't seem to work with Rakudo's (non-native) arrays.
But I found out that the JVM backend does *not* have a problem with array[uint32].new in the setting -- while it has a problem with 'my uint32 @arr' 13:22
lizmat: could you explain to me if there are relevant differences between 'my uint32 @ords' and 'my @ords := array[uint32].new' in a place like github.com/rakudo/rakudo/blob/c076...dey.pm6#L9 13:25
lizmat aha! 13:26
bartolin_ I mean, do you see any problem with the latter (as in github.com/usev6/rakudo/commit/5fd7d068ed)?
lizmat I don't think there *should* be any difference?
bartolin_ Ha! That's good to hear ;) 13:27
lizmat ok, so yeah, a PR with that and the other #?if's reverted, would be welcome!
Geth rakudo: usev6++ created pull request #4293:
Jvm unicodey 2		 13:28
bartolin_ there you go
Geth rakudo/master: 4 commits pushed by (Christian Bartolomäus)++, (Elizabeth Mattijsen)++
bartolin_ I'll take a look if I can do something similar in one or two other places.
lizmat ++bartolin
afk for a few hours& 13:32
13:36 frost-lab left 13:37 b2gills left, b2gills joined 13:56 squashable6 left 13:57 squashable6 joined 13:58 HarmtH joined 14:15 domidumont joined 14:19 domidumont left
Geth nqp: f7896c5afb | (Stefan Seifert)++ | tools/templates/MOAR_REVISION
Bump MoarVM for new nqp::backtrace version
 14:32
rakudo/fix_backtrace_with_spesh_inlines: 2e79780e4a | (Stefan Seifert)++ | 4 files
Make backtraces consistent on all backends

Usually backtraces are created from exceptions. To catch such an exception the BackTrace constructer used a try thunk which at the VM level got its own call frame. However MoarVM's specializer may decide to inline this frame. While recent improvements to MoarVM made backtrace generation inline-aware, there still remains a problem when the inlined frame and the nqp::backtrace op are ... (9 more lines)		 14:38
rakudo: niner++ created pull request #4294:
Make backtraces consistent on all backends
rakudo/fix_tps_continuation_race_condition: 98839c8022 | (Stefan Seifert)++ | src/core.c/ThreadPoolScheduler.pm6
Fix race condition in ThreadPoolScheduler

t/spec/MISC/bug-coverage-stress-6.d.t died occasionally with "continuationinvoke expects an MVMContinuation" when run on a heavily loaded system. The reason for this is that a different thread may have taken the continuation job from the queue before the continuation was actually taken and stored in the variable.
... (9 more lines)		 15:01
rakudo: 98839c8022 | (Stefan Seifert)++ | src/core.c/ThreadPoolScheduler.pm6
Fix race condition in ThreadPoolScheduler

t/spec/MISC/bug-coverage-stress-6.d.t died occasionally with "continuationinvoke expects an MVMContinuation" when run on a heavily loaded system. The reason for this is that a different thread may have taken the continuation job from the queue before the continuation was actually taken and stored in the variable.
... (9 more lines)
16:52 evalable6 left, linkable6 left 16:54 evalable6 joined 16:55 linkable6 joined 17:09 domidumont joined 17:43 domidumont left
Geth rakudo: usev6++ created pull request #4295:
[JVM] Limit special cases to variable declaration		 18:26
rakudo: e774e19410 | (Christian Bartolomäus)++ | 4 files
[JVM] Limit special cases to variable declaration

We have a couple of workarounds for native arrays in the setting not working correctly on the JVM backend. Having something like
   my int @arr;
... (9 more lines)		 19:34
rakudo: b0de0ff087 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 4 files
Merge pull request #4295 from usev6/jvm_native_arrays

  [JVM] Limit special cases to variable declaration
bartolin_ thanks, lizmat 19:45
Geth roast: 9d22ba47ef | (Christian Bartolomäus)++ | S09-typed-arrays/native-num.t
[JVM] Unfudge now-passing tests

Fixed with github.com/rakudo/rakudo/commit/e774e19410
  (special case for JVM backend removed)		 20:07
rakudo: 2e79780e4a | (Stefan Seifert)++ | 4 files
Make backtraces consistent on all backends

Usually backtraces are created from exceptions. To catch such an exception the BackTrace constructer used a try thunk which at the VM level got its own call frame. However MoarVM's specializer may decide to inline this frame. While recent improvements to MoarVM made backtrace generation inline-aware, there still remains a problem when the inlined frame and the nqp::backtrace op are ... (9 more lines)		 20:17
rakudo: bebc82f38c | niner++ (committed using GitHub Web editor) | 4 files
Merge pull request #4294 from rakudo/fix_backtrace_with_spesh_inlines

Make backtraces consistent on all backends
roast: 3113a7def8 | (Christian Bartolomäus)++ | S15-unicode-information/uniname.t
[JVM] Unfudge now-passing tests for uniname(s)

Positive fallout from lizmat++'s recent work on Rakudo::Unicodey.		 20:32
vrurg nine: do I get it right that on moar nqp::backtrace(nqp::null) now does it without thrown an exception? 20:39
*throwing
nevermind, found the commit. Good... 20:50
nine yes 20:51
MasterDuke committable6: 2021.03,HEAD my $a; my $s = now; $a = do given "hi" { when 3 { "three" }; when 5 { "five" }; when "hi" { "hello" }; when * > 40 { "> 40" }; default { "default" } } for ^40_000; say now - $s; say $a 20:53
committable6 MasterDuke, ¦2021.03: «6.06434␤hello␤» ¦HEAD(bebc82f): «4.889722657␤hello␤»
MasterDuke nice 20:54
21:10 HarmtH left 21:46 grayrider joined
japhb MasterDuke: Any idea which of the commits is responsible for that? (I'm idly curious both what had such a large effect, and whether it will have any effect on [Tux]'s tests.) 22:34
MasterDuke japhb: it's nine++'s merge of his rakudo PR github.com/rakudo/rakudo/pull/4294 22:35
japhb Lighter backtraces make given/when faster? That's ... not self-obvious. 22:38
MasterDuke the cost is all the Failures created from the initial failed matches 22:39
a profile of the above code shows 50% of the time is spent in src/core.c/Backtrace.pm6:104 22:44
japhb Oh wild ... so what's that percentage now? 22:49
MasterDuke that's now 22:50
japhb !!!
I guess that makes it doubly important to have most likely matches at the front of a when ladder then. 22:54
MasterDuke yep 22:59
well, some things are more expensive to check than others. the fail is really coming from val(), trying to turn "hi" into a number 23:03
ugexe m: eager gather for 1..10 { (1..10).race.map({ take $_ }) } 23:20
camelia A worker in a parallel iteration (hyper or race) initiated here:
in code at <tmp> line 1
in block <unit> at <tmp> line 1

Died at:
take without gather
in block at <tmp> line 1

Powered by Cro and the Raku® Programming Language.

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

Thank you!