|
02:05
japhb left
02:09
japhb joined
03:09
MasterDuke joined
05:31
MasterDuke left
09:29
sena_kun joined
12:59
rba left
13:02
rba joined
|
|||
| Geth | nqp/add-is-interactive: 430373b14c | ab5tract++ | src/HLL/Compiler.nqp Add is-interactive to HLL::Compiler This commit nukes the hard-to-grok distinction of `interactive` vs `non-interactive` repl-modes and replaces it with the following options: - `tty` ... (21 more lines) |
14:53 | |
| rakudo/fail-gracefully-outside-of-supported-terminal-emulator: b3d1b1da94 | ab5tract++ | 3 files Be the change you wish to see |
15:02 | ||
| nqp/add-is-interactive: 73289f5a7b | ab5tract++ | src/HLL/Compiler.nqp Update repl-mode options in HLL::Compiler This commit nukes the hard-to-grok distinction of `interactive` vs `non-interactive` repl-modes and replaces it with the following options: - `tty` ... (21 more lines) |
15:17 | ||
| rakudo/fail-gracefully-outside-of-supported-terminal-emulator: 295890e243 | ab5tract++ | tools/templates/NQP_REVISION Update with newest relevant NQP commit |
15:19 | ||
| rakudo/fail-gracefully-outside-of-supported-terminal-emulator: 78ef764d1b | ab5tract++ | 2 files Migrate REPL tests to repl-mode=process |
15:43 | ||
| ugexe | ab5tract: i think a good reason for not including many things in the core that seem ok now is that often those things were written before or without long term design considerations. The classic example would probably be php and its multiple methods that do the same thing but some more securely than others. They threw all sorts of features into the language where it was easy enough to implement | 15:45 | |
| but there was little thought into the design. For example a path library probably has to make some less than perfect tradeoffs to be cross platform (for example how to treat symlinks, file locking, etc on windows). To be clear I'm not arguing the stdlib or core should be tiny; I like Golangs stdlib but everything in it had a lot of design consideration including areas that should be taken into | |||
| account but are often ignored until later (such as windowsy things). Golang can habve a package manager in the core because they have tar and ssl in the core and they work on any platform. | |||
| ab5tract | yeah, that's fair. Maybe we can develop some rubrik for this though | 15:46 | |
| In terms of Test::Helpers, we have thousands of tests in roast running this code | 15:47 | ||
| ugexe | i think for something to be included in the core the author should be familiar with the problem space pretty well, not just having learned it as they put together the thing. and they should be familiar with that problem space across platforms as well unfortunately | ||
| from what i remember Test.rakumod is already a mess, which probably puts people off to adding more test stuff based on it (even if it will never go away) | 15:48 | ||
| ab5tract | it doesn't feel particularly messy from a user point of view until you start wondering why things are missing | 15:49 | |
| s/you/I/ | |||
| and why would Test ever go away? messy code can be refactored as long as it presents the same interface | 15:50 | ||
| ugexe | yeah but i think multiple people have tried refactoring it, including myself. largely to get it to work better / at-all in parallel | 15:51 | |
| it has quite a few globals i think was the main thing | |||
| ab5tract | I imagine it could be significantly simplified via RakuAST/macros | 15:53 | |
| but even if it were just replaced wholesale, don't we have the capability via `:api<>` to easily replace it even with a revised and incompatible interface? | 15:55 | ||
| [Coke] | we also have the concept of rakudo not being the official version - which is more of an ideal at this point than a reality - that means that if we expose something and say it's part of the spec, we're having an impact outside of rakudo. I feel like this was a stronger prohibition 15 years ago than it is today. :| | ||
| ugexe | ab5tract: no, because we dont have a dual life mechamism | ||
| old versions of raku dont have access to other versions of Test | 15:56 | ||
| ab5tract | that doesn't seem important to me, we specifiy minimum language versions in META6.json | 15:58 | |
| that logic seems to imply that no one would ever code against anything besides v6.c | |||
| it even seems to me that | 15:59 | ||
| Test:api<2.x> could be de-coupled from language revisions via a specification in test-depends | |||
| [Coke] | or test-depends on v6.e | 16:00 | |
| ugexe | Language version doesn’t map to core library versions | 16:38 | |
| ab5tract | I'm not sure I understand. If v6.e introduced a Test:api<2.0>, then wouldn't such a mapping exist? | 16:40 | |
| and then if a user had Test:api<2.1> in their test-depends, I would expect the module to fail to install on rakudo releases that don't include that version of Test | 16:41 | ||
| [Coke] | I think that sounds reasonable, but I don't think any of that scaffolding exists. | 16:42 | |
| ab5tract | true. this has been the subject of quite some debate over the years. | 16:43 | |
| (the relationship of rakudo releases to defining user expectations about what is provided by `raku` and Raku) | 16:44 | ||
| ugexe | I’m typing in a phone so it’s difficult to explain the nuance right now. But another thing is that all core modules share the same distribution | 16:45 | |
| I.e. making a test api 2.1 that requires 6.e also does the same to e.g. NativeCall | 16:46 | ||
| regardless i think we need a dual life strategy, which means splitting the core modules into separate distributions (harder than it sounds do to internal uses of -Ilib needing to be -Ilib/Test -Ilib/NativeCall etc) as well as releasing every change to those modules to an ecosystem | 16:52 | ||
| ab5tract | ugexe: ahhh, ok the shared distribution issue clarifies a a lot | 17:01 | |
| [Coke] | why is rakudo-m-early-build using the *installed* nqp path? | 17:15 | |
| if we're doing --gen-nqp, we should be using the one we gen'd, yes? | 17:16 | ||
| ab5tract | Ah, this answers the query I just posed in #raku | 17:25 | |
| [Coke] | also, cannot build on windows anymore (it's been 3 months since I built there) - nuking nqp and updating rakudo to 2024.10 got me far, but now dying on building CORE.c.setting - tried also nuking the install directory. no love. | ||
| C:\Strawberry\perl\bin\perl.exe Configure.pl "--gen-moar" "--gen-nqp" "--backends=moar" "--prefix=C:\raku" $* | |||
| ^^ Contents of config.status | 17:26 | ||
| ab5tract | Well we have been flying blind on CI/CD for windows … I guess maybe a genuine breakage got through :( | ||
| [Coke] | (still using installed nqp, presumably it's installed by the time the initial config step is done. ah well | 17:27 | |
| Yah, will start trying previous release tags, I guess. | |||
| then I can bisect if I find something working. | |||
| ab5tract | In NQP::Config::Rakudo I see that nqp_home is set to $prefix/share/nqp of no —nqp-home is specified | 17:31 | |
|
17:32
japhb left
|
|||
| ab5tract | s/of/if/ | 17:32 | |
|
17:37
japhb joined
|
|||
| Geth | rakudo/fail-gracefully-outside-of-supported-terminal-emulator: 35baad52a5 | ab5tract++ | t/02-rakudo/repl.t Add test for failure of repl-mode=tty outside of TTY |
17:55 | |
| [Coke] | tried 2024.09, 2024.05, no luck so far. Guessing my build config is borked, somehow. | 18:02 | |
| ab5tract | Maybe it actually was the Win11 upgrade after all? | 18:11 | |
| Seems strange tho | |||
| [Coke] | hard to tell, since I haven't been building regularly - and it's not impacting the win builds at release time... | 18:17 | |
| [Coke] sees a /DAO_ASSUME_WIN_98 or something similar fly past. | 18:21 | ||
| jumped releases, but 2023.10 didn't work either. Must be me. Maybe a reinstall of VS. | 18:23 | ||
| ugexe | i think the last version i was able to build on win11 was 2023.03 or something | 18:27 | |
| win11 on arm at least | 18:28 | ||
| maybe try 2023.04 and 2022.12 as i see those are the two non broken versions i have on my windows vm | 18:30 | ||
| [Coke] | already kicked off the VS update, will try those versions. | 18:34 | |
| ugexe++ ab5tract++ | 18:35 | ||
| (oof. installing package 604 of 743) | 18:44 | ||
| nope022.12 dies same place | 19:16 | ||
| nope: 2022.12 dies same place | |||
| updating to vs 2022... | 19:18 | ||
| Geth | App-MoarVM-Debug/main: 7f992bbb19 | (Timo Paulssen)++ | lib/App/MoarVM/Debug.rakumod Fix holding down enter with "step" This also makes the prompt show up after the step finishes if it finishes quickly instead of slipping in between the request and response. ... (7 more lines) |
19:27 | |
| patrickb | The CI pipeline that compiles the Windows builds every month is working reliably. So in general the build is working on Windows. | 19:46 | |
| ugexe | does it compile arm builds for windows? | 19:53 | |
| my issues are likely related to that | |||
| Geth | Crane/main: baeaebe3c3 | (Elizabeth Mattijsen)++ | 78 files Prepare for transfer to Raku Community Modules |
19:56 | |
| Crane/main: 1171f81c12 | (Elizabeth Mattijsen)++ | 2 files 0.1.2 |
20:02 | ||
| ab5tract | patrickb: I would argue from the 119 commits in R#5642 tells a different story | 20:19 | |
| linkable6 | R#5642 [open]: github.com/rakudo/rakudo/pull/5642 Try improving the azure pipeline (focus on windows builds) | ||
| ab5tract | the CI pipeline that compiles Windows successfully is more an exception to the rule in my experience | 20:20 | |
| [Coke] | OK, doing another build attempt on 2022.12 with VS2022 | 20:24 | |
| ab5tract | also: R#5566. | 20:27 | |
| 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?! | ||
| ab5tract | [Coke]: if you're feeling wild, you can try with this MoarVM PR: github.com/MoarVM/MoarVM/pull/1852 | 20:28 | |
| [Coke] | wouldn't I want a working build first? | 20:29 | |
| or do you suspect that might fix the issue? | |||
| heh. | 20:36 | ||
| I got past stage start! ... and then died on stage optimize. | 20:37 | ||
| patrickb | The pipeline that compiles the precomp builds for every release is also on azure, but a separate pipeline from the one that runs on every commit. | 20:40 | |
| github.com/rakudo/rakudo/blob/0291...s.yml#L239 This is the precomp pipeline. | 20:42 | ||
| ugexe: Currently it's not doing ARM. | 20:43 | ||
| ab5tract | patrickb: my point is that there success of that CI is not indicative of building on Windows being “generally” successful | ||
| patrickb | ugexe: Do you think it's worth it already? | ||
| ab5tract | Considering it’s the only known success story at the moment | ||
| patrickb | Agreed | 20:44 | |
| ab5tract | [Coke]: that MR is intended to resolve a diagnosed Windows compilation issue | ||
| patrickb | Given I just started working on getting the terminal stack on Windows working I'll soon be hitting the same issues... | ||
| Geth | Config-TOML/main: da642b4c11 | (Elizabeth Mattijsen)++ | 59 files Prepare for transfer to Raku Community Modules |
||
| ab5tract | Whether it solves *your* issue would be useful to know | 20:45 | |
| But I also only proposed it based on your current $*WILD value :) | |||
| [Coke] | ab5tract: will check | 20:46 | |
| ugexe | ab5tract: my appveyor builds always work for zef | ||
| so another success that is reproducible | 20:47 | ||
| ab5tract | patrickb: indeed. I’m also looking forward to hearing how it goes for Bas for Git | ||
| ugexe: true I forget about that | |||
| IIIRC that also uses 2019, right? | 20:48 | ||
| Geth | Config-TOML/main: e11faf586a | (Elizabeth Mattijsen)++ | 2 files 0.1.3 |
||
| [Coke] | trying 2024.10 rakudo with default nqp and that moarvm branch | 20:49 | |
| ugexe | it uses Visual Studio 2022 | ||
| not sure if that is windows 2019 or not | 20:50 | ||
| patrickb: i dunno if its worth it probably not. i only use it because i couldnt run x86 windows on a m2 | 20:51 | ||
| yeah it does appear appveyor is using Windows Server 2019 | 20:52 | ||
| timo | github.com/raku-community-modules/...2884253835 - is this just "windows doesn't like long paths"? | 20:53 | |
| lizmat | perhaps, but maybe it's the auth error [Coke] saw earlier today? | 20:54 | |
| hidden inside another error? | |||
| afk& | 20:55 | ||
| timo | i have zero clue how to figure that out | ||
| ab5tract | I thought we had the long path problem in Windows fixed :S | 20:56 | |
| timo | no idea | 20:59 | |
| [Coke] | ab5tract: no change, 2024.10 dies the same way | 21:04 | |
| fixed? no | |||
| there was a partial PR that I don't think was applied. | |||
| ugexe | timo: it doesnt appear too long but im not entirely sure. zef/raku does not see the file, so i would probably try to download the file with curl similar to how zef does and see if that works | 21:05 | |
| github.com/ugexe/zef/blob/45f3ac76...#L108-L111 | |||
| curl.exe '-L', '-z', $save-as.absolute, '-o', $save-as.absolute, $uri | 21:06 | ||
| ab5tract | [Coke]: just double checking that you bumped MOAR_REVISION in nqp, comitted that, and then bumped the NQP_REVISION in rakudo | 21:08 | |
| though since that MR is still a draft, maybe timo++ hasn't fully worked out the kinks | 21:14 | ||
| [Coke] | I did a top level configure with gen-nqp, gen-moar=<branch name> | 21:19 | |
| (starting at HEAD on rakudo) | 21:20 | ||
| patrickb | timo, ugexe: I'm going to be working mostly on Windows stuff in Rakudo the next few weeks and thus will have a Windows 11 machine running. If there is anything I can do to help push forward with the long path PR or the JIT/RTL PR. Please ping me. | 21:21 | |
| ab5tract | I've never used gen-moar=branch-name | 21:23 | |
| that sounds handy, if it works | |||
| tried it and it doesn't work OOB | 21:38 | ||
| gist.github.com/ab5tract/eb6f2ffbe...ae73d15d59 | |||
| maybe it works more reliably for others but I don't think I'll trust it | 21:43 | ||
| The first example in that gist (without-force-rebuild) is obviously wrong because it didn't recompile MoarVM | 22:31 | ||
| timo | patrickb: it'd be cool if you could try slotting github.com/GlinkieGamesInc/longjmp_win64 into moar and see if that fixes jit on windows for newer MSVCs. i unfortunately ran out of steam before i could try that | 22:43 | |
| ab5tract: i think it would have worked if the reprotest_tile_compiler branch was rebased onto a newer moarvm version, or alternatively if you --gen-nqp=some_older_version, really anything that gives you a MOAR_VERSION that is older than what's in the branch | 22:45 | ||
| ab5tract | ah, that makes sense. seems like more work than managing the revisions myself, but that does explain why it failed | 22:46 | |
| timo | i really really want a flag or environment variable that lets me tell the "your version is too old" part of configure.pl (which also runs multiple times during compilation, so you're not safe by just skipping the actual Configure.pl step) to please shut up and let me continue | 23:01 | |
|
23:15
sena_kun left
|
|||
| Geth | Config-TOML/main: 7b920e4c49 | (Elizabeth Mattijsen)++ | 19 files Make sure tests use -I. logic in fetching modules |
23:25 | |
| Digest-xxHash/main: 231b322fce | (Elizabeth Mattijsen)++ | 14 files Prepare for transfer to Raku Community Modules |
23:49 | ||
| Digest-xxHash/main: 9899e548d3 | (Elizabeth Mattijsen)++ | .github/workflows/linux.yml Fix Linux CI native lib fetching |
23:52 | ||
| Digest-xxHash/main: d7cda3390f | (Elizabeth Mattijsen)++ | .github/workflows/linux.yml Be more specific in native lib version for linux Apparently it installs 0.8.1.1 instead of 0.8.2 |
23:54 | ||
| lizmat | meh | 23:55 | |
| sleep& | |||