01:04 leont left 01:45 vrurg joined 02:17 lucasb left 02:38 lizmat left 02:39 lizmat joined 02:51 Kaiepi joined 03:19 vrurg left 03:27 vrurg joined 04:21 vrurg_ joined 04:22 vrurg left 04:30 guifa joined
guifa Talking with jdv79 on #raku has brought me to an interesting observation. DateTime accepts seconds as an Real value, so it handles fractional seconds without any real (ha) problem. The most common way of getting this, though, is by using an Instant, which stores its values as a Rat. This is odd, since the fractional time is consistantly a float from MoarVM into NQP into Rakudo::Internal, only changed into a Rat to be stored in 04:34
Instant’s private attribute.
Any thoughts on simply changing Instant to use a Num? It’d save us a Num—>Rat conversion, and preserve the precision of the value returned. As it stands in documentation, Instant doesn’t promise a Rat representation and Roast doesn’t really seem to be concerned with the type when retrieved via the various methods that access it 04:46
06:41 Xliff joined 06:50 domidumont joined 07:09 Altai-man joined 08:22 Xliff left 09:43 sena_kun joined 09:44 Altai-man left 12:40 MasterDuke left
jdv79 guifa: uh, that would make the math situ even worse. Rat is better. 13:05
[Tux] Rakudo version 2020.09-39-ge0e24a8db - MoarVM version 2020.09-10-g8d7a80d55
csv-ip5xs0.805 - 0.824
csv-ip5xs-208.038 - 8.105
csv-parser25.723 - 26.289
csv-test-xs-200.389 - 0.392
test7.569 - 7.709
test-t1.895 - 2.043
test-t --race0.855 - 0.879
test-t-2032.544 - 32.725
test-t-20 --race9.296 - 9.885
 13:11
