Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
MasterDuke [Coke]: i don't really know, i'm going off of what azure has, which is just windows server 2019 and 2022 02:23
ugexe MasterDuke: just a wild guess, but I wonder if the path to VS changed. Yours using 'Program Files (x86)' still, but when I look at when I updated my appveyor files I see I stopped using (x86) - github.com/ugexe/zef/commit/448863...5377649cf4 02:41
so maybe the detection here isn't working because vswhere.exe is in that different path - github.com/MoarVM/MoarVM/blob/0454...ml#L12-L13 02:42
MasterDuke thanks, i'll try messing around with that 02:43
ugexe MasterDuke: I just looked on a windows 11 VM with VS 2022 and vswhere is in that 86 location, so I guess thats not it 02:51
MasterDuke hm, that led me to some more googling which suggests vswhere + azure + windows 2022 are problematic and i don't think can easily be fixed by only changing paths
e.g., github.com/microsoft/vswhere/issues/250 02:52
 i think i'm going to back the windows change out of the pr, that can be handled later by someone who knows more about them than i do
ugexe i wonder what vswhere.exe is outputting on azure 02:54
Geth MoarVM/master: 8 commits pushed by (Daniel Green)++, MasterDuke17++ 05:01
Geth MoarVM: 34bae78d45 | (Stefan Seifert)++ | 4 files
Work around "const_iX NYI" after getlexstatic_o with fallback resolver

getlexstatic_o and sp_getlexstatic_o did not take into account that MVM_frame_find_lexical_by_name may now dispatch if a fallback resolver is in use.
Note: this fix is _not_ complete as it completely ignores that we have ... (5 more lines)
16:46