ugexe Creating library moar.dll.lib and object moar.dll.exp 01:38
interp.obj : error LNK2001: unresolved external symbol _MVM_setjmp
gist.github.com/ugexe/3b688d250d49...t-txt-L902 01:41
patrickb: ^
seems like maybe related to the longjump stuff 01:42
the other error, "error LNK2001: unresolved external symbol _GetSystemTimePreciseAsFileTime" ive got on my VM for awhile now so I dont believe it to be related
patrickb ugexe: Yes, it's related to the long jump thing. I have an idea what might be the cause. Is it an ARM Windows? 08:51
patrickb ugexe: I'm a bit curious about the system, because that output says "x64 toolchain NO" and "size of pointers: 4" 13:22
oh, I also see "Target Architecture: x86", so it's simply an x86 32bit system. Right? 13:23
Geth MoarVM: patrickbkr++ created pull request #1893:
Fix MVM_setjmp on 32bit Windows		 13:53
patrickb ugexe: Can you try with the above PR? (It should successfully compile. The interesting question if the longjmp errors show up or not IIRC during rakudo compilation.) 13:55
ugexe Ah I missed it was 32bit. I’m using a windows 11 arm VM and it’s using x86 via its compatibility mode or whatever 16:20
not sure why it’s 32 bit tho
I’ll test later today
Geth MoarVM/main: 777294c43c | (Daniel Green)++ | azure-pipelines.yml
Maybe the order jobs are started is alphabetical?
 18:35
MoarVM/main: 1caf8d396f | MasterDuke17++ (committed using GitHub Web editor) | azure-pipelines.yml
Merge pull request #1891 from MasterDuke17/quick_hack_to_try_and_get_windows_jobs_to_start_first_in_CI

Maybe the order jobs are started is alphabetical?
timo i think the order that azure pipelines starts jobs in is essentially random 18:48
coleman why does the order matter in this case? 18:59
ugexe They probably take the longest 19:15
MasterDuke github.com/MoarVM/MoarVM/pull/1892 has passed CI, but maybe we're too close to a release to merge it? 19:35
timo phew. yeah, a libuv bump could be a bit too much, especially when we already have the first blin run almost done? 19:37
MasterDuke yeah. wonder if the new libuv changes anything for github.com/MoarVM/MoarVM/pull/1882? 19:45
guifa: mind testing if github.com/MoarVM/MoarVM/pull/1882 is ok after being rebased on top of github.com/MoarVM/MoarVM/pull/1892? 19:46
[Coke] blin run just finished, ticket opened
guifa MasterDuke you mean locally or is there a way I can force the recheck on there? (sorry, n00b) 19:47
MasterDuke i think you'd have to perform the rebase locally, but i guess if you force pushed once that's done you could get a CI review 19:49
wow, the 5th function in a profile of `my $s = 0; my $R = "rakudo/README.md".IO; my $L = "rakudo/LICENSE".IO; for ^1_000 { $s += $R.slurp.words.elems; $s += $L.slurp.words.elems;  }; say $s` is `get_attribute` 19:51
timo could be attributes of the iterator objects? 20:02
MasterDuke hm. any easy way to tell? 20:06
this was a perf profile btw, not a rakudo profile 20:07
ran it again and it was tied for 4th with MVM_string_find_not_cclass 20:08
timo yeah 20:09
i have it open in perf now too
+ 10.10% 6.47% rakudo [JIT] tid 829555 [.] count-only(SETTING::src/core.c/Str.rakumod:2848) ▒
11th place in inclusive time 20:10
MasterDuke fyi, i'm on my mba so no jit
timo but from self time it's third
MasterDuke ugh, i really want versions of all the string function "specialized" on the storage type, but they're going to be such a pain to create 20:14
timo if you like you can try making $!str into a local variable in that function 20:15
MasterDuke $!value you mean? 20:21
timo Str.rakumod line 2848 has everything in local variables except for $!str 20:24
where is $!value from?
MasterDuke oh, for me line 2848 is in `multi method trim-leading` 20:25
timo i might be slightly out of date
2769 for me 20:26
MasterDuke count-only in `my class Words does PredictiveIterator {`? 20:27
timo that's the right one
MasterDuke ok, i'll see if that changes anything 20:28
looks like time dropped from ~0.285s to ~0.255s and instructions from ~5.102b to ~4.572b 20:31
and get_attribute is not even on the first page in perf
timo can you do a silly different experiment and give that method a definite constraint on the invocant? 20:33
presumably (Words:D: --> Int)
(Words:D: --> Int:D)
MasterDuke that plus making $!str a local? 20:34
timo try keeping $!str as attribute for a moment 20:40
i see in the spesh log that it doesn't consider "self is concrete" as proven
MasterDuke combined doesn't seem to change anything, now trying just the constraint
*combined doesn't seem to be an improvement beyond making a local for $!str 20:41
just constraint isn't really any improvement 20:42
maybe tiny, i
'd have to do some more rigorous testing to be sure 20:43
timo ok, weird. maybe that's also a spot to look at for general spesh optimizations 20:44
MasterDuke fwiw, i just tried adding that constraint to all the `Words` methods but no change 20:46
ugexe patrickb: that PR gets past the error. i cant tell if you if it works or not though since I still have that other unrelated error preventing it from building 20:54
i forget, is there something preventing us from updating dyncall? 20:57
MasterDuke i think maybe i experimented once and not many version bumps worked? wouldn't swear to that at all though... 20:58
timo: fyi, making a local for $!str in the count-only of Lines didn't make as much of a difference 21:00
ugh, how do i trigger push-all? 21:14
.reverse does it 21:19
timo right, i would assume that it runs the findcclass and findnotcclass is called less often for lines than it would be for words, unless a file has just one word per line? 21:20
MasterDuke findnotcclass isn't even called for lines 21:22
timo oh ok 21:28
i guess that makes it do even fewer getattr for the $!str
it's not supposed to be using slow getattr, which you already complained about in a different context i think 21:30
MasterDuke i didn't check if it's using the slow one or now 21:34
timo right, i was just assuming 21:39
ugexe we need an updated dyncall for windows arm support i believe 21:44
i tried updating dyncall locally once to get windows arm to work and it did compile and seemed to work, but i didnt run the spectest or anything significant 21:45
(this was like 2 years ago)
Geth MoarVM/main: caf97bf073 | (Patrick Böker)++ (committed using GitHub Web editor) | src/platform/setjmp.h
Fix MVM_setjmp on 32bit Windows

Co-authored-by: Patrick Böker <patrick.boeker@clarisights.com>		 21:52
patrickb ugexe: I'm not aware of any reasons not to update dyncall. 22:01
MasterDuke timo: maybe the "test" rakudo ci jobs should install TAP::Formatter::JUnit and App::Prove without running their tests? 22:04
took almost two min to install them 22:05
oh, that's the windows job. the linux job only took ~40s to install modules. still, maybe it could be faster 22:06
wait, maybe it's already not running tests? 22:07
maybe the debug output is actually kind of slow? 22:11
timo tests.reproducible-builds.org/debi...oarvm.html this is suspicious 23:01
it's got "MVM_CAN_UNALIGNED_INT32" set to 1 in one and 0 in the other attempt 23:03
meaning our detection for whether unaligned int32 access is supported or not by the target architecture is flappy?
anyway, debian sez: Migration status for moarvm (2024.09+dfsg-2 to 2024.09+dfsg-3): Will attempt migration 23:04

Powered by Cro and the Raku® Programming Language.

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

Thank you!