|
05:41
kjp left
05:46
kjp joined
|
|||
| Geth | MoarVM/main: 10 commits pushed by (Nick Logan)++, (Elizabeth Mattijsen)++ review: github.com/MoarVM/MoarVM/compare/0...34be1105fa |
15:27 | |
| MoarVM/main: ebdfdf928a | (Nick Logan)++ (committed using GitHub Web editor) | src/spesh/optimize.c Don't move a write across a branch in set elimination (#2055) Previously `conflict_free` only checked for other uses of the target register between the writer and the `set`. Retargeting the writer past a branch could clobber another version of that register that was still live on the other path. This stops moving a write earlier at a BB with more than one successor. Fixes #2054 |
15:44 | ||
|
16:25
MasterDuke joined
|
|||
| ShimmerFairy | I finally decided to poke at an "executable stack" deprecation warning I've been getting from dyncall for ages, and it looks like the problem came down to the relevant dyncall build file not having been re-built since 2016. I wonder if this sort of staleness has been the cause of some flappy tests I've been experiencing. | 16:27 | |
| Seems our build script only rebuilds 3rd party deps when their final outputs are missing, and they only go missing if you 'make realclean' or similar (git reset in the base repo doesn't help there). That seems... really bad. I'd expect the bundled deps to be rebuilt when their sources change, but right now submodule updates seemingly don't affect a well-used repo at all. | 16:29 | ||
| lizmat | wow | 16:31 | |
| sounds like a good catch! | |||
| ShimmerFairy | (honestly we should just switch to a standard build system like CMake, but I don't think I'm enough of a MoarVM dev to strongly make that suggestion) | 16:33 | |
| lizmat | is that supported on Windows? | 16:37 | |
| ShimmerFairy | CMake specifically is a very popular option for cross-platform software, it can generate Visual Studio solutions (or whatever they're called), and I think at this point VS has support for it built in. There are other choices I'm sure, I just brought CMake up because it's what I always use for my C++ work. | 16:42 | |
| MasterDuke | somebody (i don't remember the name/user) was working on converting the build to Meson. fwiw, i personally don't have any interest in switching build systems, but that's because i think every build system i've ever used is equally awful, i hate them all, so why bother doing a ton of work just to end up in the place | ||
| lizmat | well, I'm a build noob enough to like standardizing | ||
| MasterDuke | i'm not going to prevent someone from doing anything, but i will never volunteer to try and make a switch myself | 16:43 | |
| lizmat | understood :-) | ||
| MasterDuke | *end up in the **same** place | 16:44 | |
| lizmat | yeah, inferred that :-) | ||
| MasterDuke wishes i could find a build system i thought was great, but there are only so many more to be subjected to... | 16:47 | ||
| ShimmerFairy | In my lifelong experience using Gentoo and just generally building software from source, projects that insist on their own bespoke build system tend to be more annoying to deal with for little (if any) gain. And this isn't the first time I've encountered a weird odd thing with our bespoke build system. | ||
| MasterDuke | i'm including ours in the list of build systems i hate. i've just never found one that's better than the rest (i have found the worst one though, and that's Maven) | 16:49 | |
| hm, now that i'm looking at that whole commit (the one that introduced native_idx) more closely, i'm not following. it's being assigned an index and is commented as a position of an argument, but when it's read/used it's being passed as indicating the kind of something | 17:05 | ||
| oh, but some other existing code seems to be doing something very similar | 17:07 | ||
| lizmat feels a revert coming | |||
| ah, *phew* | |||
|
17:51
MasterDuke left
|
|||