🦋 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:47 sena_kun left
Geth rakudo/ugexe/fix-leaking-handles: 155818f4ad | (Nick Logan)++ | src/core.c/CompUnit/Repository/Installation.rakumod
Avoid leaking repo.lock handle

The repo.lock file would be opened when installing a distribution, but would never get closed. On windows this could manifest as an error saying it can't delete repo.lock because the resource is busy. This updates CURI.install to close the repo.lock file when leaving the function.		 03:06
rakudo/ugexe/fix-leaking-handles: e620769939 | (Nick Logan)++ | src/core.c/CompUnit/Repository/Installation.rakumod
Simplify unlock logic
rakudo: ugexe++ created pull request #5523:
Avoid leaking repo.lock handle 		03:12
03:41 epony left 04:50 epony joined 07:34 [Coke] left 07:37 [Coke] joined
patrickb ugexe++ 07:55
Geth rakudo/main: 155818f4ad | (Nick Logan)++ | src/core.c/CompUnit/Repository/Installation.rakumod
Avoid leaking repo.lock handle

The repo.lock file would be opened when installing a distribution, but would never get closed. On windows this could manifest as an error saying it can't delete repo.lock because the resource is busy. This updates CURI.install to close the repo.lock file when leaving the function.		 08:25
rakudo/main: e620769939 | (Nick Logan)++ | src/core.c/CompUnit/Repository/Installation.rakumod
Simplify unlock logic
rakudo/main: 107810b969 | niner++ (committed using GitHub Web editor) | src/core.c/CompUnit/Repository/Installation.rakumod
Merge pull request #5523 from rakudo/ugexe/fix-leaking-handles

Avoid leaking repo.lock handle
09:36 sena_kun joined 10:13 finanalyst joined
Geth rakudo/main: 7ca96bbd90 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/Repository/Installation.rakumod
Properly leave the install scope

Check for there actually being a concrete lock, before trying to unlock and close.		 10:49
11:36 finanalyst left 12:38 epony left 13:41 epony joined
Geth rakudo/main: 71c0151aa7 | (Daniel Green)++ | 2 files
Add Int/Real coercing versions of `infix:<div|mod>`

This makes them consistent with the other operators, so e.g., `say "6" div 3` now prints `2`, instead of
  `Calling infix:<div>(Str, Int) will never work with any of these multi signatures:
   (Int:D \a, Int:D \b --> Int:D)
   (int $a, int $b --> int)
   (uint $a, uint $b --> uint)`
Fixes github.com/Raku/problem-solving/issues/326		 15:20
rakudo/main: 3eba92f5bf | MasterDuke17++ (committed using GitHub Web editor) | 2 files
Merge pull request #4946 from MasterDuke17/add_multis_for_div_and_mod_that_coerce_to_Int_and_Real_respectively

Add Int/Real coercing versions of `infix:<div|mod>`
rakudo/main: 35760cebc3 | (Elizabeth Mattijsen)++ | src/vm/moar/dispatchers.nqp
Streamline raku-multi-core dispatcher and helper subs

  - move initialization of Positional(BindFailover) to when they're needed
  - simplify multi-junction-failover helper sub
  - add MultiDispatchCall.trivial method to faster check for trivial dispatch
  - add MultiDispatchAmbiguous.more method to faster trivial ambiguity
  - much more internal comments		 16:45
nqp/main: cd8b1bb61f | (Elizabeth Mattijsen)++ | 2 files
Add all SIG_ELEM constants as nqp::const::xx constants

