lizmat looks ok here, including installing my personal batch of modules 00:00
so a good moment to get some shuteye :-)
&
[Coke] c: 63bc8b839 pi.say 00:01
committable6 [Coke], ¦63bc8b8: «Cannot find this revision (did you mean “9233a89”?)»
[Coke] Will have to wait until the build finishes, then I can do it
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
09:38 finanalyst left
patrickb lizmat: Thank you for doing bumps and merge. 09:47
lizmat yw :-)
disbot6 <melezhik.> patrickb: would you like to run tests on head ? 11:07
patrickb That was Coke's call as well, to run post that merge, right? 11:08
disbot6 <melezhik.> Yeah . Anyway . Whenever agent is available we can just run o10r 11:30
patrickb give me an hour or so 11:33
11:39 librasteve_ joined
disbot6 <melezhik.> Sure , no rush . Just thought this could be good opportunity to check 12:01
<melezhik.> What is pty in two words btw ? 12:04
<melezhik.> “The term "pty proc" generally refers to processes running within a pseudo-terminal (PTY) in Unix-like operating systems, or potentially the /proc filesystem entries related to PTYs. A PTY is a virtual device that emulates a physical terminal, enabling communication between a process (like a shell) and a program (like a terminal emulator or SSH client). “ AI tells
<melezhik.> stackoverflow.com/a/4426291 12:06
patrickb melezhik: There'll be an advent post about PTYs on the 21st. :-) 12:20
disbot6 <melezhik.> Patrick++ then we indeed to check the changes on brownie 😄 13:03
13:17 ShimmerFairy left 13:20 ShimmerFairy joined
patrickb my agent is running 13:43
disbot6 <melezhik.> Ok 13:45
<melezhik.> So do we run for the latest commit , right ? 13:46
13:46 melezhik joined
melezhik brw.sparrowhub.io/report/brw-orch/6...ecentData/ - run new round for the latest commit 13:49
[Coke] c: 63bc8b839 pi.say 14:03
committable6 [Coke], ¦63bc8b8: «3.141592653589793␤»
patrickb I did a git pull right before run.sh 14:06
melezhik Yep. Testing 3000 modules against Rakudo version: sha (63bc8b839300eff9f13bac2cae62bd108207b510) 14:07
[Coke] blinning 14:17
melezhik || TESTS STAT: rakudo_version: sha | time: 37m | tests total: 2387 | finished tests: 581 | sent to queue: dist=10 / redist=0 | agents cnt: 1 14:26
Blining AND browning )))
[Coke] ⏳ 96 out of 2389 modules processed (4.01%) 14:33
melezhik patrickb: can you please check if RW_AGENT_CAP_INSTALL_FROM_SOURCE_FORCE is set or not on agent ? 14:39
env|grep BRW_AGENT_CAP_INSTALL_FROM_SOURCE_FORCE 14:40
I removed it from default in run.sh cause I need to test exactly whateverable Rakudo rather then installed from source 14:41
[Coke] also updated and started brownie again 14:42
melezhik Thanks 🙏 14:44
See some diffs already , not sure why
brw.sparrowhub.io/file_view/brw-rep...DBIish.log
For example
brw.sparrowhub.io/file_view/brw-rep...curity.log this one rings a bell, huh 🤔? 14:45
patrickb melezhik: I've removed that from run 14:48
.sh during the gut pull merge
I can't check what's actually set though because I'm afk atm. 14:49
melezhik Ok. Sounds good 14:51
[Coke] any license gurus here? github.com/raku-multilingual/raku-...LICENSE#L6 has added a copyright line to the license just before: 14:53
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
(this is not the only issue I have with the module, but happened to see this one too)
melezhik Got few modules with tests failed with message “Parse errors: Got line TAP::Unknown<2311773974048> after late plan” not sure what that means 15:03
brw.sparrowhub.io/file_view/brw-rep...Inline.log
This one also is weird brw.sparrowhub.io/file_view/brw-rep...::HTTP.log 15:12
Many failed modules have this TAP Parse errors line
ugexe theoretically that could be related to the pty stuff 15:28
since they work by spawning processes and reading stdout/stderr and parsing that
melezhik Yeah. I am going to rerun those failed tests again . After the round finish . To double check it’s not brownie quirks . But that’s suspicious 15:38
ugexe why does it use `zef test .` to test? 15:43
it should be using zef install .
the old output indeed uses zef install . 15:45
melezhik zef look Foo && zef install . —deps-only && zef test —verbose . gets run only if Foo failed its tests whether during direct installation or indirectly as dependencies. Because zef install Foo never gives details 15:52
ugexe what details does it not give you? why are you not passing --verbose or --debug to zef install like you do for zef test? 15:53
`zef install Foo` might fail its tests due to a precompilation error that isn't exercised by the tests and hence `zef test .` (where . points at Foo) wouldnt fail 15:56
16:05 melezhik2 joined
melezhik2 I did not say I run set test instradc 16:06
Instead of zen install
I only run mentioned chain of commands if Foo doesn’t pass its unit tests during installation 16:07
as for zef -debug or -verbose flags for zef install command on my experience they don’t provide details of TAP report , this is why I run zef test -verbose . 16:09
If you know the better way I will consider it 16:10
16:10 melezhik2 left 16:13 melezhik2 joined 16:18 melezhik2 left
ugexe i just told you the better way, but you're saying your experience is different 16:24
only one of us can be right 16:25
so it might be worth reevaluating your experience to see if it doesn't align with what i just said 16:26
16:43 melezhik_ joined 16:47 melezhik_ left
melezhik Nick I feel like sometimes you jump into conclusions on my some my statements too fast , please don’t , with all respect if you sometimes slow down on your judgement it will help to find solution  instead of arguing over ver phrasing , etc, this is what I mean by saying “zef install Doublephone —verbose” does not give me ( TAP report ) details - looks at this gist as an example - first block is what I want report looks 16:50
like ( I use prove6 t/ —verbose for that , but I believe I saw the same results when I used zef test —verbose . , but just not for every module , and maybe this also  depends on Rakudo version , I dunno , need to investigate ) , the second block is output from zef install Doublephone —verbose which misses those details which are essential at least for me in context of brownie )
gist.github.com/melezhik/24ee374b2...e861095371 16:51
ugexe did you try --debug like i suggested? 17:12
the reason i can so often jump to conclusions is because i have a strong understanding of the framework was build on which also used consistency as one of its primary goals. so when users say something that describes behavior that is inconsistent with my mental model of the framework it is usually a strong indicator of user error 17:14
typically i think my conclusions are correct 17:16
disbot6 <melezhik.> That’s ok ) nobody criticize your well done work , most of the time when I write something about zef I am looking for solutions of my tasks not for picking holes , even potential bugs which I occasionally find the idea is to make things better 17:23
17:41 melezhik_ joined 17:45 melezhik_ left 17:46 melezhik2 joined
melezhik2 ok, looks like zef --debug does the trick , the reasons I did not consider it before, as it produce too much other verbose data which I don't need if I use via zef install --debug Foo, but using it with zef test --debug . ( when all deps are already installed ) is probably ok, thanks 17:46
I am still not sure why some module produce all TAP details when are tested via zef --verbose . while others don't 17:47
if this is something that might be governed on module side? 17:48
as a suggestion it'd be good imho to gave some sort of flag of env var that only increases verbosity of TAP report, not other details for zef 17:50
for me as a someone who tests thousands of Raku modules this would be very helpful in troubleshooting why modules fail 17:51
but current workaround is ok too )
patrickb: I am again have this phantom of "your agent does not work correctly" ))) I dunno but when I rerun failed modules on my agent ( the same Rakudo version ) they pass, as on [Coke]: agent too ), once you've got an access to your agent please run `env|grep BRW` inside id, brownie reports show that you probably have Rakudo version installed 17:54
from source code, not downloaded from whateverable, I am not 100% sure though , thanks
As an example - gist.github.com/melezhik/c800b01dd...7bf2935d41 17:57
cc patrickb:
[Coke] ⏳ 1113 out of 2389 modules processed (46.58%) 18:05
ugexe that example is proof of why you should just always use --debug 18:06
on the output where --debug was used there is `[Hashids] Testing with plugin: Zef::Service::Shell::Test`
for the other output no such line exists, but based on the output of a test summary it presumably uses Zef::Service::TAP 18:07
18:10 melezhik2 left
ugexe i think you need to decide if you want to use TAP::Harness during testing. if yes it needs to always be installed. then you need to ensure that is the only way tests are run by disabling the other testers in config or via `--/raku-test`. Or if you want to test everything without using TAP::Harness then force that by passing `--/tap-harness`. Currently zef will prefer TAP::Harness if it is 18:10
installed, otherwise it uses Zef::Service::Shell::Test
melezhik Ok. I get it. But main question why is patrickb agent has different setup for zef then mine and [Coke] agent . The only (?) possible question for that would be it installs Rakudo and zef from source code instead of using whateverable distro 18:19
[Coke] "if installed" - maybe he has more modules installed on his setup? 18:24
melezhik Yeah … [Coke] could you please pull the latest commit and restart agent ? I added —debug on ugexe suggestion . Some modules keep failing on your agent too , debug will gives up more details in TAP report 18:57
brw.sparrowhub.io/report/job.1.report/1770 18:59
Again those TAP related errors
[Coke] done 19:00
19:02 Pixi left 19:11 Pixi joined