|
🦋 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: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm Set by lizmat on 8 June 2022. |
|||
|
00:00
reportable6 left
00:01
reportable6 joined
01:51
linkable6 left,
coverable6 left,
unicodable6 left,
releasable6 left,
shareable6 left,
evalable6 left,
sourceable6 left,
notable6 left
01:52
unicodable6 joined
01:53
notable6 joined,
shareable6 joined,
releasable6 joined,
coverable6 joined,
sourceable6 joined
01:54
linkable6 joined,
evalable6 joined
02:40
MasterDuke joined
|
|||
| Geth | rakudo: MasterDuke17++ created pull request #5352: Use new stat syscalls |
02:56 | |
|
03:21
squashable6 left,
squashable6 joined
04:48
squashable6 left,
coverable6 left,
benchable6 left,
shareable6 left,
nativecallable6 left,
reportable6 left,
releasable6 left,
notable6 left,
committable6 left,
evalable6 left,
sourceable6 left,
quotable6 left,
greppable6 left,
unicodable6 left,
linkable6 left,
statisfiable6 left,
tellable6 left,
bloatable6 left,
bisectable6 left,
tellable6 joined
04:49
statisfiable6 joined
04:50
unicodable6 joined,
committable6 joined,
nativecallable6 joined,
bisectable6 joined,
benchable6 joined,
greppable6 joined,
shareable6 joined,
linkable6 joined
04:51
notable6 joined,
releasable6 joined,
quotable6 joined,
bloatable6 joined,
squashable6 joined,
evalable6 joined,
reportable6 joined,
sourceable6 joined,
coverable6 joined
05:51
unicodable6 left,
bloatable6 left,
greppable6 left,
notable6 left,
releasable6 left,
nativecallable6 left,
statisfiable6 left,
squashable6 left,
reportable6 left,
bisectable6 left,
shareable6 left,
evalable6 left,
sourceable6 left,
tellable6 left,
committable6 left,
benchable6 left,
linkable6 left,
quotable6 left,
coverable6 left,
squashable6 joined
05:52
shareable6 joined,
releasable6 joined,
notable6 joined
05:53
linkable6 joined,
greppable6 joined,
quotable6 joined,
bloatable6 joined,
sourceable6 joined,
benchable6 joined,
committable6 joined
05:54
statisfiable6 joined,
reportable6 joined,
evalable6 joined,
tellable6 joined,
nativecallable6 joined,
unicodable6 joined,
bisectable6 joined,
coverable6 joined
06:00
reportable6 left
06:01
reportable6 joined
07:01
shareable6 left,
bisectable6 left,
squashable6 left,
evalable6 left,
statisfiable6 left,
coverable6 left,
benchable6 left,
unicodable6 left,
quotable6 left,
nativecallable6 left,
linkable6 left,
notable6 left,
sourceable6 left,
committable6 left,
bloatable6 left,
greppable6 left,
releasable6 left,
tellable6 left,
reportable6 left,
reportable6 joined,
tellable6 joined,
evalable6 joined,
sourceable6 joined,
shareable6 joined,
unicodable6 joined
07:02
committable6 joined,
statisfiable6 joined,
releasable6 joined,
notable6 joined
07:03
bloatable6 joined,
nativecallable6 joined,
coverable6 joined,
linkable6 joined,
bisectable6 joined,
squashable6 joined,
benchable6 joined,
greppable6 joined,
quotable6 joined
08:22
sena_kun joined
|
|||
| Geth | rakudo/main: 244ea5e9d6 | (Elizabeth Mattijsen)++ | 2 files RakuAST: add &*DD as an alias of dd() For *much* easier debugging of grammar and actions |
08:50 | |
| rakudo/main: 632f952b0a | (Elizabeth Mattijsen)++ | src/Raku/Actions.nqp RakuAST: Streamline lang-setup a bit And also introduce the RAKU_LANGUAGE_VERSION environment variable to set the language version to be used if no "use v6xxx" has been seen. Sadly this exposed a bug in language version setting: $*RAKU is set correctly with e.g. a "use v6.*", but the actual grammar being used, is still the default, aka the 6.d grammar. |
09:03 | ||
|
09:29
evalable6 left,
linkable6 left
09:30
evalable6 joined
09:31
linkable6 joined
09:46
NemokoschKiwi joined
|
|||
| Geth | rakudo/main: 88ca1e382c | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp RakuAST: Streamline check-variable Still not fully grokking what is going on with metaops though |
10:21 | |
| rakudo/main: e5d5d48eb1 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp RakuAST: Streamline obs handling And get rid of worryobs, as it is not being called anywhere |
|||
| rakudo/main: a17588f81b | (Elizabeth Mattijsen)++ | 2 files RakuAST: kebab-case typed_panic |
10:37 | ||
| rakudo/main: b20c79932f | (Elizabeth Mattijsen)++ | 2 files RakuAST: kekab-case typed_sorry |
10:46 | ||
| rakudo/main: 8a7f4b722d | (Elizabeth Mattijsen)++ | 2 files RakuAST: kebab-case typed_sorry |
10:57 | ||
| lizmat | meh, that was typed_worry | 11:11 | |
| TIL that: subst($orig, /foo/, "bar") is a thing in NQP | 11:35 | ||
|
12:00
reportable6 left
12:03
reportable6 joined
12:51
MasterDuke left
|
|||
| Geth | rakudo/main: 1d5a9508e7 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp RakuAST: Streamline build-exception and associated Still not grokking them completely :-( |
13:05 | |
|
13:13
finanalyst joined
|
|||
| lizmat | hmmm... feels like $*RESTRICTED is a leftover from the obsolete restricted setting? | 13:15 | |
| ah, I guess not: it's being set in src/core.c/INTERPOLATE | 13:16 | ||
| intriguing though there don't appear any tests for it ? | 13:17 | ||
| Geth | rakudo/main: 779f0f7992 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp RakuAST: remove "security" method It was only being called once, so move the logic there |
13:28 | |
|
13:29
sena_kun left
13:31
sena_kun joined
|
|||
| vrurg | lizmat: have you resolved the problem with `nano`? | 13:46 | |
| lizmat | nope | ||
| vrurg | Sorry, I was afk all day yesterday. | 13:47 | |
| lizmat | no worries | ||
| so, use v6.e.PREVIEW and v6.* set $*RAKU and such | |||
| but the grammar that's being used, is still 6.d | |||
| vrurg | The legacy grammar supports it by introducing explicit token term:sym<nano>, actually. That is how it works, I think. | ||
| `use v6e.*; say CORE-SETTING-REV;` shows no difference between the legacy and RakuAST. | 13:51 | ||
| lizmat | nano was just the canary... | 13:52 | |
| it isn't limited to nano | |||
| I don't think? | 13:53 | ||
| vrurg | There are more 'term' definitions in the legacy grammar, if memory doesn't betray me. | ||
| CORE-SETTING-REV is declared in the settings. If it is 'e' then there is no way CORE.e is not loaded. | 13:54 | ||
| Therefore the problem is not in a term not available – it's not seen. | 13:55 | ||
| lizmat | m: use v6.e.PREVIEW; say $*RAKU; say //42; | 14:00 | |
| camelia | Raku (6.e) True |
||
| lizmat | m: Q|use v6.e.PREVIEW; say $*RAKU; say //42|.AST | ||
| camelia | ===SORRY!=== Error while compiling Null regex not allowed. Please use .comb if you wanted to produce a sequence of characters from a string. ------> use v6.e.PREVIEW; say $*RAKU; say //⏏542 |
||
| lizmat | not just nano | ||
| m: use v6.*; snitch (1,2,3) | 14:01 | ||
| camelia | (1 2 3) | ||
| lizmat | m: Q|use v6.*; snitch (1,2,3)|.AST | 14:02 | |
| camelia | ( no output ) | ||
| vrurg | I'd rather suspect the lookup mechanism. | ||
| The CORE is definitely there, but lookups do not see symbols from it. | |||
| lizmat | ok, I'll look in that direction then... still feels weird | 14:03 | |
| vrurg | m: q<use v6.*; say &prefix:<//>.raku>.AST | 14:04 | |
| camelia | ( no output ) | ||
| vrurg | m: q<use v6.*; say &prefix:<//>.raku>.AST.EVAL | ||
| camelia | No such method 'raku' for invocant of type 'VMNull'. Found 'raku' on type 'Mu' in block <unit> at <tmp> line 1 |
||
| vrurg | m: EVAL q<use v6.*; say &prefix:<//>.raku>.AST | ||
| camelia | ===SORRY!=== Error while compiling <tmp> EVAL is a very dangerous function!!! (use the MONKEY-SEE-NO-EVAL pragma to override this error but only if you're VERY sure your data contains no injection attacks). at <tmp>:1 ------> L q<use… |
||
| vrurg | Anyway, plain lookup for the prefix OP works. The symbol _is_ visible. Then it's something about the resolver and/or how the grammar is using it. | 14:05 | |
| lizmat | ack | 14:06 | |
| vrurg | Which I could look into it personally. :( | 14:07 | |
| vrurg sadly crawls away to start integrating work app with google cloud... | |||
| lizmat | I wonder if $*R needs updating in lang-setup | 14:08 | |
| I'll try to see if that makes a difference | |||
| Geth | rakudo/main: 386cac8a12 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp RakuAST: streamline .NYI and .malformed |
14:19 | |
| lizmat | nope, that isn't it :-( | 14:33 | |
|
15:19
NemokoschKiwi left
|
|||
| vrurg | jdv: guess, you plan a release soon? | 15:30 | |
| lizmat | last thing jdv said was Monday | 15:31 | |
| vrurg | Ok. Just don't want to merge the PseudoStash thing before that. | 15:37 | |
|
15:44
finanalyst left
|
|||
| Geth | rakudo/main: 083f28579f | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp RakuAST: Streamline .missing handling And some more tweaks and fixes |
15:46 | |
| rakudo/main: 32e078ca75 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp RakuAST: Started on streamlining expressions |
17:05 | ||
|
18:00
reportable6 left
18:01
reportable6 joined
18:08
finanalyst joined
18:12
finanalyst left
20:26
MasterDuke joined
|
|||
| japhb | Is it just me, or is Rakudo starting up much slower than usual these days? | 21:01 | |
| $ time raku -e '' | |||
| real0m0.476s | |||
| user0m0.117s | |||
| sys0m0.024s | |||
| (That's from a fresh Rakudo build.) | |||
|
21:02
sena_kun left
|
|||
| japhb | In contrast, from back in February: | 21:05 | |
| $ time rakudo-moar-2023.02-0-g6c2f9194f/rakudo-m -e '' | |||
| real0m0.093s | |||
| user0m0.091s | |||
| sys0m0.017s | |||
| OK, confirmed faster start at rakudo-moar-2023.02-232-gef05ef1e2 and slower start at rakudo-moar-2023.05-7-g5be4c809f. I don't locally have any builds between those, looks like I'll have to build some more to bisect this. | 21:07 | ||
| ugexe | the startup times for me on 2023.02 and blead are identical for me | 21:08 | |
| same with 2023.06 | 21:09 | ||
| macos m2 | |||
| japhb | That's interesting. Do you happen to have an x64 machine about? I'm wondering if the jit got disabled, or some such arch-specific issue | 21:10 | |
| Meanwhile I'm building a 2023.04 to start the bisection fun | 21:11 | ||
| ugexe | i have a resource limited vm that is x64, it'll take a bit to build those two rakudos though | 21:14 | |
| japhb | Yeah, understood. Thank you for taking a look! | 21:18 | |
| vrurg | japhb: I compared 2023.02 and 2023.05 on Xeon E5-2690 v4 @ 2.60GHz. Makes no difference, 160-180ms for `raku -e ''` | 21:20 | |
| japhb | vrurg: What about 2023.06? | 21:31 | |
| The earliest in the 2023.05 series I had was -7- so something could have landed between the release and that point | |||
| vrurg | Didn't have it readily available, but was building. Gimme a sec to try. | ||
| japhb | Yeah of course. Thanks for helping to investigate! | 21:32 | |
| vrurg | The same, no difference. | ||
| japhb | WTH is going on? | ||
| ugexe | yeah, i see no difference on x64 too | ||
| japhb wonders if it was a compiler, linker, or C library change between the earlier builds I have on my system and the later ones. | 21:33 | ||
| vrurg | japhb: try freshly rebuild .02 and .06 using the same tools, perhaps? | ||
| japhb | Yeah, going to try that next, once .04 finishes. | 21:34 | |
| rakudo-moar-2023.04-0-g15df5d8a8 (built fresh) started at full speed. | 21:43 | ||
| rakudo-moar-2023.05-0-g297a1ec35 (built fresh) started SLOW. | 22:18 | ||
| vrurg in unpacking fresh popcorn... | 22:22 | ||
| japhb | Heh | 22:25 | |
| Tried moving .raku and .zef out of the way just in case that was related. Seems no. | 22:27 | ||
| Welp, continue bisecting I guess; trying 2023.04-103-gfac61c28e (first NQP bump after 2023.04) | 22:32 | ||
| Not that I'm actually assuming it's NQP, but it seemed like a reasonable way to rule that out at least. | 22:33 | ||
| rakudo-moar-2023.04-103-gfac61c28e (built fresh) started at full speed. | 23:02 | ||
| 2023.04-117-g401b77a8a (next NQP bump commit) next | 23:04 | ||
| rakudo-moar-2023.04-117-g401b77a8a (built fresh) started SLOW. | 23:37 | ||
| Guess I'll try -116- next, because if that is fast, then the NQP bump actually *is* the problem for me. | 23:38 | ||