Allowing the prevention of a lot of initializations in the Raku bootstrap.
NOTE: note sure why this has to be maintained for the MoarVM and JVM backends seperately.		 17:09
jdv note note sure:) 17:51
lizmat heh not :-) 17:52
18:03 epony left 18:09 epony joined
ugexe hmm, why *dont* we have something like golang/perl `defer $thing` 18:11
we have LEAVE, but yeah as noted in that recent commit it isn't exactly the same
jdv how exactly is it different? 18:15
ugexe m: sub foo { die 666; LEAVE say 42; }; foo() 18:16
camelia 42
666
in sub foo at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat you mean: when the LEAVE phaser gets activated
leont defer activates on runtime, LEAVE on scope enter
(poor words, can't find the better ones)
lizmat LEAVE is actually compile time, but yes
in RakuAST I thin a DEFER phaser could actually be added relatively easy 18:17
*think
Geth nqp/main: bdf63a606c | (Elizabeth Mattijsen)++ | 2 files
Add some more SIG_ELEM constants to nqp::const::xxx

These occurred inside Raku's Parameter class		 18:22
ugexe lizmat: i'm not really seeing why your commit would have broken windows installation, but apparently it does 19:02
lizmat which commit ? 19:03
7ca96bbd90 ??
linkable6 (2024-02-10) github.com/rakudo/rakudo/commit/7ca96bbd90 Properly leave the install scope
ugexe yeah 19:06
lizmat Failed to unlock filehandle: 158 19:07
ugexe only thing i can think of is there could be something that happens when .close is called before .unlock (my PR called .close first)
lizmat when I did that order, rakudo wouldn't build
because .close would nullify the $!PIO and so .unlock had nothing to work on 19:08
ugexe its technically not building now either though 19:09
just on a different OS
lizmat true
ugexe i imagine reverting your commit and then changing my lines to $lock.?close and $lock.?unlock might be sufficient to get working, but i'm still curious what is going on 19:11
i wonder if there could be a weird interaction between LEAVE $handle.whatever and IO::Handle::DESTROY 19:12
lizmat ahhh... that might be it 19:13
in any case, doing the unlock after the close, won't work 19:14
unlock does nqp::unlockfh($!PIO)
and close does: $!PIO := nqp::null
ugexe .?close wont work either hmm 19:15
m: my IO::Handle $x; $x.?close
camelia Invocant of method 'close' must be an object instance of type
'IO::Handle', not a type object of type 'IO::Handle'. Did you forget a
'.new'?
in block <unit> at <tmp> line 1
ugexe doing the unlock after the close does work though 19:16
we saw that
its just that if that `die` on an earlier line is thrown there is a regression 19:17
but we do know we can call LEAVE $h.close; LEAVE $h.unlock;
we know that because my PR passed all the CI tests
lizmat m: LEAVE say "one"; LEAVE say "two" 19:19
camelia two
one
lizmat which would imply your code would first do an unlock, and then a close
which mine does as well? 19:20
ugexe right, thats what i meant
it does do it in the same order, but it isn't exactly the same as mine
lizmat LEAVE (say "one"),(say "two")
evalable6 one
two
ugexe i'm not sure what all is different. at a minimum there is an additional phaser registered
lizmat I wonder if it's a timing issue ? 19:21
ugexe and that could potentially change how DESTROY works
i wonder if calling $handle.do-not-close-automatically would help 19:23
that would presumably rule our DESTROY 19:24
s/our/out/
lizmat by all means, try :-) 19:25
I thought I was just preventing an execetion error if the open would fail
Geth nqp/main: ad8bf79cf1 | (Elizabeth Mattijsen)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
Correct value of SIG_ELEM_IS_NOT_POSITIONAL constant
 19:26
rakudo/ugexe-patch-2: 7c844bb712 | (Nick Logan)++ (committed using GitHub Web editor) | src/core.c/CompUnit/Repository/Installation.rakumod
Work around repo.lock unlocking on windows

Commit 7ca96bbd90 started showing a `Failed to unlock filehandle: 158` error on Windows. This attempts to work around a presumed issue in how `IO::Handle::DESTROY` and e.g. `LEAVE $handle.unlock` interact by disabling the auto closing behavior of the lock file being used.		 19:33
rakudo: ugexe++ created pull request #5524:
Work around repo.lock unlocking on windows
lizmat ugexe: I guess now we await the CI, right ? 19:34
ugexe yeah
lizmat chec 19:35
k
Geth rakudo/main: 9afcfd1bc1 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get the new nqp::const::SIG_ELEMxxx constants
 19:41
rakudo/main: 512978791d | (Elizabeth Mattijsen)++ | 4 files
Use the new nqp::const::SIG_ELEMxxx constants

