|
00:31
apogee_ntv left
00:33
apogee_ntv joined
01:12
apogee_ntv left
01:14
apogee_ntv joined
01:58
apogee_ntv left
03:09
hurufu joined
04:04
hurufu left
04:27
hurufu joined
|
|||
| Geth | rakudo/main: abf53a6061 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 2 files RakuAST: streamline Nodify lookup (#6209) Instead of calling .Nodify with name parts, always call it with a fully qualified class name as a string (minus the RakuAST:: part). This allows a simple cache to be built for these class lookups. Also introduce a .Nodify method in the Grammar to more easily (and recognizable) places where class lookups are done. This appears to take off about 1 second from stage parse of the c setting in RakuAST (33 -> 32 seconds), at least for me. |
08:33 | |
| rakudo/lizmat-my-constant: 261 commits pushed by 7 authors review: github.com/rakudo/rakudo/compare/2...cd4f3930e5 |
09:18 | ||
|
09:33
apogee_ntv joined
09:46
apogee_ntv left
09:47
apogee_ntv joined
11:41
finanalyst joined
12:08
apogee_ntv left
12:09
apogee_ntv joined
12:21
apogee_ntv left
12:22
apogee_ntv joined
|
|||
| Geth | nqp/main: 7b4689531a | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION Bump MoarVM to get mod fix |
13:55 | |
| rakudo/main: 0870b473bb | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION Bump NQP to get mod fix |
14:04 | ||
| nqp/main: cd443ed8d8 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION Bump MoarVM to get large string read fix, timo++ |
14:10 | ||
| lizmat | I think this will help rak going through large files :-) | 14:13 | |
|
14:15
rakkable left,
rakkable joined
|
|||
| Geth | rakudo/main: 20b6c7456f | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION Bump NQP to get large string read fix, timo++ |
14:18 | |
| [Coke] | I'll go ahead and pull the trigger on MoarVM 2026.05.1 | 14:23 | |
| er, press the button | |||
|
14:39
apogee_ntv left
14:41
apogee_ntv joined
|
|||
| [Coke] | El_Che: you can probably try again in about 1m | 14:49 | |
| er, 10m | |||
| MoarVM 2026.05.1 has been cut - its sole purpose is to let the older redhat OS release work, no need to update for anyone else. | 14:57 | ||
| The one commit in there is already on main. | |||
| El_Che: let me know if any issues. | |||
|
15:04
apogee_ntv left
15:07
apogee_ntv joined
15:13
apogee_ntv left
15:14
apogee_ntv joined
15:34
ntv joined
15:35
apogee_ntv left
15:45
ntv left
15:46
apogee_ntv joined
15:51
apogee_ntv left
15:52
apogee_ntv joined
|
|||
| Geth | rakudo/lizmat-8: 4 commits pushed by (Elizabeth Mattijsen)++ | 16:01 | |
| lizmat | ugexe would appreciate some eyes on 6e9b92d53958e786af7 | 16:02 | |
| github.com/rakudo/rakudo/commit/6e...958e786af7 | |||
|
16:26
apogee_ntv left
16:59
apogee_ntv joined
18:00
finanalyst left
18:50
hurufu left
|
|||
| Geth | rakudo/lizmat-8: edaaa8b388 | (Elizabeth Mattijsen)++ | src/Raku/ast/package.rakumod RakuAST: some small changes to go further in setting compilation For some reason, it can't find infix:<,>, but I don't see where that would be needed :-( |
19:29 | |
| patrickb | there won't be a rakudo 2026.05.1, correct? | 22:00 | |
| I'm asking, because the release pipeline works off of the release rakudo files on rakudo.org. | 22:01 | ||
| I can create a custom release that that pulls in moar 2026.05.1 instead, but that's a bit unclean. Any opinions on what's best to do? | 22:03 | ||
| lizmat | it was the idea that there would only be a moarvm point release | 22:05 | |
| as its fix was only for some close to EOL OSes ? | |||
| patrickb | correct. | 22:06 | |
| only concern is that the rakudo release files explicitly list the moar revision to use. I'll change that reference there but will not change the version number. | 22:07 | ||
| I guess no one will care, I just think it's worth a mention that I'll be lying a bit there. | 22:08 | ||
| lizmat | well.. unless you're packaging for such old OSes, you can go by what Rakudo 2026.05 specifies as a NQP/Moar dependency | 22:09 | |
| patrickb | unrelated question, is GitHub.com/Raku/geth the real thing? (Last updated 5 years ago.) | ||
| lizmat checks | 22:10 | ||
|
22:10
Geth left
|
|||
| patrickb | the prebuilt releases that end up on rakudo.org are always built with such old releases. That bug is the reason there is no binary for Linux for 2026.05 there yet. | 22:10 | |
|
22:10
Geth joined
|
|||
| patrickb | s/releases/oses/ | 22:10 | |
| lizmat | yeah, that's where Geth lives | 22:11 | |
|
22:11
Geth left,
Geth joined
|
|||
| lizmat | I have some minor local changes | 22:11 | |
| patrickb | The reason the binary releases use such old oses is because glibc is backwards, but not forwards compatible | 22:12 | |
| i.e. always pick the oldest glibc you want to support when building. | |||
| I upgrade rarely, and always try to support the oldest release of the major distros. | 22:13 | ||
| [Coke] | patrickb: if your previous binaries worked, do not use the new moar. | 22:38 | |
| I thought only el_che reported issues with the binaries they were creating. (and only one of those) | |||
| You can just skip 2026.05.1 if 2026.05 worked for you | 22:39 | ||
| then everything will sync up with 2026.06 next month | |||
| (centos 8, I think was the problem OS) | |||