timo i think the makefile rule for NQPP5QRegex might be not 100% correct, it seems to be re-running relatively often in the ci jobs 02:12
02:27 MasterDuke joined
MasterDuke timo: 0241916bea50f967dc99398f3de20354f7990a51 might be relevant 02:27
timo linkable6: 0241916bea50f967dc99398f3de20354f7990a51
linkable6 (2024-03-28) github.com/Raku/nqp/commit/0241916bea Revert "Merge pull request #815 from MasterDuke17/second_attempt_at_not_compiling_P5QREGEX_every_time_tests_are_run"
releasable6 Next release in ≈6 days and ≈15 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 03:00
timo oh lord
03:25 MasterDuke left 07:12 sena_kun joined 08:26 sena_kun left
Geth PrettyDump/main: d270f45dcc | (Elizabeth Mattijsen)++ | 54 files
CI check for 1.2.2 release
 13:30
PrettyDump/main: 1763ff3dda | (Elizabeth Mattijsen)++ | 2 files
1.2.2
 13:32
sjn q 13:48
timo is there something wrong with the pod 2 markdown thing that generated that readme? "=item List\n=item Array\n=item Pair" turned into "\n * List\n\n * Array\n * Pair" and that generates an "<ul><li><p>List</p></li><li><p>Array</p></li><li><p>Pair<p></li>..." which i guess doesn't look wrong but it feels strange to have the extra p in there 14:13
also wow that looks like a lot of work went into that commit with an innocent sounding description 14:14
interesting, what is run-tests all about? 14:16
14:18 japhb left 14:26 japhb joined
lizmat it's basically a smarter way to run tests with less information if all is well, and more if things go wrong 14:28
timo: the markdown is generated by App::Mi6 14:29
timo cool. should that go in a shared location somewhere? maybe become a module installable with zef in the CI scripts even? 14:30
ugexe for a CI i would just always run with more information. less information if all is well isn't as much of a benefit for CI since you only check if when all is not well 14:31
i dont remember the last time i checked a green CI for its output for instance 14:32
for zef itself i imagined it could write all its output to a file instead of stdout/stderr, and then effectively use that file to source what it outputs to stdout/stderr. that way if you are running e.g. zef install . without --debug you could still check some output log file for what went wrong. alas my tuits have been lacking lately 14:35
lizmat timo: fwiw, I also use run-tests locally,
in any case, "run-tests" will produce --ll-exception backtraces on execution errors and show them 14:36
and all output on test errors
timo sounds useful. i'm just thinking you don't have to copy it to every library if you make a change :D 14:39
ugexe if there are not any differences from using prove6 and setting e.g. RAKUDO_OPTS=--ll-exception a more idiomatic approach might be to use that. i believe it is included in most of the prebuild binaries and hence are in most peoples CI already. although that wouldn't scratch your local development workflow since it would need to be installed for that 14:41
if there are differences then prove6 might be the best place to centralize such logic 14:42
although i imagine that would require much more effort :o
then again i have to contradict myself because using prove6 + trying to install (which I always recommend) would precompile twice 14:48
i guess having prove6 installed but having zef run the test avoids that, but 🤷 14:50
ultimately these are just optimization nits that really only torture those who are aware of their existence 14:52
ugexe's basilisk 14:54
timo phew, the templates we have for our Makefile stuff are a lot to get used to 15:02
ab5tract yeah... 15:20
I went in there to try and remove / modify the debugger "executables" 15:21
but then... I didn't :) 15:22
that tangentially reminds me that I need to submit the belated PRs for supporting `zig` as a compiler for moarvm 15:39
I also think it might be useful to make a `Compiler::Zig` package that would allow Raku modules to ensure that they have a C compiler available 15:42
timo possibly easier to set up than an msvc or mingw on windows huh? 15:48
[Coke] msvc when you're at the desktop isn't too bad. 15:50
Not sure how it would fare automated.
[Coke] just thanks everybody for being pretty cool. 15:56
jdv im not cool or pretty but i am part of everybody. 16:03
ab5tract timo: should be considerably so, yeah 16:05
that's the theory of it, at least. though I think I read somewhere that they are prematurely moving to rip out the embedded llvm
that doesn't make any sense to me, so I'm assuming they won't actually do that until they've reached some sort of Serious Parity 16:06
s/llvm/clang/ 16:08
msvc isn't so bad when you already have it installed 16:12
I don't suppose someone has a BNF of NQP stashed away somewhere, by any chance? 16:26
[Tux] Rakudo v2024.08-62-gba303f4a7 (v6.d) on MoarVM 2024.08-10-gb7750ec26
csv-ip5xs0.270 - 0.271
csv-ip5xs-201.145 - 1.469
csv-parser1.487 - 1.512
csv-test-xs-200.142 - 0.142
test1.850 - 1.875
test-t0.405 - 0.415
test-t --race0.266 - 0.270
test-t-204.846 - 4.987
test-t-20 --race1.228 - 1.258
 16:28
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
Geth nqp/reproducible_build_improvement: 85745d05c0 | (Timo Paulssen)++ | tools/build/gen-version.pl
Sort files by name before hashing into source-digest
 17:38
