|
🦋 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. |
|||
| Xliff_ | For reference, I know this code worked as of March 24th of this year. | 00:13 | |
| [Coke] | bisectable6: my $a = "(b)"; my $b = $a.encode; $b.^name.say; use NativeCall; my $ca = CArray[uint8].new($b) | 01:34 | |
| bisectable6 | [Coke], Will bisect the whole range automagically because no endpoints were provided, hang tight | ||
| [Coke] | oh, this was already done in #raku | 01:35 | |
| bisectable6 | [Coke], Output on all releases: gist.github.com/e0b78471299540b643...dab8d7ec5c | ||
| [Coke], More than 3 changes to bisect, please try a narrower range like old=2024.04 new=HEAD | |||
| Geth | rakudo/rakuast-phase-cleanup: 25 commits pushed by (Stefan Seifert)++ review: github.com/rakudo/rakudo/compare/7...1f32c08d2d |
06:23 | |
|
06:33
_Guapo_ joined
06:40
_Guapo_ left
|
|||
| Geth | rakudo/rakuast-phase-cleanup: c5b634266d | (Stefan Seifert)++ | src/Raku/ast/variable-access.rakumod RakuAST: give dynamics a second chance at resolving There are two ways for finding dynamically scoped variables: if they are in the current scope, we have to access the lexical direclty. If they are not in the current scope, we have to use dynamic lookup. Thus we look up these variables only in the current scope. ... (9 more lines) |
07:12 | |
| lizmat | Xliff_: I probably borked that, please make an issue and assign me | 07:48 | |
|
08:00
sena_kun joined
|
|||
| Geth | rakudo/main: d0cbe4ae30 | (Elizabeth Mattijsen)++ | 2 files Unbreak CArray.new An optimization in 3861b8f8f27028426f27 inadvertently broke some use cases without being noticed. This unbreaks that by adding a fast path for Blobs and Lists, while retaining the original slow path for all other Positionals. Add test to make sure this doesn't happen again unnoticed. Spotted by Xliff++ |
08:25 | |
| lizmat | m: dd "(b)".encode.^roles # found this while investigating ^^ | 08:26 | |
| camelia | (Blob[uint8], UnsignedBlob[uint8], Positional[uint8], Stringy, UnsignedBlob[uint8]) | ||
| lizmat | note that UnsignedBlob[uint8] is occurring twice | 08:27 | |
| wonder what that is about | |||
| m: dd "(b)".encode.^roles.Set | 08:38 | ||
| camelia | Set.new(Blob[uint8],Positional[uint8],Stringy,UnsignedBlob[uint8]) | ||
| lizmat | so they *are* the same UnsignedBlob[uint8], not just by name, but also by WHICH | ||
| afk for quite a few hours& | 08:39 | ||
|
09:25
sena_kun left
|
|||
| Xliff_ | 'morn | 10:44 | |
| lizmat: Looks like your fix broke something else... | |||
| Can you please check the following gist: gist.github.com/Xliff/0fdb4edcca96...5b3c858b3a | 10:47 | ||
| Added a raku backtrace to it. | 10:49 | ||
|
11:56
liztormato joined
|
|||
| liztormato | Xliff_: am afk atm. Will look when back later today | 11:57 | |
| Xliff_ | liztormato: Understood. Thanks! | 11:59 | |
|
12:01
liztormato left
12:40
finanalyst joined
16:01
finanalyst left
|
|||
| Geth | rakudo/main: b36cceb36b | (Elizabeth Mattijsen)++ | lib/NativeCall/Types.rakumod Remove Blob fast path in CArray.new Apparently it causes segfaults |
16:56 | |
| lizmat | Xliff_: ^^ | 16:57 | |
| Xliff_ | lizmat: Has camelia been updated? | 17:15 | |
| lizmat: New error - "==SORRY!=== Error while compiling /home/cbwood/Projects/p6-GLib/lib/GLib/Raw/Definitions.pm6 (GLib::Raw::Definitions) New type Block for List is not a mixin type at /home/cbwood/Projects/p6-GLib/lib/GLib/Raw/Definitions.pm6 (GLib::Raw::Definitions):9" | 17:18 | ||
| [Coke] | m: say 3 | 17:46 | |
| camelia | 3 | ||
| [Coke] | Note the commit ID in the response | 17:47 | |
| Geth | rakudo/main: b6028f9da6 | (Elizabeth Mattijsen)++ | lib/NativeCall/Types.rakumod Remove List fast path in CArray.new as well |
18:41 | |
| lizmat | Xliff_: ^^ | ||
| nine | lizmat: isn't there still an off-by-one error in there? | 19:53 | |
| Ah, no --$n | |||
| Xliff_ | lizmat: Same error. You can check yourself. | 20:44 | |
| Pull down github.com/Xliff/p6-GLib | |||
| 1) Make change; 2) cd into p6-GLib; 3) raku -Ilib -e 'use GLib::Raw::Definitions' | |||
| The advantage here: It gives you a chance to look at GLib::Raw::Definitions to see what the root issue is, and if it can be solved by changing that compunit. I will be doing the same, here. | 20:45 | ||
| Looks like the problem is triggered by GLib::Raw::Distro | 20:48 | ||
| Found the problem. Recompiled it. Problem went away. | 20:53 | ||
| Now went back to the original version of the code and problem did NOT return. Weird. | |||
| Problem found again in GLib::Object::Supplyish | 20:54 | ||
| Commented out the entire compunit. | 20:55 | ||
| Recompiled it. Fine. | |||
| Uncommented. Recompiled. Fine | |||
| Same with GLib::Roles::Protection | 20:57 | ||
| So I can't confirm what the problem is, but I have found a workaround. | 20:58 | ||
|
20:58
sena_kun joined
22:23
sena_kun left
22:51
Xliff_ left
23:26
MasterDuke joined
|
|||