lizmat guifa: TimToady had specific ideas about that: 13:12
C<Instant>s and C<Duration>s are measured in atomic seconds with fractions.
Notionally they are real numbers which may be implemented in any C<Real>
type of sufficient precision, preferably a C<Rat> or C<FatRat>.
(Implementations that make fixed-point assumptions about the available
subsecond precision are discouraged; the user interface must act like real
numbers in any case.)
from: design.raku.org/S02.html#Immutable_types 13:14
Geth_ rakudo: 338c7439d2 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 6 files
Fix for issue with Z / X with set operators (#3950)

  * Let the multi-fallback handle Any case as well
A good night of sleep revealed the solution: using the +@p signature instead of the **@p signature on the fallback, should fix the issue found with Z and X using set operators that don't return a Bool. ... (5 more lines)		 13:17
linkable6 RAKUDO#3950 [closed]: github.com/rakudo/rakudo/pull/3950 Fix for issue with Z / X with set operators
roast: 7290218201 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 6 files
Add tests for R#3945 (#682)

Add tests for R#3945		 13:18
linkable6 R#3945 [open]: github.com/rakudo/rakudo/issues/3945 Intersection meta-ops behave like union
ROAST#682 [closed]: github.com/Raku/roast/pull/682 Add tests for R#3945
13:21 leont joined 13:42 Altai-man joined 13:44 sena_kun left
Geth_ rakudo: 4af961ed33 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Perl6/Actions.nqp
Add sanity check in infix handling, fixes R#3949 (#3951)

Before this, an "infix:(&)" (note the missing < > there) would cause a:
   $ raku -e 'infix:(&)'
   This type (QAST::WVal) does not support positional operations
... (8 more lines)		 13:55
linkable6 R#3949 [open]: github.com/rakudo/rakudo/issues/3949 [LTA] [LTA] error message with incorrectly spelled infix operator
RAKUDO#3951 [closed]: github.com/rakudo/rakudo/pull/3951 Add sanity check in infix handling, fixes R#3949
roast: 3f83432344 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | S32-exceptions/misc.t
Add tests for R#3949 (#683)
linkable6 ROAST#683 [closed]: github.com/Raku/roast/pull/683 Add tests for R#3949
Geth_ rakudo: d0854ffcc5 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Perl6/Actions.nqp
Make "is rw" on parameters of MAIN worry (#3947)

As noted in R#3929 by Zoffix++		 13:57
linkable6 RAKUDO#3947 [closed]: github.com/rakudo/rakudo/pull/3947 Make "is rw" on parameters of MAIN worry
R#3929 [open]: github.com/rakudo/rakudo/issues/3929 [LTA] Mistaken use of `is rw` on `sub MAIN` Produces Usage Instead of Error/Warning
Geth_ roast: bc7d44e050 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | S06-other/main.t
Add tests for fix of R#3929 (#681)
linkable6 ROAST#681 [closed]: github.com/Raku/roast/pull/681 Add tests for fix of R#3929
14:13 Xliff joined
Xliff \o 14:13
nwc10 o/ 14:28
Xliff What does this error imply: "Can only store CPointer attribute in CPointer slot in CStruct" 14:29
It seems to stem from the bind, here: github.com/Xliff/p6-GIO/blob/septe...ts.pm6#L37 14:32
Problem is illustrated here: repl.it/@Xliff/MellowMutedCrash#main.raku 14:45
m: my $a; sub aa { ^2.pick ?? 2 !! 4 }; $a := aa; 14:51
camelia Potential difficulties:
Precedence of ^ is looser than method call; please parenthesize
at <tmp>:1
------> 3my $a; sub aa { ^27⏏5.pick ?? 2 !! 4 }; $a := aa;
Xliff m: my $a; sub aa { (^2).pick ?? 2 !! 4 }; $a := aa;
camelia ( no output )
Xliff m: my $a; sub aa { (^2).pick ?? 2 !! 4 }; $a := aa(); $a.say 14:52
camelia 4
Xliff m: my $a; sub aa { (^2).pick ?? 2 !! 4 }; $a := aa(); $a.say
camelia 4
Xliff m: my $a; sub aa { (^2).pick ?? 2 !! 4 }; $a := aa(); $a.say
camelia 2
Xliff Yeah, this doesn't make any sense... 14:55
repl.it/@Xliff/MellowMutedCrash#main.raku
The difference between it working and it not working is that the LHS is an attribute 14:56
15:30 domidumont left 16:12 [TuxCM] joined 16:25 [Tux] left 16:26 [Tux] joined 17:36 lichtkind joined 17:42 sena_kun joined 17:44 Altai-man left 19:13 MasterDuke joined
Geth_ rakudo/nqpif2ternary: 15cd58c120 | (Elizabeth Mattijsen)++ | 58 files
Replace all simple nqp::if(42,foo,bar) with ternaries

If memory serves me well, about 1.5 years ago, optimizations in Rakudo made the construct:
   42 ?? foo !! bar
... (12 more lines)		 19:14
rakudo: lizmat++ created pull request #3957:
Replace all simple nqp::if(42,foo,bar) with ternaries		 19:15
lizmat that was an interesting excercise 19:19
or rather exercise :-) 19:20
nine so...did you benchmark this? 19:22
lizmat yes... at least in a small piece of code 19:25
tonight I'll run my spectest bench on it, and we'll see if that makes a difference 19:26
m: use nqp; my $a = 42; for ^10000000 { my $b = nqp::if($a,42,666) }; say now - INIT now 19:27
camelia 0.4398375
lizmat m: use nqp; my $a = 42; for ^10000000 { my $b = nqp::if($a,42,666) }; say now - INIT now
camelia 0.4652576
lizmat m: use nqp; my $a = 42; for ^10000000 { my $b = nqp::if($a,42,666) }; say now - INIT now
camelia 0.4549415
lizmat m: my $a = 42; for ^10000000 { my $b = $a ?? 42 !! 666 }; say now - INIT now
camelia 0.4784214
lizmat m: my $a = 42; for ^10000000 { my $b = $a ?? 42 !! 666 }; say now - INIT now 19:28
camelia 0.43757528
lizmat m: my $a = 42; for ^10000000 { my $b = $a ?? 42 !! 666 }; say now - INIT now
camelia 0.4323779
lizmat m: my $a = 42; for ^10000000 { my $b = $a ?? 42 !! 666 }; say now - INIT now
camelia 0.4495505
lizmat with 10M iterations, there's bound to be noise
MasterDuke cachegrind might show something useful. also MVM_SPESH_BLOCKING and MVM_SPESH_NODELAY 19:36
locally i don't really see any difference between those two 19:37
lizmat this was about delivering in my promise made many years ago that when high level constructs would allow for the same performance, I would change code back to using those hll conctructs 19:39
MasterDuke lizmat++
lizmat *on my promise
MasterDuke cachegrind with MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1 shows them pretty similar 19:42
lizmat mind you, I didn't generally touch nqp::if's inside of other nqp:: structures
but those would require more brainpower to actually do
and thus would take a lot longer to do 19:49
[Coke] seems like the sort of work that someone could chip in on in that branch, no? just needs to be spectest clean, right? 20:00
lizmat well... also in the same ballpark of performance
so the nqp::while/nqp::until structures should definitely *not* be touched 20:01
[Coke] fair enough. If you need help with braindead swaps, that is definitely in my wheelhouse. thinking probably not so much. :) 20:03
20:03 MasterDuke left
lizmat this PR is more a proof of concept, and we should see how tonight's spectest comes out (on my machine) 20:04
when it runs, it runs around 6am in the morning, when it has been asleep for a few hours and so should have fewer throttling issues 20:05
20:13 sena_kun left 20:15 MasterDuke joined
timotimo i would perhaps compare --output=optimize between ??!! and nqp::if 20:19
lizmat as rakuast has a Ternary class, it should allow for higher level optimization logic as wel 20:22
hmm... interesting test output from is-deeply: 20:25
# expected: $(("a", "b", "c"), Bool::True)
# got: $(("a", "b", "c"), Bool::True)
[Coke] O_o; 20:39
lizmat m: my %h = a => 42; dd %h<a>:kv[1] # sorta expected 42 here, wonder why the [1] is silently being ignored
camelia ("a", 42)
lizmat m: my %h = a => 42; dd (%h<a>:kv)[1] # extra parens gives the correct result 20:40
camelia Int %h = 42
lizmat [Coke]: turned out one was an IterationBuffer, and the other one was a List 20:45
[Coke] +1 20:57
20:58 squashable6 left 20:59 squashable6 joined
Geth_ rakudo: d08247db4a | (Elizabeth Mattijsen)++ | src/core.e/hash_slice.pm6
Fixes for tests that failed for %h{a;b;c}:adverbs
 21:17
rakudo: 33bb6504d1 | (Elizabeth Mattijsen)++ | 2 files
Make IterationBuffer.raku different

It was just rakuing as a List, but that creates some very confusing is-deeply output when comparing the same values from a List and an IterationBuffer.
Telemetry needed to be adapted because it depended on the previous behaviour.
Please note that IterationBuffer.raku is a debugging tool: it does
  *not* roundtrip, nor is it the intent that it ever will.
roast: 1d95056189 | (Elizabeth Mattijsen)++ | S32-hash/multislice-6e.t
Add some %h{a;b;c}:delete tests

Not all of the passing yet		 22:04
lizmat and that concludes my hacking for today&
22:05 lichtkind left 22:08 dogbert17 left, dogbert17 joined 23:25 squashable6 left 23:27 squashable6 joined 23:50 MasterDuke left 23:51 leont 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!