|
01:27
Voldenet left
02:01
Voldenet joined
|
|||
| patrickb | timo: What do I need to trigger the failure and what's the failure mode? VC>2022? Fails the Moar build? | 08:11 | |
|
09:30
sena_kun joined
|
|||
| Geth | Digest-xxHash/main: 135e6f8479 | (Elizabeth Mattijsen)++ | lib/Digest/xxHash.rakumod Fix breakage caused by proper uint64 implementation Before this was implemented, uint64 was basically a alias for int64, which meant that it *could* return negative values. The tests depend on that behaviour, and the tests would die because now one can *not* store a negative value in a uint64 anymore. Fixed by just using an int64 in signatures instead. |
09:45 | |
| Digest-xxHash/main: 054564082d | (Elizabeth Mattijsen)++ | .github/workflows/linux.yml Hopefully fix linux CI by asking for the correct version |
|||
| Digest-xxHash/main: 8320ba5f05 | (Elizabeth Mattijsen)++ | .github/workflows/linux.yml Linux CI fix #3 |
10:01 | ||
|
10:01
sena_kun left
10:04
finanalyst joined
|
|||
| Geth | Digest-xxHash/main: 6880ebc578 | (Elizabeth Mattijsen)++ | lib/Digest/xxHash.rakumod Allow any version of xxhash |
10:09 | |
| Digest-xxHash/main: c05972a698 | (Elizabeth Mattijsen)++ | 2 files More CI tests testing |
10:13 | ||
| Digest-xxHash/main: 539ffa91b3 | (Elizabeth Mattijsen)++ | 2 files 1.8.0 |
10:27 | ||
| lizmat gives up on getting linux CI to work with xxHash | |||
|
10:31
finanalyst left
|
|||
| ab5tract | patrickb: In CI settings I belive windows > 2019 (which I guess is an alias for windows server 2019 but which must have a corresponding mapping to consumer windows versions) | 12:05 | |
| "Rakudo build / compile jobs on Windows11 and on "GitHub latest" stops with an error" (from R#5566) | 12:07 | ||
| linkable6 | R#5566 [open]: github.com/rakudo/rakudo/issues/5566 [MoarVM][Windows] Rakudo doesn't build on GitHub "windows-latest"... and any recent Windows OS and/or MSVC release?! | ||
| patrickb | timo: I can reproduce the failure. Now let's try fixing. | 12:39 | |
| timo: Adding the no-frills-longjmp to moar makes the nqp build die. (...\moar.exe' : return code 0x0000005) Now I'd need some hint of how to debug this thing. Can you give me a primer? | 13:27 | ||
| ab5tract | patrickb: what were the requirements for reproducing the error in the end? | 13:59 | |
| patrickb | I can't say for sure. I am on Win11 with VS2022. I didn't need to change anything for it to fail. | 14:01 | |
|
14:03
rba left
|
|||
| ab5tract | Okay, so it seems that pairing a recent Windows with an otherwise-working msvc seems to do the trick | 14:03 | |
| As [Coke] reported VS2022 working for him previously | 14:04 | ||
| Geth | rakudo/main: 2053ea9884 | (Elizabeth Mattijsen)++ | 2 files Remove some dead code |
||
|
14:05
rba joined
14:22
Geth joined
|
|||
| ab5tract | This sounds familiar… | 14:22 | |
|
14:26
lizmat_ left,
lizmat joined
|
|||
| ab5tract | patrickb: I hope maybe this can help? blog.lazym.io/2020/09/21/Unicorn-D...n-Windows/ | 14:31 | |
| patrickb | That's what timo already tried to do and failed. WIP in github.com/MoarVM/MoarVM/pull/1852 | 14:35 | |
| The latest idea is to instead get our good old longjmp back via github.com/GlinkieGamesInc/longjmp_win64 | 14:36 | ||
| That's what I'm currently trying. | |||
| ab5tract | Ah, sorry for the noise then | 14:42 | |
| patrickb | I do think that getting the new longjmp working is the thing we should pursue in the medium term. That custom longjmp is only implemented on win64, on arm it will still break. | 14:46 | |
| ab5tract: Do you have any experience with RtlAddFunctionTable? Maybe we could push that branch over the finish line? | 14:48 | ||
|
14:49
[Coke] left
|
|||
| patrickb | Ok. I got it working with the no-frills-longjmp implementation. | 14:49 | |
| To push forward with that we'd need allowance by the author though, as I'm pretty sure you can't mix apache2 and artistic2. | 14:50 | ||
| timo | do we know how setjmp/longjmp is implemented in windows arm? | 15:35 | |
| ab5tract | Unfortunately I don’t have any experience with Windows APIs at all :( | 15:36 | |
| patrickb | I don't. | 15:40 | |
| timo: What's your call? Just proceed with longjmp_win64 (which I did manage to get working) or pour more time into RtlAddFunctionTable? | 15:41 | ||
| lizmat | do I understand correctly that the longjmp_win64 is basically a hack, and the RtlAddFunctionTable is a more generic approach that would also work on arm ? | 15:46 | |
| timo | i assume that RtlAddFunctionTable also exists on arm, but the format of the stuff you put into that table is likely different, at least slightly? | 15:48 | |
| the longjmp_win64 is not so much a hack, i wouldn't say | 15:49 | ||
| lizmat | but wouldn't work on arm? | ||
| does that include Apple silicon? | 15:50 | ||
| timo | right, implementing longjmp and setjmp requires you to go very close to "the metal", you have to directly fiddle with registers, which usually means you have to write a bit of assembly | ||
| it also depends not only on the machine, but also the ABI could influence what exactly you have to do, not 100% sure on that | 15:51 | ||
| lizmat | I wouldn't want MoarVM to stop working on Apple silicon: that would severely hamper my workflow :-) | 15:52 | |
| timo | for apple silicon, i would assume the longjmp/setjmp implementation they have is one that doesn't give us problmes | ||
| patrickb | completely different idea. that unicorn blog post says that the win impl actually does provide a non-unwinding impl. It's just not available publicly. IIUC it's a single flag in the jmp_buf that switches the impl. | 15:54 | |
| timo | learn.microsoft.com/en-us/cpp/buil...w=msvc-170 looks like this describes the format of the unwind tables on windows arm, but i haven't looked yet if setjmp/longjmp on windows arm uses stack unwinding at all | 15:55 | |
| patrickb | Can we just be a little dirty and set that flag manually post the setjmp call? | ||
| timo | you can try that, i didn't have enough patience last time i dove into windows, but it could work and make less trouble | ||
| patrickb | I'll try. It may be dirty, but could possibly be the least invasive and most maintainable approach. | 15:56 | |
| ab5tract: That blog post you dug up actually turned out to be pretty helpful! | 15:59 | ||
| timo | it's cool you got windbg to do reverse debugging, it looked to me like you have to shell out for a visual studio pro membership or whatever to get that | 16:00 | |
| patrickb | Dunno. I just downloaded the thing... | 16:03 | |
| Another question. That blog says the `setjmp` actually takes two parameters but only provides a signature for one. Is there really no way to somehow revive a `setjmp(jmp_buf, int)`? We are in C land after all. Why shouldn't we be able to just reassign a function pointer? | 16:05 | ||
| timo | you can try #undefine or #undef or what it's called, and then putting the "custom" signature below it? | 16:10 | |
| casting "setjmp" to a function pointer and calling that could also work, yeah | 16:11 | ||
| i can never remember the syntax for function pointers though ... | |||
| ((void (*)(struct jump buffer or whatever*, int)setjmp)(jmp_buf, 1)? | 16:12 | ||
| i'm so glad you're picking up the windows stuff, thank you! | 16:23 | ||
| patrickb | "'_setjmp': purely intrinsic functions have no address" | 16:36 | |
| So I guess we can't do that. Then let's fix up that field in the opaque struct instead! :-P | |||
| It seems `tc->interp_jump[0].Part[0] = 0;` is all that was needed. The shape changes for every different architecture though. | 16:55 | ||
| Should I try to package that into a define? | |||
| patrickb does so | 17:15 | ||
| ab5tract | In terms of architectures, I think we support: x86, x86-64, aarch64 (arm64.. is there a difference?) | 17:18 | |
| Do we have other ones to worry about too? | |||
| ab5tract wonders if it is even possible to spin up a 32-bit windows box of remotely recent vintage | 17:19 | ||
| timo | well, debian does test rakudo and a couple modules against a wider range of architectures | 17:20 | |
| ab5tract | patrickb: does the shape change per-OS as well? | ||
| timo | i don't know what we as "the raku dev team" officially support | ||
| ab5tract: probably | 17:21 | ||
| ab5tract | timo: interesting.. like sparc and mips and stuff? | ||
| timo | buildd.debian.org/status/package.php?p=rakudo | ||
| i don't think i've ever heard of sh4? | |||
| ab5tract | timo: whoa | 17:22 | |
| I think that’s a Japanese chip from Sharp.. | |||
| Ah, Hitachi | 17:23 | ||
| timo | "The J-Core Project plans to support the SH4 instruction set in their J4 processor in 2017" i sure hope this is just the page not being looked at in a long long time, and not j-core missing that timeline by 7 years | 17:25 | |
| oh, from what i've seen, arm64 and aarch64 are synonyms | 18:01 | ||
| i guess there is some kind of difference, but it usually doesn't matter? | 18:07 | ||
| ab5tract | gotta love that :) | 18:08 | |
| patrickb | ab5tract: Yes it does. But I have it all done to the best of my knowledge. | 19:04 | |
| ab5tract: Oh, you mean per-OS, not per arch. I'd guess so. But it doesn't matter. This workaround is exclusively needed on Win, as Win is the only OS that tries to do stack unwinding in longjmp AFAIK. | 19:06 | ||
| ab5tract | ah, good to hear! | 19:09 | |
|
19:10
sena_kun joined
|
|||
| ab5tract | especially since Win arches are limited | 19:10 | |
| really awesome that you've leaped this long-standing hurdle patrickb++ | 19:22 | ||
| patrickb | ab5tract: I've tried the raku in GitBash thing now. It's still hanging. I think I know why. Want me to explain? | 20:20 | |
| Geth | rakudo/main: 93baf30989 | (Elizabeth Mattijsen)++ | src/core.c/REPL.rakumod Remove some more (now) dead code |
20:21 | |
| ab5tract | patrickb: sure. Also, a surprising result considering $*IN.t is False in this scenario | 22:12 | |
| patrickb | when not passing the repl-mode arg the condition in github.com/Raku/nqp/pull/827/files...4e83a2L321 does not hit | 22:14 | |
| ab5tract | Yeah, I don’t see why that isn’t reached | 22:15 | |
| patrickb | It instead goes here: github.com/Raku/nqp/pull/827/files...4e83a2L331 | ||
| ab5tract | Also, what’s the deal with ‘exit’ being parsed as ‘asdf’ when repl-mode is process? | ||
| patrickb | because `%adverbs<repl-mode>` is empty | 22:16 | |
| ab5tract | So it’s the same as ‘raku -‘ .. got it | 22:17 | |
| And I didn’t run into this because I was testing via | |||
| patrickb | the ASDF vs exit is because the output is offset by one enter push. I first typed "asdf", return, "exit", return. | ||
| ab5tract | ‘repl()’ in Comma | ||
| Ah, I didn’t notice that because it’s before the prompt appeared | 22:20 | ||
| Well, looks like it is unresolvable in the end as you mentioned, at least in terms of the CLI | 22:21 | ||
| patrickb | Yeah, I fear so. I still like the new repl modes though. | 22:22 | |
| ab5tract | Yeah those may be salvageable | ||
| From the exception message from repl-mode TTY seems to demonstrate that $TERM is not set to anything usable here either | 22:24 | ||
| patrickb | Yeah. And we should not test for term to print out an error message I'd say. | 22:29 | |
| patrickb is off to bed | |||
| ab5tract | Yeah, unless it was something like “gitforbash” | 22:35 | |
| Thanks for testing! | |||
|
23:17
sena_kun left
|
|||
| timo | oh i should point out that we only need to change anything at all related to setjmp/longjmp on platforms where we have a jit compiler, so it's not relevant to arm64 windows or macos at all; except on arm macos you should be able to run moar as a x86_64 program and get jit that way through rosetta and i imagine that works fine | 23:37 | |