🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
00:02 reportable6 left 00:05 reportable6 joined 00:52 b2gills left 01:15 b2gills joined 02:44 bisectable6 left, sourceable6 left, coverable6 left, shareable6 left, quotable6 left, reportable6 left, committable6 left, greppable6 left, squashable6 left, evalable6 left, tellable6 left, linkable6 left, notable6 left, benchable6 left, nativecallable6 left, unicodable6 left, releasable6 left, statisfiable6 left, bloatable6 left, linkable6 joined, coverable6 joined, releasable6 joined, sourceable6 joined, benchable6 joined, tellable6 joined, committable6 joined, quotable6 joined, evalable6 joined, squashable6 joined 02:45 reportable6 joined, bloatable6 joined 02:46 bisectable6 joined, greppable6 joined, notable6 joined, unicodable6 joined 02:47 statisfiable6 joined, nativecallable6 joined, shareable6 joined 03:11 japhb joined 04:11 reportable6 left, coverable6 left, statisfiable6 left, notable6 left, committable6 left, unicodable6 left, sourceable6 left, greppable6 left, shareable6 left, tellable6 left, quotable6 left, nativecallable6 left, releasable6 left, bisectable6 left, linkable6 left, evalable6 left, benchable6 left, squashable6 left, bloatable6 left 04:12 benchable6 joined, sourceable6 joined, evalable6 joined, bloatable6 joined, statisfiable6 joined, releasable6 joined, linkable6 joined 04:13 greppable6 joined, nativecallable6 joined, notable6 joined, committable6 joined 04:14 shareable6 joined, coverable6 joined, reportable6 joined, squashable6 joined, unicodable6 joined 04:55 samebchase2 is now known as samebchase 05:19 squashable6 left 05:27 tellable6 joined 06:03 reportable6 left 06:05 reportable6 joined 06:18 bisectable6 joined 06:26 squashable6 joined 06:42 frost joined 07:32 patrickb joined 08:25 raydiak joined 10:47 morayj joined 11:17 RakuIRCLogger joined
lizmat m: dd "⩶".uninames 11:23
camelia ("THREE CONSECUTIVE EQUALS SIGNS",).Seq
lizmat m: dd "⩵".uninames
camelia ("TWO CONSECUTIVE EQUALS SIGNS",).Seq
11:43 morayj left, morayj_ joined 11:47 morayj_ is now known as morayj
Geth rakudo/equal-synonyms: b2ee9d29fd | (Elizabeth Mattijsen)++ | 9 files
Add ⩶ and ⩵ as unicode synonyms for === and ==

  - ⩶ aka U+2A76 THREE CONSECUTIVE EQUALS SIGNS
  - ⩵ aka U+2A75 TWO CONSECUTIVE EQUALS SIGNS
