|
08:45
sena_kun joined
12:08
librasteve_ left
|
|||
| lizmat | notable6: weekly | 12:29 | |
| notable6 | lizmat, 5 notes: gist.github.com/32e02500a372f22949...fa301204f2 | ||
| lizmat | notable6: weekly reset | 12:30 | |
| notable6 | lizmat, Moved existing notes to “weekly_2025-02-03T12:30:05Z” | ||
| lizmat | and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2025/02/03/2025-...ie-awaits/ | 12:31 | |
|
13:32
japhb left
|
|||
| Geth | rakudo/main: e6f0771a3c | (Elizabeth Mattijsen)++ | src/core.c/Map.rakumod Simplify Hash/Map.new The nqp::create(Hash/Map) automagically creates the $!storage hash attribute nowadays |
15:25 | |
| rakudo/main: ddf0734344 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/Map.rakumod Make Map|Hash.new( a => 42, b => 666) more DWIM Inspired by github.com/rakudo/rakudo/issues/3211 and the fact that I've run into this several times myself, and have had to explain why that didn't work. I think it's fine to make an exception for Map.new / Hash.new and all of its subclasses |
15:26 | ||
| roast: c2608389f8 | (Elizabeth Mattijsen)++ | 2 files Add tests for #3211 |
15:46 | ||
| rakudo/main: 9ece34b2b4 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/Hash/Object.rakumod Throw coercion failures on object hashes If an object hash is defined with a coercion type (e.g. Int(Str)) the Failure of the coercion would be stored as the key. Only to thrown whenever that key would be accessed in the hash, e.g. with .keys. ... (7 more lines) |
15:52 | ||
| [Coke] | Should that go a step further and not create a failure that can be stored but instead throw there? | 16:00 | |
| lizmat | possibly, but that gets into signature binding area... and that's something I'm still working up the courage to (re)-visit | 16:01 | |
| [Coke] | or, different question: do we have guidance on core items where failures are OK vs. exceptions? (and then cases like this where failures should immediately explode?) | ||
| lizmat | I don't think we have an official "guidance" on that | ||
| [Coke] | heh. looking at github.com/rakudo/rakudo/issues/3211 trying to figure out why there's a smiley face on the ticket (figured it out. :) | 16:02 | |
| OK - Figured this was a topic that we might have started out | |||
| er, as consistent, but is very easy to have situations where we throw vs. fail that might eventually want a review. | 16:03 | ||
| Maybe a topic for 6.f | |||
| 6.Fail 1 | |||
| lizmat | hehe | 16:05 | |
| sure :-) | |||
| Geth | roast: cabd39fd8f | (Elizabeth Mattijsen)++ | S09-hashes/objecthash.t Add test for #4301 |
16:09 | |
|
16:43
japhb joined
|
|||
| Geth | rakudo/main: e4157a41d8 | (Elizabeth Mattijsen)++ | 2 files Make Instant.DateTime timezone aware in 6.e By making it properly revision gated, ab5tract++ |
17:51 | |
| rakudo/main: 80c21053f6 | (Elizabeth Mattijsen)++ | 2 files Properly revision gate Date.DateTime The proto must have the trait applied as well |
18:16 | ||
| rakudo/main: 3b8e50942a | (Elizabeth Mattijsen)++ | src/core.e/Fixups.rakumod Make Int.uniname return Failure on unassigned in 6.e This effectively implements PR 5658, but for 6.e only. Sadly it turned out to be impossible to use true revision gating, as the almost all dispatch then turned in to ambiguous dispatches. So just implement a 6.e candidate, and make that the default. |
18:55 | ||
| timo | random idea dump: if we have a "scan" in a regex followed by an NFA invocation, could we reasonably run the NFA in scanning mode? instead of running the NFA over and over again after advancing one step each time for example? | 19:02 | |
| jdv | i feel like i've asked this before but is there info somewhere about @larrys ideas in optimizing the regex engine? | 19:04 | |
| timo | not sure | 19:11 | |
| i'm also feeling like from something like \d\d '-' \d\d '-' \d\d\d\d we could totally build a thing that can immediately go into the needle string search algorithm we are already using, just with a different generation for the lookup table | 19:12 | ||
| also maybe someone wants to highlight to these users that \d covers more than just 0..9, but also stuff in the higher unicode spheres | 19:19 | ||
| lizmat | m: dd 42.can("gist") | 22:29 | |
| camelia | (proto method gist (Mu $:: |) {*}, proto method gist (Mu $:: |) {*}) | ||
| lizmat | why two ? | ||
| m: dd 42.can("gist").map({.file ~ ": " ~ .line}) | |||
| camelia | ("SETTING::src/core.c/Mu.rakumod: 913", "SETTING::src/core.c/Mu.rakumod: 913").Seq | ||
| lizmat | they go back to the same? | ||
| m: dd 42.can("gist")>>.WHERE | 22:30 | ||
| camelia | (2426165487480, 2426165275064) | ||
| lizmat | but they are different? | ||
| bisectable6: old=2024.01 dd 42.can("gist") | |||
| bisectable6 | lizmat, Bisecting by output (old=2024.01 new=3b8e509) because on both starting points the exit code is 0 | ||
| lizmat, bisect log: gist.github.com/d3e6d958a5baac0a14...b7278b817a | 22:31 | ||
| lizmat, (2024-05-26) github.com/rakudo/rakudo/commit/f1...f24e30b94a | |||
| lizmat | that's... unexpected | ||
| ok, change in .raku output | 22:34 | ||
| bisectable6: old=2022.01 dd 42.can("gist").elems | 22:35 | ||
| bisectable6 | lizmat, Cannot find revision “2022.01” (did you mean “2025.01”?) | ||
| lizmat | bisectable6: old=2022.02 dd 42.can("gist").elems | ||
| bisectable6 | lizmat, On both starting points (old=2022.02 new=3b8e509) the exit code is 0 and the output is identical as well | ||
| lizmat, Output on both points: «2» | |||
| lizmat | bisectable6: old=2020.01 dd 42.can("gist").elems | ||
| bisectable6 | lizmat, On both starting points (old=2020.01 new=3b8e509) the exit code is 0 and the output is identical as well | ||
| lizmat, Output on both points: «2» | |||
| lizmat | weird | ||
|
23:51
sena_kun left
|
|||