🦋 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.
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.
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
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
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
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
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
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
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
Altai-man jdv, not sure anything doing a run in 2.5h can be counted as "ancient", heh. 15:42
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
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
[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
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
ugexe the lldb and gdb runners didn't work either when i was looking at this either 21:05
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
ugexe github.com/rakudo/rakudo/blob/10c3...c.pm6#L357 sometimes does not get fired 21:48
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
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!