🦋 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
|