nqp: timo++ created pull request #826:
Sort files by name before hashing into source-digest		 17:41
timo this includes changes to perl5 code, which is something i am only barely competent at
so i'd like someone to check if i did it right or maybe i missed something 17:42
Geth nqp/reproducible_build_improvement: a492243065 | (Timo Paulssen)++ | 2 files
Bring in reproducibility fixes from debian patches
 17:48
ab5tract timo: it looks good to me, but when in doubt you can always create named subs and pass them by reference via &name 18:07
but if it's already working, I doubt it's necessary 18:08
timo i tried to pass &sort but that said it couldn't find main::&sort 18:15
\&sort i guess
appreciate it :) 18:16
ab5tract ah, right, there's an extra bit needed there 18:22
`sub { return unless /\.nqp\z/; $sha->addfile($_) }` hurts my brain 18:26
I'm not sure how the `@_` turns into `$_` here
if it were `sub { for (@_) { return unless /\.nqp\z/; $sha->addfile($_) } }` I could see it 18:27
timo find iterates that sub 18:29
it's only a single file entry each time
ab5tract if it works, it works 18:43
but even for single argument subs, It was always `sub foo { my $arg = shift; ...}` or sub foo { my ($arg) = @_; ... }` 18:45
there's obviously an implicit something or other here though
perl -wE 'use v5.34; sub foo { return unless /foo/; say $_ }; foo "foo"' 18:49
Use of uninitialized value $_ in pattern match (m//) at -e line 1.
timo use 5.008; though? 18:51
ab5tract dear lord
timo so in nqp we generate a nqp.c that is compiled and installed, and it has some argv that it passes, and those argv actually point at the build path rather than the target path, that's clearly not right 18:52
ab5tract there's no pragma for that lang level. perl being perl, it doesn't complain when you give it an invalid version to use :( 18:53
but there isn't a system in the world that can reasonably run raku that is using such an ancient perl
anyway, you should get ancient perl when you *don't* specify a language revision, and that code snippet still fails 18:54
shifting onto `$_` at the start of the sub works though 18:56
> perl -e 'use 5.008; sub foo { return unless /foo/; print $_ }; foo "foo"' ===> (no output) 18:57
coleman I don't have Meson working yet but I still think we'd be better served by something like it long term m.youtube.com/watch?v=vua1zU9TZcc&...IHIyZDI%3D 19:03
ab5tract (I was using v5.008 before, then tried v4.008, leading to my comment about not complaints on invalid versions)
coleman sorry this github.com/MoarVM/MoarVM/issues/1795
Build systems are super hard 19:04
ab5tract coleman++
coleman I am only in MoarVM right now
Geth nqp/reproducible_build_improvement: 7998519fa7 | (Timo Paulssen)++ | tools/templates/moar/Makefile.in
BASE_DIR does not belong in moar_argc for installed runner
ab5tract yeah, indeed. but especially when you are writing semi-hateful Perl. `shift`-ing off of @ARGV? for rely?
*real
coleman I'm not anti-perl but I confess I have a harder time with it than even C++ build systems ha ha 19:05
I think a true transition will involve both. I took a while with Meson last weekend and our header includes were hard to get right 19:06
ab5tract Perl can be totally fine, it's cowboy-ing needlessly that leads to annoying legacy code 19:07
also stubbornly sticking to 5.008 when there's no Linux system in the world not on a 2.4 era kernel running that version
maybe even 2.2 19:08
coleman Well, what's interesting is the build system "generator" aspect. So we are doing autotools-esque things in Perl. It's totally necessary right now but our C deps are not that extreme
github.com/dontlaugh/MoarVM/commits/mesonbuild/ is the branch I've been hacking on
but I will need to back it out because I started going a little bananas
I will try again with what I've learned at some point. But my next attempt will probably take a different approach: creating an ALTERNATIVE main that links to a libmoar.so built with the existing Perl 19:10
ab5tract re: 5.008, the number of systems that *cannot update to a newer Perl* and *can run Raku* has got to be zero 19:11
timo i'm not holding on to 5.008 at all, it's just what's in that script at the moment, and another one at least
coleman Then, ensure the executables are compatible, and then slowly morph the project structure, moving more and more dependencies into Meson
ab5tract no no, I didn't mean to implicate you in that timo
timo haha
ab5tract it's just crazy how often you see this 5.008 stuff 19:12
coleman Our build is actually pretty nifty. It's just a free-Jazz riff on a C project.
ab5tract nqp-configure is a tuba solo
timo apparently the value that's in base_dir and exec_name may not even matter at all 19:13
ab5tract fart after fart ;)
coleman And SO much has changed since MoarVM was started
lol okay
ab5tract it works though, but the low notes can cause shaky bowels 19:14
(Sorry, I'll veer back off the scatological road before it's too late)
timo ... it's not using the .o file that it's generating there 19:15
coleman timo: is there a build error log you can link to that's troubling you at the moment
or are you down a rabbit hole at the moment 19:16
ab5tract I don't think I've ever seen a perl file that ends with `0;`
Geth nqp/reproducible_build_improvement: 62cc03482b | (Timo Paulssen)++ | tools/templates/moar/Makefile.in
BASE_DIR does not belong in moar_argc for installed runner
 19:19
timo oh, just a little rabbit hole exploration
salsa.debian.org/timotimo-guest/nq...bs/6309201
the nqp package is not reproducible because the path to the build directory ended up in one of the binaries 19:20
turns out it was for a bad reason
ab5tract ahh, so the mystery is solved: from the perldoc -- "The wanted function takes no arguments but rather does its work through
a collection of variables."
so it's literally using a `$_` from the calling scope 19:21
this part is especially curious: "its return value is ignored"
timo right, in this code we have here we just use it as a side effect 19:22
ab5tract in that case it could be rewritten as `{ /\.nqp\z/ and $sha->addfile($_) }` 19:28
tellable6__ 2024-09-20T19:27:47Z #raku <tbrowder> ab5tract i am using a module sub dir as a test bed and it will never be officially part of the module. maybe not a good practice, but many of my published modules have such
timo moar taking the CFLAGS it's called with into its own config that it spits back out when you ask it to is a problem with reproducible builds. either we have debug symbols with filenames that have the changing stuff in them, or we supply -ffile-prefix-map to strip those parts of the path out, but the path goes into the CFLAGS inside moar's config 20:18
coleman if those are only needed at build-time can they be externalized into some kind of options.txt file 20:34
timo aw damn 21:14
we put CFLAGS and CPPFLAGS directly into @cflags so just filtering out elements that start with -ffile-prefix-map doesn't work when there are some other flags in there as well, and now ... do i have to implement something like shell splitting here? ugh. 21:15
save me, somebody, anybody >_< 21:16
ugexe just delete em 21:19
21:21 [Coke] left
timo i realize i know barely how to write perl5 on a good day 21:27
21:30 sena_kun joined
ab5tract I find I got rusty quite quickly 21:31
after not using it daily, I mean
but hacking on old scripts is different than writing new ones, of course. you never know what blind alley back-in-the-day Perl will lead you down 21:32
actually, it's a good thing that `use 5.008;` is a no-op 21:37
because defined-or (`//`) did not exist then - www.effectiveperlprogramming.com/2...-operator/ 21:38
timo salsa.debian.org/perl6-team/moarvm...t-in.patch can you tell me if this is bad or worse? 21:43
oh i spent so much time getting the flags out into the separate array that i forgot to merge it back into the flags used by the compiler 21:46
ab5tract looks fine, though I'd un-indent line 30. and it's a matter of tast, but if I'm doing multi-line and/or mutation in a map, I'll assign $_ to a scalar 21:47
coleman looks good. How long will they have to carry a patch?
ugexe i think you meant for `$_ =~ s/$fullflag//;` to be `$_ =~ s/$fullflag//r;` since you are returning the result of the map
coleman now we're mob programmin' 21:48
ab5tract another matter of taste, if you stick with `$_` it's actually a bit more common to use the implicit regex form
`$_ =~ /foo/` has a weird look to it. I usually go the direction of `$named =~ /foo/` over `/foo/`, but weirdly enough I prefer the latter over `$_ =~ /foo/` 21:50
timo so without the =~ entirely?
ab5tract yeah
ugexe disregard my comment actually... the result of the map is the following $_ not the `$_ =~ s/$fullflag//;` 21:51
timo i think this change ought to be in upstream moarvm as well. also the one that makes the tile compiler deterministic
what's more important is that moar fails to create something that runs when building for i386 21:52
that definitely needs fixed for 2024.09, perhaps even a 2024.08.1?
ab5tract yeah, definitely. there is an issue from an opensuse package maintainer about determinism as well
timo very strange that only one BSD user has noticed this so far, and me on the debian builders
ab5tract i*3*86 ?
timo well, their name for 686 i hope 21:53
ab5tract :)
timo i do believe linux already dropped 386 or maybe already 486?
ab5tract oh, one last suggestion would be to remove line 20 and puth the uniq call on line 30 21:54
which would also mean no need for a uniq on line 32 21:57
those would reduce thinking overhead in the future imo
or just do the uniq on 32 only, if that suits better
timo something smart to remove empty entries from cflags after removing the fullflag from the string? 22:00
hm. i think the regex breaks with code where there's a - in the path 22:01
that's very bad actually
i'm not sure how exactly someone would expect to pass a -ffile-prefix-map with a file that has spaces in it through the CFLAGS env var 22:02
would there be quotation marks, would there be backslashes 22:04
time to bring urlencoding to the commandline
try.diffoscope.org/zsxsbqysttcs wow 22:05
ugexe would it ever contain like "C:\Program Files\rakudo" or some such on windows? 22:16
timo somehow it was working anyway with paths that have - in it
nothing in our code would currently pass ffile-prefix-map, you'd have to be doing it yourself 22:17
but you would probably not be building your rakudo inside of Program Files in the first place. maybe a different folder with spaces though
ugexe C:\Users\First Last\whatever
regardless i imagine some other part of the build system would blow up on spaces in the path 22:18
ab5tract off 22:19
oops ^^
timo: you can do a grep { $_ } and it will remove empty entries 22:20
just stick it to the left of the map 22:24
22:38 sena_kun left
timo ======================= 22:40
Reproduction successful 22:41
=======================
No differences in ./*.*deb
ab5tract \o/ 22:46
timo that is only moarvm, of course. 22:51
also, i now have locally reproduced the moar crash on i386
ab5tract did you pull out an old 12lb Compaq laptop for that? :) 22:56
timo podman did all the heavy lifting 22:58
releasable6 Next release in ≈5 days and ≈19 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 23:00
ab5tract ah man, I was hoping you were downloading over ethernet-10 on a pcmcia :)
one thing about old, thick notebooks is that they usually have killer keyboards 23:07
23:17 [Coke] joined
coleman timo you are a hero 23:18
timo ok, the code doesn't fail with the patch i already put in moar master, the one that split pointers into .any and .any_ptr 23:22
so not really reproducing the issue the other user saw
so, point release just days before the next real release, or debian gets a patch from upstream backported for a few days? 23:24
ab5tract I think the former is fair, personally 23:25
but playing it safe also has its advantages 23:26
timo salsa gitlab runners are keeping me waiting :( 23:29

Powered by Cro and the Raku® Programming Language.

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

Thank you!