11:48
rakudo: lizmat++ created pull request #4392:
Add ⩶ and ⩵ as unicode synonyms for === and ==
11:49
11:51 morayj left, morayj joined
gfldex notable6: weekly: p6steve.wordpress.com/2021/06/04/414/ 12:01
notable6 gfldex, Noted! (weekly)
12:03 reportable6 left, reportable6 joined
lizmat weekly rag? :-) 12:18
leont Why am I not surprised unicode has a THREE CONSECUTIVE EQUALS SIGNS 12:31
lizmat well, *I* was :-) 12:34
leont They have every other mathematical symbol
lizmat well, I didn't realize I guess that === has a mathematical meaning as well 12:35
leont Apparently, they have 948 mathematical symbols: www.compart.com/en/unicode/category/Sm 12:36
Several we could support, not sure it's really worth it in most cases 12:41
lizmat less then but not equal to ? WTF ? 12:42
leont and «equal or less than» is separate from «less than or equal», for some reason 12:43
«Less-Than Equal to or Greater-Than» has me puzzled too 12:44
12:45 morayj left 13:01 quotable6 joined
lizmat m: say "a" ∼ "b" 13:04
camelia 5===SORRY!5=== Error while compiling <tmp>
Confused
at <tmp>:1
------> 3say "a"7⏏5 ∼ "b"
expecting any of:
infix
infix stopper
postfix
statement end
statement modifier
lizmat m: dd "∼".uninames
camelia ("TILDE OPERATOR",).Seq
lizmat feels like another candidate
leont They have a rightward arrow and a long rightwards arrow, which we could make mean -> and --> I suppose. But given that they're actual syntax and not operators that may be trickier. 13:08
lizmat actually, that also implies quite a few other ops as well: ~~ ~| ~< etc. 13:15
as well as prefix ~ and ~~ 13:16
going to leave that for now :-) 13:20
13:32 Kaiepi joined 14:30 squashable6 left
gfldex If we do add all those unicode operatos, I gonna get myself a new keyboard in the likes of pjmorgans.com/wp-content/uploads/2..._2_rev.jpg 14:57
lizmat :-) 15:00
15:16 frost left
nine Turns out, we kinda do have to generate both the jit-optimized and the non-jited native function body, as one can turn off JIT support at runtime with MVM_JIT_DISABLE=1 15:23
We could omit creating the jit-optimized body on platforms that don't have JIT support, but that's a comparitively rare usecase 15:24
patrickb It does apply to the new M1 Macs though. 15:40
nine Owners of such machines can implement JIT support or improve NativeCall's handling of that case 15:50
15:51 squashable6 joined
nine In a surprising plot twist, it turns out that neither the minutes of compilation time, nor the 16G of memory usage for those 3000 native subs are actually due to us compiling the function bodies. 15:52
Instead, for each of those subs we spend 0.022319779s in setup-nativecall, which doesn't actually do all that much 15:55
Ah, it's this line: compstuff[1]() unless nqp::isnull(compstuff);
Which runs this code: github.com/rakudo/rakudo/blob/mast....nqp#L2594 15:56
So we do spend the time in compilation. But in compilation of code that's never supposed to be run. 15:59
I wonder why this compilation of almost empty function bodies takes more time than the compilation of the function bodies that will be run 16:02
Ah, I know! And there's even a workaround 16:16
Got it down from 5 minutes to 1:44min and from 16G to 6G by placing every line of Glarkum.rakumod in its own block 16:17
ugexe protip: give every line of code its own lexical scope for performance 16:21
16:27 linkable6 left 16:29 linkable6 joined
nine In this case yes. Also when you have BEGIN blocks in huge lexical scopes 16:48
18:02 reportable6 left 18:03 reportable6 joined 19:04 rouking joined
rouking Is it possible for users to define metaoperators that have the same level of "niceness" as the builtin metaops like Z, X, R? I see some special-casing in src/Perl6/Grammar.nqp 19:50
I imagine the answer right now is no, so I'm wondering if that's on the table for future versions or if it would requite an inordinate amount of work 19:51
lizmat it will definitely not happen before the rakuast branch lands, I'd say 19:56
20:04 linkable6 left, evalable6 left 20:05 linkable6 joined 20:06 evalable6 joined 20:43 patrickb left
MasterDuke nine: i suspect you're much past this part in debugging, but a perf report of all the constants and 100 of the subs showed 14% of the time in MVM_sc_find_object_idx. here are some quick stats i gathered gist.github.com/MasterDuke17/041fd...28668ed681 21:11
lizmat hmmm.. no idea what that does exactly, but it feels it's going to proportionally longer for more serialization contexts... 21:16
Geth rakudo: 0de28ae72d | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/Any-iterable-methods.pm6
Make .grep(Regex) and .first(Regex) about 40% faster (#4383)

By not needing to create relative expensive .Match objects when only a Bool can do.
For historic reasons, Regex.ACCEPTS is *not* expected to return a Bool (contrary to all other .ACCEPTS methods) but a Match object. ... (10 more lines)
21:26
21:27 linkable6 left 21:29 linkable6 joined 21:35 squashable6 left 21:36 squashable6 joined