Instead of initializing them here and there, with the danger that they do not use the same name and/or the same values in the various bootstrap cases.		 19:42
ugexe Didn't work 19:53
lizmat meh so maybe it *is* timing related ?
ugexe I'm not sure. honestly i don't think any additional timing from having a second LEAVE block would be sufficient to have this consistent change in behavior 19:55
but then i'm not sure what else it could be
19:56 finanalyst joined
ugexe oh hmm, it looks like calling .unlock might re-register the file to be automatically closed 20:07
maybe not... cant tell 20:10
20:38 [Coke]_ joined 20:41 [Coke] left 20:46 [Coke]_ is now known as [Coke]
ugexe the error 158 suggests that the error is the file is not locked 20:59
m: my $x = q|META6.json|.IO.open(:w, :shared); $x.lock; $x.close; $x.unlock 21:01
camelia get native descriptor requires an object with REPR MVMOSHandle (got VMNull with REPR Null)
in block <unit> at <tmp> line 1
ugexe not sure that is related, but not a great error
m: my $x = q|META6.json|.IO.open(:w, :shared); $x.lock; $x.unlock; $x.unlock; 21:06
camelia ( no output )
ugexe on windows that gives 21:07
Failed to unlock filehandle: 158
in method unlock at 'SETTING::'src/core.c/IO/Handle.pm6 line 650
so how the heck is that handle becoming unlocked, seemingly by the rearrangement of that LEAVE logic... 21:08
Geth rakudo/main: bae06a2c8c | (Elizabeth Mattijsen)++ | src/core.c/Parameter.rakumod
Streamline some Parameter methods, specifically .ACCEPTS

Mostly about using a native int instead of the attribute: this codegens to faster local references instead of attribute fetches.		 21:09
lizmat ugexe: perhaps the lock failed in the first place?
(silently) 21:10
ugexe maybe, but using .lock on a handle seems to block correctly on windows on a 1 liner 21:11
lizmat weird 21:12
ugexe maybe it is timing related. your pr worked on my windows vm 21:21
`LEAVE { try .unlock; try .close };` might be a workaround 21:24
oh jeez 21:25
its obvious
github.com/rakudo/rakudo/commit/7c...06eb2e44c5
accidently removed the call to $lock.lock 21:26
Geth rakudo/ugexe-patch-2: a723c387ce | (Nick Logan)++ (committed using GitHub Web editor) | src/core.c/CompUnit/Repository/Installation.rakumod
Fix removal of file locking during installation

7ca96bb accidentally removed the logic to lock the file. This reintroduces the necessary locking.		 21:29
rakudo: ugexe++ created pull request #5525:
Fix removal of file locking during installation
ugexe i wonder if rakudo should make unlocking an unlocked file the same on Windows as on other os 21:37
which don't throw an error
21:40 epony left 22:23 finanalyst left
ugexe currently it looks like calling something like `$handle.do-not-close-automatically; $handle.unlock;` would cause the handle to still be closed automatically do to `.unlock` re-registering it to be auto-closed (presumably because .lock un-registers auto-closing). however, intuitively i expect calling $handle.do-not-close-automatically to cause it not be closed regardless of what i do with the 23:00
handle later
it feels like do-not-close-automatically needs an attribute to mark it has been called by e.g. user code, so the later call to .unlock doesn't try to re-register it to be auto closed 23:01
jdv is slightly concerned this seems complicated. seems coukd be simple. 23:18
23:23 epony joined
ugexe yeah, i'm not sure I like DESTROY auto-closing handles or not 23:24
it could be interested to get rid of all that logic, and have DESTROY just warn about unclosed file handles 23:26
interesting^
Geth rakudo/main: a723c387ce | (Nick Logan)++ (committed using GitHub Web editor) | src/core.c/CompUnit/Repository/Installation.rakumod
Fix removal of file locking during installation

7ca96bb accidentally removed the logic to lock the file. This reintroduces the necessary locking.		 23:48
rakudo/main: 5be1824c9f | (Nick Logan)++ (committed using GitHub Web editor) | src/core.c/CompUnit/Repository/Installation.rakumod
Merge pull request #5525 from rakudo/ugexe-patch-2

Fix removal of file locking during installation
23:52 sena_kun left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!