🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
00:02 reportable6 left 00:03 reportable6 joined
Geth DBIish/rbt.end-of-line: 109ed17d86 | (Rod Taylor)++ | lib/DBDish/StatementHandle.pm6
Add semi-colon to end of non-trivial line.
 00:13
DBIish: 109ed17d86 | (Rod Taylor)++ | lib/DBDish/StatementHandle.pm6
Add semi-colon to end of non-trivial line.
 00:52
DBIish/rbt.sqlite_rows: 2742e84ca3 | (Rod Taylor)++ | 2 files
Warn on rows call in sqlite

Track situations where the value returned may be inaccurate and warn on those usages.
01:02 frost joined 01:31 frost left 01:35 frost joined
Geth DBIish/rbt.sqlite_rows: a431f481a8 | (Rod Taylor)++ | 4 files
Warn on rows call in sqlite

Track situations where the value returned may be inaccurate and warn on those usages.		 01:37
DBIish/rbt.sqlite_rows: 5ef20df9e6 | (Rod Taylor)++ | 4 files
Warn on rows call in sqlite

Track situations where the value returned may be inaccurate and warn on those usages.		 01:43
DBIish: rbt++ created pull request #213:
Warn on rows call in sqlite		 01:51
03:39 committable6 left, bloatable6 left, coverable6 left, squashable6 left, reportable6 left, evalable6 left, linkable6 left, benchable6 left, shareable6 left, quotable6 left, releasable6 left, unicodable6 left, nativecallable6 left, greppable6 left, notable6 left, tellable6 left, sourceable6 left, bisectable6 left, statisfiable6 left 03:40 unicodable6 joined, bloatable6 joined 03:41 linkable6 joined, notable6 joined, bisectable6 joined, benchable6 joined, sourceable6 joined, committable6 joined 03:42 tellable6 joined 04:40 shareable6 joined 04:41 reportable6 joined 04:42 evalable6 joined, squashable6 joined, quotable6 joined 04:43 coverable6 joined 05:40 nativecallable6 joined, greppable6 joined 05:42 statisfiable6 joined 06:02 reportable6 left 06:42 releasable6 joined 07:44 Xliff joined 07:54 patrickb joined
patrickb o/ 07:55
Can we define some next steps wrt new release manager? I think people need some guidance on how to proceed after step 1. "raise your hand". 07:56
People I know about that have showed interest: andinus and jdv. 07:57
sena-kun: Would you be willing to moderate a first "get to know each other and organize meeting"? 08:01
08:04 reportable6 joined 08:22 frost left, frost joined
sena_kun patrickb, o/ 09:21
Hmmmm. 09:22
patrickb Hi!
sena_kun: I don't necessarily want to involve you explicitly. But you were the first person that came to mind. (As the previous release manager you can not only moderate a first get-together, but also answer questions, but I think that's not strictly necessary.) 09:25
sena_kun Hard to reply to be honest. I am not sure what's more there is, other than "Yes, I can spend a day to do it". I can reply questions for sure. 09:27
If we have so many people, say someone can do the moarvm release and someone else can do rakudo release, it's a simple decision.
patrickb I think the most important thing to do is "authorizing" people to be release manager. "Thanks for volunteering. Yes you can take the release manager role. You do have our trust in doing this." 09:28
sena_kun patrickb, to do this what's needed is just committing a change for this section: github.com/rakudo/rakudo/blob/mast...e-releases 09:29
Replace "Be the next" with your nickname and you are officially approved.
patrickb Fine then, that's easy. 09:30
sena_kun IMO meetings and long discussions really over-complicate things, take time instead of just doing it.
E.g. we have a "documentation team", but all people did there was discussing, discussing discussions, discussing discussions about discussions etc. 09:31
patrickb sena_kun: True. But it's also important to respond when people showed interest to do the work. We asked for volunteers, (I know of) two people that responded and said they'd be willing. So now someone (who?) needs to respond to that volunteering. Otherwise I fear nothing will happen. 09:33
jdv, andinus: Thanks for showing interest to be a release manager. There is no formal inauguration process. The most important thing to do is committing a change to this section: github.com/rakudo/rakudo/blob/mast...e-releases to make sure responsibility is clearly defined and duplicate work prevented. 09:35
jdv, andinus: Further more there is enormous freedom of choice in how and when to do a release. So, for example, should the release manager (the one named in the priviously named document) decide to move the release date to a different week day, they have the authorization to do so. 09:39
sena_kun lesson&
patrickb jdv, andinus: sena_kun, the previous release manager, is available to answer questions. 09:41
Should I have missed anyone else that has volunteered as release manager, the above applies to you just as well. 09:45
10:11 discord-raku-bot left 10:12 discord-raku-bot joined
sena_kun patrickb, agreed, it's just that nobody except maettu yesterday contacted me directly IIRC. 10:33
patrickb Ah. We should have probably been more clear in the weekly. It only said to speak up in this channel. Stating to contact you directy might have been better. 10:37
lizmat had not understoof that it was ok to contact sena_kun directly 10:44
sena_kun No problem, we cleared it up anyway I guess? 10:51
lizmat I hope so :-) 10:55
12:02 reportable6 left 13:43 frost left
jdv since nobody else seems to be taking action I'll give it a go and we can sort it better in time i guess if desired 14:35
sena_kun jdv++ 14:40
jdv is there a list of pre-reqs or should i just read the release guides and run into stuff and discover it that way? ... 14:41
lizmat I think the release guide gives you a pretty good idea? 14:43
14:44 dogbert17 joined
jdv sounds good 14:44
i imagine i'd need commit bits on some more repos? i think i only have a commit bit on nqp and roast. 14:51
also, i'd hazard a guess that 12/4 isn't gonna be realistic. how about this time we'll just say it'll happen this month:) 14:52
lizmat that'd be fine with me :-) 14:55
releasable6 Next release in ≈4 days and ≈3 hours. 4 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 15:00
patrickb Wow! It looks like we have a 2021.12 releasemanager! jdv: Many thanks for picking up the torch! 15:01
15:05 reportable6 joined
sena_kun I wouldn't say it is not realistic, but it depends on Blin results more than something else. 15:07
jdv, from the top of my head "pre-reqs" is 1)to have some nice gpg key you own around; 2)to setup git to sign your commits. 15:08
jdv, also how good is your hardware?
sena_kun goes afk until Altai-man nick is available 15:09
jdv my hw is ancient but i ran blin a while ago - i think it was done in <2.5h iirc 15:11
i don't believe i have a "nice" gpg key. i guess i'll set one up. 15:14
timo there's surely a tool that lets you choose what short key id you want 15:26
at the cost of some cpu (or ideally gpu probably) time
15:41 Altai-man joined
Altai-man jdv, not sure anything doing a run in 2.5h can be counted as "ancient", heh. 15:42
15:44 melezhik joined
Altai-man jdv, wrt "rights to commit" - do you plan to make a moarvm release as well? 15:48
jdv maybe. why do you ask? 15:50
Altai-man jdv, it's a pretty important bit, as it decides whether you do both or we need one more person. 15:51
jdv oh, i thought there was an issue with it that you were infering 15:55
yes, sure.
Altai-man aah, well, there is also the fact that you need to commit to moarvm to do its release. :)
jdv timo: do you know of one? 15:56
Altai-man OTOH the whole process can be done via PRs now and it's not necessary to commit directly.
jdv whatever is easiest i guess 15:57
Altai-man github.com/MoarVM/MoarVM/pull/1576 and github.com/rakudo/rakudo/pull/4529 so both are done via PRs now. 15:59
vrurg PRs make RM dependent on others good will. Usually it's not a problem, but might cause some delays if nobody is available to merge the PR.
Altai-man agreed, plus there is a need to push tags and create releases. 16:00
timo i've used git-vanity before to get a git ommit to have a hash that starts with the haraters i want
but i haven't used any tool to do that with gpg keys
Altai-man which cannot be done with a PR, so it's just that it's cleaner this way.
timo there's a post that says you can only sensibly get a vanity key in a reasonable timeframe (using cpu at least) because you need to reduce input entropy amount or else it'll take weeks 16:04
16:04 andinus joined
Altai-man just follow docs.github.com/en/authentication/...ng-commits and you should be fine. 16:07
jdv thanks. i have some other things to attend to - bbl. 16:08
16:44 japhb left, lucs_ left, bartolin_ left 16:45 lucs joined 16:46 japhb joined, bartolin joined 16:47 squashable6 left 16:58 patrickb left 17:00 patrickb joined
[Coke] cla? 17:07
crap, was hoping a bot had saved the URL for that.
Altai-man notable6, CLA 17:08
notable6 Altai-man, 1 note: gist.github.com/f631025ceff43aaf0d...5e4e69d630
Altai-man ^^
[Coke] for jdv when he gets back - will need to fill that out to get a rakudo commit bit. 17:09
17:26 Altai-man left 18:02 reportable6 left 18:04 reportable6 joined
ugexe so `raku -e 'shell("ls")'` is enough to freeze on Monterey 90% o the time 20:26
lizmat wow 20:27
so that feels like a libuv issue then to me
ugexe yeah, but if it was i would also have expected node to have a similar issue 20:28
lizmat what version is node using then?
ugexe what i mean is someone already mentioned updating libuv for raku and having the same issue 20:29
so even if node was on a recent libuv i'd expect the problem to still exist
lizmat I see
afk& 20:31
21:01 p6steve joined
ugexe the lldb and gdb runners didn't work either when i was looking at this either 21:05
21:11 p6steve left
ugexe seems like the issue might also occur when installing rakudo... stuck on `+++ Preparing installation` 21:13
vrurg Is it all about Intel or M1 versions of mac? 21:15
ugexe this is occuring on an intel, and most of the reports ive seen are m1 so i dont think its related to arch
specific to Monterey
vrurg Ok, so I stick to Big Sur in the meanwhile. Thanks! 21:16
ugexe github.com/rakudo/rakudo/blob/ad1f...c.pm6#L187
that seems to be where its getting stuck 21:17
21:24 p6steve joined 21:29 p6steve left
ugexe github.com/rakudo/rakudo/blob/10c3...c.pm6#L357 sometimes does not get fired 21:48
21:56 squashable6 joined 22:01 [Coke] left
ugexe m: use nqp; say nqp::hash().DUMP 22:02
camelia No such method 'DUMP' for invocant of type 'BOOTHash'. Did you mean
any of these: 'DUMP', 'Num', 'sum'?
in block <unit> at <tmp> line 1
22:05 [Coke] joined
Geth nqp/Xliff-patch-1: 18d3d891a9 | Xliff++ (committed using GitHub Web editor) | tools/lib/NQP/Config/NQP.pm
- Allows the proper use of --no-optimize in --moar-option

Previously, even if --moar-option="--no-optimize" was used, the "--optimize" switch was still added to MoarVM's invocation of ./Configure.pl.
This patch addresses that issue.		 22:38
nqp: Xliff++ created pull request #750:
- Allows the proper use of --no-optimize in --moar-option
Xliff Pls review. 22:39
23:05 patrickb left

Powered by Cro and the Raku® Programming Language.

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

Thank you!