🦋 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. |
|||
08:07
sena_kun joined
08:35
finanalyst joined
|
|||
finanalyst | .tell [Coke] please take another look at doc-website PR#363. Makes indexed=true default, and defaults are not written unless changed | 08:38 | |
tellable6 | finanalyst, I'll pass your message to [Coke] | ||
09:18
finanalyst left
|
|||
lizmat | github.com/Raku/problem-solving/issues/424 | 10:50 | |
nine | lizmat: LOL did I really just guess an actual module and that's even written by yourself? What are the odds? :) | 12:16 | |
lizmat | hehe | ||
nine | Btw. I'm not convinced that small reductions in bytecode size would be worth anything but minor changes. The most likely source of any performance improvement would be getting some routines below the inlining limit. But if that really helps so much we could as well just increase that limit by 5 %. | 12:58 | |
lizmat | github.com/Raku/problem-solving/issues/425 | ||
I think the current limit is there for a reason | |||
but perhaps we need to play with that as well to see what gives better performance | 12:59 | ||
nine | There's already a different max_inline_size for Raku (384) than the default of 192 (which still gets used for NQP). Both were determined empirically. | 13:01 | |
lizmat | % bceval c '.frames.grep({ 385 < .opcodes.elems < 400}).elems' | 13:19 | |
268 | |||
the C setting has 268 frames that are just above the threshold | |||
currently c setting has 18720 frames below the threshold | 13:20 | ||
% bceval c '.frames.grep({ .opcodes.elems <= 384}).elems' | |||
18720 | |||
all of this with a grain of salt, of course, as the bytecode from disk is really quickly altered by spesh in the runtime | 13:21 | ||
nine | Speshed bytecode can be a lot smaller than the original | 13:22 | |
That's the norm actually | |||
14:08
Altai-man joined
14:10
sena_kun left
16:25
finanalyst joined
|
|||
finanalyst | [Coke] I've implemented a reset button as requested for the search options. Its working on new-raku. Tests still in progress on doc-website | 17:51 | |
[Coke] tests passing | 18:11 | ||
Geth | rakudo/main: 4 commits pushed by (Stefan Seifert)++ | 18:43 | |
lizmat | 1058! | 19:01 | |
ab5tract | heck yeah :) | 19:12 | |
Geth | rakudo/main: d6dc3610ea | ab5tract++ (committed using GitHub Web editor) | src/core.c/Any.rakumod Supply an Any.match method candidate for Any:D (#5559) This addresses the use of non-`Str` candidates arriving in `where` constraints that attempt to match against a regex. (R#5464 / #5464). ``` ... (32 more lines) |
19:25 | |
linkable6 | R#5464 [open]: github.com/rakudo/rakudo/issues/5464 [dispatching] Invocant of method 'match' must be a type object of type 'Any' | ||
rakudo/main: 51b0ef2561 | (Elizabeth Mattijsen)++ | 2 files Final tweaks in Any.match fixes - The JVM backend isn't smart enough to make the an "empty" proto disappear, so it needs an extre level of nqp::getlexcaller. - Int.match(foo) would still fail: fixed by making the Cool.match method a multi ab5tract++ for perseverance! |
19:47 | ||
ab5tract | lizmat: shouldn't Int.match still fail though? | 19:55 | |
lizmat | it warns, that should be enough? | 19:56 | |
m: dd Int ~~ Cool | |||
camelia | Bool::True | ||
19:57
nativecallable6_ joined
19:58
reportable6 joined,
sourceable6_ joined,
notable6_ joined,
unicodable6_ joined,
coverable6_ joined,
linkable6_ joined,
bloatable6_ joined
|
|||
ab5tract | locally without your commit I get: `Invocant of method 'match' must be an object instance of type 'Cool', t a type object of type 'Int'. Did you forget a '.new'?` | 19:58 | |
19:59
tellable6_ joined
|
|||
ab5tract | that seems to match the expected behavior, no?\ | 19:59 | |
19:59
evalable6_ joined,
greppable6_ joined
|
|||
lizmat | no, that was actually incorrect | 19:59 | |
19:59
squashable6 joined,
releasable6_ joined
|
|||
lizmat | type objects stringify to the empty string with a warning | 19:59 | |
ab5tract | ie, the `Any:U:` candidate that calls `self.Str` | ||
19:59
statisfiable6 joined
|
|||
lizmat | m: say Int.Str | 19:59 | |
19:59
bisectable6_ joined
|
|||
camelia | Use of uninitialized value of type Int in string context. Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful. in block <unit> at <tmp> line 1 |
19:59 | |
20:00
shareable6_ joined
|
|||
lizmat | m: my $a = Int.Str; dd $a | 20:00 | |
camelia | Use of uninitialized value of type Int in string context. Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful. in block <unit> at <tmp> line 1 Mu $a = "" |
||
20:00
benchable6_ joined,
committable6_ joined,
quotable6_ joined
|
|||
ab5tract | ah, gotcha | 20:00 | |
thanks for the fix :) | 20:01 | ||
lizmat | hmmm on that thought.... | ||
m: say "" ~~ /^ $/ | 20:02 | ||
camelia | 「」 | ||
lizmat | so it looks like it should set the empty match if that is what was requested | ||
so we can actually simplify maters | 20:10 | ||
matters | |||
20:15
Altai-man left,
sena_kun joined
|
|||
Geth | rakudo/main: 881c1e87a7 | (Elizabeth Mattijsen)++ | 2 files Simplify the Any.match issue There shouldn't really be a difference between instantiated or uninstantiated Any matching. Both should first stringify and then call .match on the result. If a class doesn't handle strinngification of its type object, this will be handled by Any.Str, which will warn and produce the empty string (which *can* potentially match). Because this is now done by Any.match, Cool.match doesn't need to exist anymore as it will fall back to Any.match. |
20:18 | |
20:26
committable6_ left
20:29
committable6_ joined
20:41
sena_kun left,
sena_kun joined
21:02
sena_kun left
21:33
sena_kun joined
22:30
finanalyst left
23:06
sena_kun left
|