01:05 librasteve_ left
Geth setup-raku/dependabot/npm_and_yarn/glob-10.5.0: 86c0afef6c | dependabot[bot]++ (committed using GitHub Web editor) | package-lock.json
Bump glob from 10.4.5 to 10.5.0

Bumps [glob](github.com/isaacs/node-glob) from 10.4.5 to 10.5.0.
  - [Changelog](github.com/isaacs/node-glob/blob/m...ngelog.md)
  - [Commits](github.com/isaacs/node-glob/compar.....v10.5.0)
  ---
... (7 more lines)
02:33
setup-raku: dependabot[bot]++ created pull request #44:
Bump glob from 10.4.5 to 10.5.0
03:45 disbot1 left, disbot2 joined 05:30 melezhik joined
Geth setup-raku: bf6cff2081 | dependabot[bot]++ (committed using GitHub Web editor) | package-lock.json
Bump glob from 10.4.5 to 10.5.0 (#44)

Bumps [glob](github.com/isaacs/node-glob) from 10.4.5 to 10.5.0.
  - [Changelog](github.com/isaacs/node-glob/blob/m...ngelog.md)
  - [Commits](github.com/isaacs/node-glob/compar.....v10.5.0)
  ---
... (8 more lines)
09:12
09:37 librasteve_ joined
ab5tract fascinating! so CurriedRoleHOW.type_check is never called on assignment to a typed container when RAKUDO_RAKUAST=1 12:11
so maybe there is an overly zealous guard in RakuAST somewhere...
12:16 melezhik left
ab5tract Looks like CurriedRoleHOW.type_check is only called in the optimizer :o 12:35
why is the optimizer still running when I do --optimize=0 though?
I don't see anything relevant in the docs either.. plz halp 12:39
lizmat and with --optimize= ?? 12:41
"0" is true
ab5tract right but it is listed as an option in the --help
same thing with `--optimize=` 12:42
lizmat hmmm 12:47
perhaps timo has an idea
12:53 librasteve_ left
timo there's a difference between --optimize=off and --optimize=0 where --optimize=0 still does the correctness checks it can do 12:57
ab5tract ah, `off` doesn't appear in `--help` 13:04
13:04 melezhik joined
ab5tract that does what I want :) 13:05
Geth rakudo/main: 04a36dd13d | ab5tract++ | src/Perl6/Compiler.nqp
Adjust CLI help to mention --optimize=off
13:06
ab5tract it turned out to be a false positive anyway.. lots of `type_check` calls in the optimizer stage but none once the script's code is actually running 13:07
just when I thought I had caught a lucky break 13:08
CurriedRoleHOW.new_type calls `nqp::settypecheckmode` with `nqp::const::TYPE_CHECK_NEEDS_ACCEPTS` 13:15
shouldn't that enforce a runtime call to (at least) `CurriedRoleHOW.accepts_type` ? 13:16
13:55 librasteve_ joined
ab5tract interesting... 14:45
m: role R[::T] { has @.a is Array[T] }; my $ri = R[Int].new; use nqp; dd nqp::istype($ri.a.WHAT,Array[Int]) 14:48
camelia 1
ab5tract m: Q| role R[::T] { has @.a is Array[T] }; my $ri = R[Int].new; use nqp; dd nqp::istype($ri.a.WHAT,Array[Int]) |.AST.EVAL
camelia Could not instantiate role 'R'; exception details:

Unknown compilation input 'qast'
in any IMPL-COMPILE-DYNAMICALLY at src/Raku/ast/code.rakumod line 429
in any at src/Raku/ast/code.rakumod line 148
in sub at src/Rak…
ab5tract uh, that's strange. I just get a `0` for that code locally 14:49
right, because it is Array[T] .. 14:51
timo ab5tract: are you wary of automatic punning if you're not handling these objects really carefully? i'm not sure if that's even relevant, just a thought 16:10
16:26 melezhik left
lizmat so is "fez remove" supposed to work now ?? 17:09
17:12 melezhik joined
ab5tract I think I've narrowed it down to a difference in how the grammar handles parametric types from the setting vs those declared in user code: gist.github.com/ab5tract/da93dea39...51f5c253fa 18:18
nine: if you have a moment, I'd be curious whether you think that I am onto anything here 18:19
18:28 finanalyst joined
ab5tract ok.. that appears to be a false start. or at least, changing how that behaves didn't fix anything 19:07
m: role R[::T] { has Array[T] $.t }; dd R[Int].new: t => [5] 19:11
camelia Type check failed in assignment to $!t; expected Array[Int] but got Array ([5]). You have to pass an explicitly
typed array, not one that just might happen to contain elements of the
correct type.
in block <unit> at <tmp> line 1
ab5tract m: role R[::T] { has Array[T] $.t }; dd R[Int].new: t => my Int @ = [5]
camelia R[Int].new(t => Array[Int].new(5))
ab5tract This works in RakuAST as well. Which implies that the problem is actually some subtle thingy happening with RakuAST::Trait::Is
m: role R[::T] { has T @.t }; dd R[Int].new: t => my Int @ = [5] 19:12
camelia R[Int].new(t => Array[Int].new(5))
ab5tract I can't use the .AST.EVAL trick to demonstrate it here, though, because instantiating R explodes 19:13
19:44 coleman left 19:45 coleman joined 22:01 melezhik left 23:54 finanalyst left