|
🦋 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. |
|||
| leont | If it doesn't auto-close, most applications will leak like a sieve I suspect. | 00:58 | |
| ugexe | i agree, but doesn't that say more about the developer? | 01:39 | |
| i guess not, coming from perl. but coming from a language like go it just seems sloppy | 01:41 | ||
| leont | It's all about managing expectations, really | 01:42 | |
| ugexe | for all my time in raku, i didn't even remember that we auto closed handles | ||
| i expected the opposite based on how other handles get treated | |||
| leont | RAII is the sensible to deal with this sort of thing IMNSHO. If they aren't autoclosed, we should provide something like using in C# | 01:43 | |
| coleman | What happens in Go to an *os.File that is simply garbage collected and not explicitly closed? | ||
| ugexe | yeah thats why i think a warning might be ideal. if we had DEFER then its even easier to guide developers to the solution | ||
| leont | defer still feels sub-optimal because it takes a second action to get things right | 01:44 | |
| That makes it too easy to forget about it | 01:45 | ||
| coleman | RAII feels like the more "OOP" type solution | ||
| ugexe | true, but you're also using a handle and not any of the convience methods you'd probably already want to be using if you don't want to explicitly close a handle | ||
| it also encourages coding patterns that may not work as expected on windows | 01:46 | ||
| maybe i just don't like the current implementation. or that its apparently so difficult to disable it | 01:50 | ||
|
04:30
kjp left
04:33
kjp joined
04:36
epony left
09:32
epony joined
09:47
sena_kun joined
10:31
finanalyst joined
|
|||
| lizmat | ugexe: oops, good catch! | 10:45 | |
| a723c387ce | 10:46 | ||
| linkable6 | (2024-02-10) github.com/rakudo/rakudo/commit/a723c387ce Fix removal of file locking during installation | ||
|
11:52
epony left
11:53
finanalyst left
12:35
epony joined
12:42
epony left
13:05
epony joined
13:29
epony left
14:02
epony joined
|
|||
| Geth | rakudo/main: 6117df24a8 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/C3MRO.nqp Streamline the C3MRO metamodel role - replace for loops by while loops, as they are 35% faster - a bit more documentation |
14:27 | |
| rakudo/main: e93208ce71 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/C3MRO.nqp Remove read lock on MRO Also replace %!mro by $!mro, as this will be atomically initialized with an NQPMu, which is easier to check for when inspecting at a time when the $!mro hasn't been initialized yet. This appears to save 5 wallclock seconds on spectest and significant less CPU usage. This also drops bare startup from .12 to .11 for yours truly. |
16:47 | ||
| ugexe | I added a warning to IO::Handle::DESTROY and reinstalled rakudo - there doesn't seem to be any other file handle leaks using that code path. but it made me think it might be nice to have an environment variable that could be set to see when handles are closed that way | 16:48 | |
| that was as a developer i could test my apps when that environment variable enabled and see if there any handles i forgot to close explicitly | 16:49 | ||
| that way^ | |||
| lizmat | +1 | ||
| ugexe | what would we call such an environment variable? RAKUDO_WARN_UNCLOSED_IO_HANDLE or some such | 16:52 | |
| lizmat | RAKUDO_WARN_UNCLOSED_IO_HANDLES ? | 16:53 | |
| RAKUDO_WARN_OPEN_IO_HANDLE | |||
| S | 16:54 | ||
| jdv | why could that not just be a warning cat? | 17:35 | |
| ugexe | there is also IO::CatHandle::DESTROY... | 17:37 | |
|
17:41
timo left
20:28
timo joined
|
|||
| timo | i just stumbled upon div not being coercive for its arguments, then i saw that literally just got fixed last week. MasterDuke17++ | 20:29 | |
|
22:14
MasterDuke joined
|
|||
| MasterDuke | m: use nqp; say(nqp::objprimunsigned(num)); say(nqp::objprimunsigned(int)); say(nqp::objprimunsigned(uint)) | 22:14 | |
| camelia | 0 0 1 |
||
| MasterDuke | huh. locally i get 208 (if building moarvm with mimalloc and random values if building moarvm with --no-mimalloc) for the `num` cas3e | 22:16 | |
| m: use nqp; say(nqp::objprimunsigned(num)); say(nqp::objprimunsigned(int)); say(nqp::objprimunsigned(uint)) | 22:17 | ||
| camelia | 0 0 1 |
||
| MasterDuke | m: use nqp; say(nqp::objprimunsigned(num)); say(nqp::objprimunsigned(int)); say(nqp::objprimunsigned(uint)) | ||
| camelia | 0 0 1 |
||
| Geth | nqp/main: 6583e61c5b | (Stéphane Payrard)++ | 2 files for the sake of the parsetree browser We need something on github for the parsetree browser. It uses --github-user=<user> to generate rakudo |
||
| MasterDuke | oh, that's only if i build with `--optimize=0` | 22:20 | |
| nqp: say(nqp::objprimunsigned(num)) | 22:21 | ||
| camelia | 0 | ||
| MasterDuke | can anybody else repro ^^^ when building MoarVM with `--no-mimalloc` and/or `--optimize=0`? afk for the big game | 22:23 | |
|
23:03
sena_kun left
|
|||
| ugexe | github.com/Raku/nqp/commit/6583e61...2c6ae0147d - it really feels like this should be reverted | 23:29 | |
| tons of commented out code, some comments that don't seem to make sense, the commit message itself doesn't tell me what it is trying to do | 23:30 | ||
| github.com/Raku/nqp/commit/6583e61...9R255-R258 | 23:31 | ||
| like wth | |||
| Geth | nqp/main: 76778258bf | (Nick Logan)++ | 2 files Revert "for the sake of the parsetree browser" This reverts commit 6583e61c5b265257c8fcfd275522462c6ae0147d. |
23:43 | |
| ugexe | not to be an asshole but that was not ready for main | 23:44 | |