00:05 sena_kun left 00:06 MasterDuke left
Geth rakudo: patzim++ created pull request #3321:
Rename PERL6_HOME to RAKUDO_HOME		 00:06
00:08 patrickb left 00:36 lucasb left
Xliff my ($a, $b) = (0, 4); say ($a, $b)».so 00:38
evalable6 (False True)
01:35 Xliff left
Geth nqp: vrurg++ created pull request #587:
Support for the new way of doing silent/verbose builds		 02:36
rakudo/configure-rebuild-all: 15255b0a91 | (Vadim Belman)++ | 3 files
Add --force-rebuild command line option

Forces rebuild of all required components like NQP and, possibly, MoarVM. --force-rebuild tries to pretend we're building in an empty or almost empty environment. I.e.:
perl Configure.pl --backends=moar --gen-nqp --force-rebuild ... (6 more lines)		 02:40
rakudo/configure-rebuild-all: 2022b9cdfa | (Vadim Belman)++ | 2 files
Don't force checkout of nqp repo if it already exists

Forced checkouts could break thins if for any reason we want nqp to remain on certain branch or commit.
nqp: e5be636469 | (Vadim Belman)++ | 6 files
Use the new silent build way via NOECHO makefile variable

With support for `VERBOSE_BUILD` and `SILENT_BUILD` overrides, as in rakudo/rakudo@3c10487d7b6a930a101c39214105ec6649134909		 02:55
nqp: ac81c66aa6 | (Vadim Belman)++ | tools/lib/NQP/Config/NQP.pm
Don't checkout MoarVM repo if it's already exists

Keep it as it is for when we need it to remain at certain branch or commit.
nqp: ba6378efd4 | (Vadim Belman)++ (committed using GitHub Web editor) | 6 files
Merge pull request #587 from vrurg/configure-rebuild-all

Support for the new way of doing silent/verbose builds
03:16 cognomin_ joined 03:20 cognominal left
Geth rakudo/configure-rebuild-all: 82bd9c2c16 | (Vadim Belman)++ | tools/templates/NQP_REVISION
[NQP Bump] Brings 3 commits

NQP bump brought: github.com/perl6/nqp/compare/2019....gba6378efd ba6378efd Merge pull request #587 from vrurg/configure-rebuild-all ac81c66aa Don't checkout MoarVM repo if it's already exists e5be63646 Use the new silent build way via NOECHO makefile variable		 03:24
03:41 cognominal joined 03:45 cognomin_ left
Geth rakudo/master: 4 commits pushed by (Vadim Belman)++ 04:00
04:08 cognomin_ joined 04:09 cognominal left 05:17 Xliff joined 05:24 Xliff left 05:38 ZzZombo left 06:18 ZzZombo joined
lizmat Files=1277, Tests=109537, 218 wallclock secs (28.64 usr 8.21 sys + 2959.38 cusr 274.65 csys = 3270.88 CPU) 09:33
hmmm... PERL6_HOME isn't even documented at the moment? 09:37
perl6/Compiler.nqp states "PERL6_HOME Override the path of the Perl6 runtime files" 09:39
Changelog has: Introduced `PERL6_HOME` and `NQP_HOME` which allow to control where 09:40
Perl 6 and NQP look for their installation
so it appears to me that these are implementation specific environment variables 09:41
and that therefore RAKU_HOME is incorrect, and should be RAKUDO_HOME
Geth problem-solving: 0ac3cb71be | (Elizabeth Mattijsen)++ | solutions/language/Path-to-Raku.md
s/RAKU_HOME/RAKUDO_HOME/

The 2019.07 Changelog states:
   Introduced `PERL6_HOME` and `NQP_HOME` which allow to control where
   Perl 6 and NQP look for their installation
... (6 more lines)		 09:48
lizmat AlexDaniel: ^^
AlexDaniel how did it even allow you to push that? :D 09:53
anyway
jnthn: ↑ I need you to OK this change
there's also this: github.com/perl6/nqp-configure/pull/14 09:56
lizmat AlexDaniel: it was not a nilly willy change, nor a big one, and the commit message states why extensively
would you rather we'd gone through another issue with voting + weeks of discussion ? 09:57
NQP PR looks ok to me 09:58
AlexDaniel lizmat: not necessarily, we can call it a shortcut and that's it
lizmat: but that's up to jnthn
lizmat so, who would you rather I'd done it ?
AlexDaniel github.com/perl6/problem-solving#l...sible-devs
language – @jnthn
path-to-raku is technically `language`, even though the change we're talking about is rakudo 09:59
but either way it's jnthn :)
so as I said, I just need jnthn to OK/not OK this change :) 10:00
lizmat ok :-)
nine Feels to me like improper upwards delegation that can only lead to managerial exhaustion. We push a decision onto jnthn about a fairly minor issue without even listing the arguments for each side and without community recommendation. Let's face it, the jnthn (TM) is a very scarce and valuable resource. We should use him wisely. 10:05
lizmat nine++ 10:07
AlexDaniel sure, nine, you're welcome to PR a change to the main problem-solving document 10:10
or at least open an issue discussing this 10:12
here: github.com/perl6/problem-solving/i...amp;title= 10:13
jnthn From what I understand of how those env vars are used in relocatability, the change makes sense.
10:13 sena_kun joined
nine It's main use seems to be for finding Rakudo's implementation files like perl6.moarvm and Perl6::ModuleLoader. The other use is for finding the site, vendor and core repositories. In that case it can be overridden by %*ENV<RAKUDO_PREFIX> 10:14
jnthn It's far from clear that it's a language thing, 'cus otherwise it implies all implementations are expected to be relocatable *or* expected to factor their relocatability in the same way Rakudo is doing.
So considering it implementation-specific seems right.
nine In one case it's used for finding the implementation (doesn't get more implementation specific than that). In the other case the existing override already uses the implementation name. 10:15
jnthn There we go then :)
nine jnthn: do you concur that we should defer such decisions to you only as a very last resort?
AlexDaniel that's not how it works… 10:16
|Tux| Rakudo version 2019.07.1-505-g5c2395bfa - MoarVM version 2019.07.1-321-g97615be0a
csv-ip5xs0.705 - 0.718
csv-ip5xs-206.507 - 6.583
csv-parser21.936 - 22.086
csv-test-xs-200.422 - 0.427
test6.242 - 6.357
test-t1.774 - 1.781
test-t --race0.814 - 0.827
test-t-2028.745 - 29.172
test-t-20 --race9.611 - 10.977
 10:17
AlexDaniel jnthn: anyway, thanks!
vrurg: now what do we do with nqp-configure
jnthn nine: Well, it's hard to say in general, 'cus it's surely not always clear to those asking thing whether I will consider it significant. :) I suspect this one wouldn't have made its way to me if it hadn't been for it tweaking the rename solution. 10:20
AlexDaniel correct 10:21
personally I don't see the problem. If the solution is so obvious then it shouldn't take a lot of effort to OK it 10:22
jnthn Well, the problem - in general - is that there's one of me. :)
But yes, I think given it touched the document it did, it's reasonable of you to ask me to quickly check it in this case. 10:23
nine AlexDaniel: of course this little issue by itself is not a problem. The problem is that these little issues sum up quickly. From personal experience (as a manager) I can say that when people push these little things onto you, you feel half drained just dealing with them, before you even get to tackling your own projects. 10:24
And often "half drained" is not enough energy anymore for things like PEA that selfish like I am, I would much rather see jnthn working on. 10:25
AlexDaniel that's like the first time we had to touch this document in weeks…
I agree with what you say, it's just not an issue yet and I don't see it becoming one
nine I see jnthn invoked every single day on these channels :)
AlexDaniel not about tweaking already accepted documents 10:26
nine: but having only one jnthn is a real issue, yes :( 10:28
lizmat fwiw, I think the error is really that PERL6_HOME was incorrect to begin with
and it was too bad it slipped through the 2019.07 release
AlexDaniel currently all language/rakudo/moarvm issues go to jnthn, and that's not right 10:29
lizmat it should have been called RAKUDO_HOME before any name change, really
nine lizmat: well better late than never :)
AlexDaniel it's kinda early too :)
lizmat nine: indeed, but my point is that we would have to correct this even if we hadn't been renaming Perl 6 10:30
we're just abusing the rename process to fix a bug, in my opinion
so in that sense, I guess it was wrong to change the Path-to-Raku document 10:31
nine Well the document only states "we could consider". So we considered it and dropped it for a better solution - no need to change the document ;) 10:32
AlexDaniel vrurg: so surprisingly on the release branch nqp-configure is at 1cd8bdc
vrurg: I guess we should branch out from 1cd8bdc and merge that draft fix there? 10:34
lizmat ok, seems I need to have 13 approving reviews now to revert the commit
AlexDaniel vrurg: anyway let me know what you thin
lizmat: revert what? Why do you need to revert it? 10:35
wait now I'm confused :)
lizmat revert the commit I just did, as it isn't needed 10:36
anyways, I've stated why I think it should be called RAKUDO_HOME, and I think jnthn agreed with that 10:37
AlexDaniel that's correct, yes, I don't see why we need to revert it back now
jnthn No, leave it alone now that it's done. :) 10:39
[Coke] waves from the states. 10:55
[Coke] sees he just missed an interesting project management discussion.
lizmat is curious about [Coke]'s POV 10:58
being from the other side of the pond
11:02 patrickb joined
patrickb o/ 11:02
I thought I'd drop by as I was the author of the PERL6_HOME thing. 11:03
lizmat patrickb! 11:04
patrickb The original reason why the thing ended up being called PERL6_HOME instead of RAKUDO_HOME was that the folder was and currently still is called 'perl6' and not 'rakudo'. 11:05
lizmat well, than that's incorrect as well :-) 11:06
because that *is* implementation specific, is it not ?
patrickb From all I see it is implementation specific and thus makes most sense to have it all called 'rakudo' instead of perl6/raku. 11:07
[Coke] Definitely, if you have a scarce resource like jnthn, you need to make sure they are spending time effectively.
patrickb It's a nice convenience that the raku rename will allow us to sneak the rename of perl6 -> rakudo in.
[Coke] In terms of the actual PR, yes, this seems like implementation specific to me as well.
I actually am having trouble getting stuff done at $DAYJOB, and part of that is that I need to re-prioritize the sorts of meetings and tasks I find myself pulled into. 11:08
I joined a new firm a year ago, and am no longer "the jnthn" in my role, but am still seeing myself and peers falling into the same sort of issues. 11:09
lizmat patrickb: indeed :-) 11:10
"never waste a good crisis" 11:11
[Coke] TIL about h 11:13
hpppiiinggggggggggggggggggggggggggggggggg3
............ annnnnnnnnnnd aaaaallllllllsssssssssssssssssssssssssssssssoooooooooooo my kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeyboard seems ttttttttttttttttttttto 11:15
avvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvveeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ssssssssssssssommmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee iiiiiiiisssssssssssssssssues
wtf. 11:16
patrickb timotimo: Do you have any strong opinion wrt the naming of the '/usr/share/perl6' folder / PERL6_HOME? I ask because you were part of the original discussion that lead to it being named PERL6_HOME. 11:17
11:18 squashable6 left
patrickb There was this idea floating around that the folder should be used by all implementations (colabti.org/irclogger/irclogger_lo...1-07#l272) 11:18
I'm in favor of having it named rakudo_home and being implementation specific, I just want to make sure we are not missing a reason. 11:19
11:20 squashable6 joined
lizmat fwiw, I'm not sure we can be inclusive of any other Raku implementation beforehand 11:20
except maybe for -Ilib behaviour
patrickb Actually I think having that folder be rakudo specific is more inclusive, as we are then not littering a folder that would be shared between implementations with specific stuff. 11:29
[Coke] I can imagine us moving to a RAKU env var if there's consensus later. (whether that's consensus with another implementation's design team, or if our design team reviews and declares it good enough)
11:30 squashable6 left 11:33 squashable6 joined 12:03 Altai-man_ joined 12:05 sena_kun left 12:06 ZzZombo left 12:09 ZzZombo joined 14:04 sena_kun joined 14:06 Altai-man_ left
lizmat so what *is* the correct handling of making a branch uptodate with master? 14:06
because I'm stuck again in a "cannot update because current branch is behind"
and a "fatal: cannot rebase with locally recorded submodule modifications" loop 14:07
:-(
vrurg lizmat: do rebase with --no-recursive-submodules. Then git pull again should fix up the submodule correctly. 14:18
AlexDaniel: leave the nqp-configure as is in the release branch. What's done lately is going into the next release. That's how I see it. 14:19
lizmat vrurg: error: unknown option `no-recursive-submodule
patrickb missing an 's'? 14:20
lizmat error: unknown option `no-recursive-submodules
vrurg lizmat: ah, you actually do `git rebase`... Because I work on my own fork of rakudo, I do `git pull --rebase` most of the time. :( 14:21
lizmat no, I do "git pull --rebase"
$ git pull --rebase --no-recursive-submodules 14:22
error: unknown option `no-recursive-submodules'
vrurg lizmat: --no-recurse-submodules
Sorry, autocompletion makes me forgetting actual names.
lizmat hehe... ok, that works much better
Geth rakudo/add-type-to-positional-in-usage: 20 commits pushed by (Elizabeth Mattijsen)++, (Tom Browder)++, (Vadim Belman)++, (Stefan Seifert)++, (Ben Davies)++
review: github.com/rakudo/rakudo/compare/8...c784b645be
lizmat but now I pushed 20 commits ? and it was only 1 ? 14:23
nine lizmat: if you rebased on a branch that gained 19 commits in the mean time, those are added to your remote branch as well - after all your local branch got them, too 14:24
lizmat but the branch did *not* gain 19 commits
it only gained 1, the others are from master ?
vrurg lizmat: they're. 14:25
nine Commits in git do not have a branch of origin. In fact, commits don't know anything about branches. They only know their predecessor commits. 14:26
lizmat I guess I'm misunderstanding the process still
AlexDaniel vrurg: so we're leaving --perl6-home ?
nine The best way to understand branches in git is to think of them as symlinks pointing to a commit (which they pretty much are in the .git directory).
AlexDaniel again, I love this: learngitbranching.js.org/ :) 14:27
vrurg AlexDaniel: yes, for this release. We can't incorporate everything at once.
AlexDaniel okay
nine So while a branch does have a clearly defined end, it's start is always the initial commit in the repository. A branch may have commits in common with other branches (like master) and tools can show you only the unique commits.
All that said: there is something wrong, as GitHub shows the PR would add 23 commits to master, which cannot be right. 14:28
AlexDaniel yeah that's absolutely wrong 14:29
lizmat well, that there is something wrong, is my feeling as well
I mean, I thought all went well with branches
until we got updates to submodules
AlexDaniel basically these commits were rebased on top of some other commit
lizmat so let me rephrase my workflow: 14:30
1. do some work on the core
2. git checkout -b branch-name
3. git commit whatever I did
4. git push 14:31
time passes and commits are done to master
while on master:
5 git pull
6. git checkout branch-name
7. git rebase master
make changes 14:32
8. git commit
9. git push
is that a wrong workflow?
nine The last step would clearly be a git push -f. This workflow doesn't mention a pull --rebase. So where did that come in?
And yes, I've used this workflow a 1000 times 14:33
AlexDaniel as for how to recover from it now, I'd say just cherry-pick your commits into a new branch 14:34
nine Or rebase -i on master and remove all but the 1 commit from the list 14:35
AlexDaniel yeah
tbrowder AlexDaniel: ref git and PRs, can we PR submitters revert the PR merge? if so, I need a cookbook solution given my setup (probably same as most here): work on local branch off master; single commit (after being told of its importance to you and management of the whole public repo); push to my account on github (origin); create PR; i, or someone else, merges the PR; PR later fails and commit needs to be reverted. so, 14:36
given all the repos and branches, how is that accomplished?
AlexDaniel it can only be done with a revert commit 14:37
IIRC github has a button to create one for you
tbrowder can i do it? or does it take someone else?
lizmat nine: sorry, 5 was a "git pull --rebase"
AlexDaniel tbrowder: open your PR and see if it has a Revert button, it should 14:38
tbrowder okay, i'll try that...
AlexDaniel that'd create a new PR
you can revert it without a PR from command line, of course
IIRC `git revert merge-commit-sha` and then follow the instructions, it'll ask which side of the merge you want to revert 14:39
nine lizmat: why do you do a git pull -r on the master branch? There shouldn't be anything to rebase there (unless you committed directly to master) 14:51
lizmat: and indeed github.com/rakudo/rakudo/commit/42...9b06b27c34 is not on master, so that's why your branch now starts with that 14:53
lizmat: the commits between that and your most current one are now distinct from their originals on master because they have a new parent
lizmat nine: the --rebase is a caution to handle the case where I missed commits on remote master while I was preparing the commit 14:55
that's a valid approach, is it not?
at least I will be told immediately if there are conflicts with my local work and the remote state ?
[Coke] I always do pull --rebase, even if it's likely that I didn't need to, because I'd rather do it and not need it than the converse. 14:56
(I aliased pull --rebase to "git rb" I do it so often.)
Geth rakudo: d81212b205 | (Christian Bartolomäus)++ | t/02-rakudo/13-exceptions.t
Add tests for catching error at compile time

The second new test refers to a change introduced with
  github.com/rakudo/rakudo/pull/3231 (to fix RT #129812
on the JVM backend). The first new test only serves to show that the native and the non-native case behaves identically.		 14:57
rakudo: 4181ca6134 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | t/02-rakudo/13-exceptions.t
Merge pull request #3304 from usev6/literal_to_rw_x_comp_test

Add tests for catching error at compile time
vrurg lizmat: what I do is I fork the original repo into my account. Locally, in the clone, I add 'upstream` remote which points to the original repo. Then in a branch where I work on something, I do `git pull --rebase upstream master' periodically. 15:12
With forking I'm not afraid of branch pollution and know that I wouldn't accidentally mess up with the original master. 15:14
15:22 squashable6 left 15:23 squashable6 joined
lizmat how is that different from "git pull --rebase" in master, and then doing the "get rebase master" in the branch ? 15:24
tbrowder AlexDaniel: the original test failure was for Mac OS, not Linux, so I'm not sure I can fix it, but i restarted the PR build to check ressults before i do anything. and i see your advice on the revert--taking better notes this time :-D 15:29
vrurg lizmat: the difference is subtle: I rebase my branch in the fork against the upstream master. And so far it works reliably well. 15:34
[Coke] lizmat; if you didn't have any local commits in master, I'd expect equivalence. 15:35
vrurg is afk&
15:48 entonian joined 15:50 entonian left
tbrowder *PR build should be "PR merge build" 15:57
vrurg: that (periodically while on my feature branch: git pull --rebase upstream) sounds like what i should be doing, thnx for the hint. 16:00
AlexDaniel: ref vrurg's periodic rebase, will that add another commit which will make it difficult to revert a PR? 16:02
16:03 Altai-man_ joined
tbrowder ok!! the rebuild of my PR #3253 merge passed all Linux and OSX tests, so i assume i can press on with other stuff, yes? 16:04
16:06 sena_kun left
lizmat so, as some of you may know, I've been working on a new implementation of Sprintf in a branch: newer-sprintf 16:30
this branch creates a new file, and adds it to the list of files to live in the setting
so not a lot of chance for conflicts 16:31
it's been a while since I worked on that branch
what is the sequence of git statements that I should use to make sure the branch is up to date with master ?
AlexDaniel well, you always have a choice to either merge or rebase 16:34
but the one you gave previously should work for rebasing
lizmat ok, so on master: git pull --rebase to make sure it's up to date, then checkout the branch and do a "git rebase master", right ? 16:36
AlexDaniel well --rebase is not needed, just git pull is fine, but yeah
in case of a conflict you'll have to resolve it, but that's no biggie 16:37
[Coke] AlexDaniel: it's not needed unless you somehow forgot about a commit - if you prefer rebases, why not just always use it? 16:52
AlexDaniel [Coke]: then the branch will be on top of the commit that perhaps was not meant to be there 16:54
[Coke] if you have that commit in master, the branch will include it after a rebase against master anyway - the difference will be that the history of master will have a more linear history instead of a merge commit. 16:57
AlexDaniel yeah that's right 16:58
but I'm for understanding what you're doing. So if you don't have any new commits on master, then you can just pull. If you don't know and decide to do --rebase just in case, well… maybe you should check first 17:01
17:08 patrickb left
[Coke] That's fair. 17:25
dogbert17 anyone recognize this message: ethod NQP::Config::configure_misc must be implemented by the language class at /home/dogbert/.rakudobrew/versions/moar-master/3rdparty/nqp-configure/lib/NQP/Config.pm line 563. 17:32
at /home/dogbert/.rakudobrew/versions/moar-master/3rdparty/nqp-configure/lib/NQP/Config.pm line 35.
vrurg dogbert17: your submodule didn't update somehow. 17:47
dogbert17: what's in your 'moar-mast' dir? NQP? 17:48
dogbert17 I wiped the moar master dir and then the build worked 17:50
I have another problem on my RPi 4 though 17:51
+++ Setting up nqp-m
Option force-rebuild does not take an argument
Configure.pl - NQP Configure
and then the build fails
usually I just do 'git pull' in my rakudo dir followed by 'perl Configure.pl --gen-moar --gen-nqp --backends=moar' 17:52
vrurg: more detail here: gist.github.com/dogbert17/a8d8a4a9...d23accacdd 17:55
vrurg dogbert17: same issue, the submodule didn't update somehow. 17:58
And it's never clear why it happens and for what reason git doesn't update it. :( 18:00
dogbert17: could you try fresh clone of rakudo and re-build? Must work this way. 18:02
18:04 sena_kun joined 18:06 Altai-man_ left
Geth rakudo/release-2019.11: 235737fa03 | (Aleks-Daniel Jakimenko-Aleksejev)++ | 2 files
Tiny changelog tweaks
 18:21
jdv79 [Coke]: i have "up" aliased to "git pull --rebase --stat" 18:59
but yeah, the submodules are kinda annoying how they don't interact well with some workflows:(
i also have recently become "mgmt" or sorts and am easily swamped with random seemingly small issues regularly:( 19:01
*of
japhb I have bash functions for managing upstream handling: one to allow me to git pull --rebase *and* review each of the commits in actual commit order: gpr () { cur=`git rev-parse HEAD`; git pull; git log -p --reverse $cur...; } 19:13
*I have two
The second one lets me get an overview of the graph of branches and merges: glg () { git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %Cblue<%an>%Creset' --abbrev-commit --date=relative --color=always "$@" | less -R ; }
Sorry, the first one is to git pull *without* the rebase. 19:14
I actually end up with a *lot* of 3-letter shell functions and aliases, because even 'git ' at the front became annoying for my most common uses, so I don't even use git's own aliasing system. 19:15
19:18 squashable6 left 19:19 squashable6 joined 19:23 MasterDuke joined 19:26 cognominal joined 19:30 cognomin_ left
Geth roast/cleanup-perl5-name: 8e16059e9c | (Vadim Belman)++ | 124 files
Change references to Perl 5 to just Perl

This surely doesn't affect keywords. Also a historical quote left intact.		 19:57
roast: vrurg++ created pull request #599:
Change references to Perl 5 to just Perl
roast: 8e16059e9c | (Vadim Belman)++ | 124 files
Change references to Perl 5 to just Perl

This surely doesn't affect keywords. Also a historical quote left intact.		 20:00
roast: 4c384ec3b8 | (Vadim Belman)++ (committed using GitHub Web editor) | 124 files
Merge pull request #599 from perl6/cleanup-perl5-name

Change references to Perl 5 to just Perl
20:03 Altai-man_ joined 20:06 sena_kun left 20:19 cognomin_ joined
vrurg greppable6: rx:Perl5 20:19
greppable6 vrurg, Found nothing!
Altai-man_ P5?
vrurg greppable6: [s|m]:Perl5 20:20
greppable6 vrurg, 1 line, 1 module: gist.github.com/91e81dcbd05c7a93cb...5c987529c6
vrurg Altai-man_: why P5?
Altai-man_ vrurg, dunno, probably my memory is wrong
vrurg Altai-man_: it's rx:Perl5 all over roast. 20:21
greppable6: [s|m|rx]:P5 20:22
greppable6 vrurg, 10 lines, 7 modules: gist.github.com/89c6f168f208874990...50d1579f31
vrurg It is aliased, it seems.
20:22 cognominal left
Geth ¦ problem-solving: vrurg assigned to jnthn Issue Remove P5 regexes from Raku github.com/perl6/problem-solving/issues/133 20:24
AlexDaniel it was a nice idea, but yeah, it seems like most people would much rather rewrite them as raku regexes instead 20:41
when porting perl5 code, that is
lizmat the big problem is that they are Perl 5.8 regexes, which if you're using Perl now, is basically really old 20:43
vrurg So, as Inline::Perl5 isn't core functionaliy, P5 regexes shouldn't be either. 20:45
lizmat well, Inline::Perl5 was a nail to the coffin of "use v5"
[Coke] +1 from me. Seems like you could wrap Inline::Perl5 to similar effect.
lizmat perhaps this would need to be revamped to transparently load Inline::Perl5 if avaoilable, and run it in the Perl 5 runtime ? 20:46
[Coke] and the Rename doesn't help either.
Also: would we rather encourage people to transpile their regexes into Grammars?
lizmat perhaps with an ":ip5" adverb, to not cause clashes with :p5 users?
nine How on earth can this work without a return type? method new() is native("./11-cpp") is nativeconv('thisgnu') { * } 20:47
(from our NativeCall tests)
vrurg would rather welcome all this discussion to the problem solving. 20:50
[Coke] So, back in the day, I was interested in getting Rakudo to run on the JVM because that was how I was going to get it deployed. Then containers happened, so MoarVM was just fine. Then I moved to a .NET shop. Do we have a guide on porting to a new backend? I know we have some example of it being done, but I don't think there's a porters guide.
vrurg IRC log isn't easy place to search afterwards.
[Coke] vrurg: feel free to cut and paste my comments if that helps.
vrurg [Coke]: For now I'd just incorporate a link to colabti. 20:51
[Coke] +1
MasterDuke [Coke]: lock pmurias in a room until he writes one? 20:52
[Coke] Which reminds me: I could really use some community feedback on the JS backend. 20:53
Geth ¦ problem-solving: japhb assigned to AlexDaniel Issue Update or replace draft SoC/CCoC github.com/perl6/problem-solving/issues/134
¦ problem-solving: AlexDaniel self-unassigned Update or replace draft SoC/CCoC github.com/perl6/problem-solving/issues/134
¦ problem-solving: AlexDaniel assigned to lizmat Issue Update or replace draft SoC/CCoC github.com/perl6/problem-solving/issues/134
roast: vrurg++ created pull request #600:
Add test for `$.method: <args>` syntax		 20:57
roast: 93b99d6b86 | (Vadim Belman)++ | S12-methods/syntax.t
Add test for `$.method: <args>` syntax

Related to rakudo/rakudo#3306		 21:00
roast: 03a18d29c6 | (Vadim Belman)++ (committed using GitHub Web editor) | S12-methods/syntax.t
Merge pull request #600 from vrurg/rakudo_3306

Add test for `$.method: <args>` syntax
21:01 entonian joined, MasterDuke left 21:02 entonian left
japhb vrurg, Altai-man_: P5 regex weren't just for backwards compat or to assist porting -- it was to bootstrap regex functionality in PUGS, since libraries already existed for PCRE-equivalent regexen in Haskell. 21:06
vrurg japhb: But that's not actual anymore, right?
japhb vrurg: Nope, I was just saying it wasn't added as an afterthought, but more as a prethought. :-) 21:08
AlexDaniel I wish you strength lizmat
doesn't look like an easy issue to resolve :( 21:09
japhb (I would say forethought, but that's a different thing -- the forethought perhaps was in not stomping on the main regex braid.)
vrurg AlexDaniel: agree to you. Hope we can be helpful for lizmat. 21:11
21:12 entonian joined
AlexDaniel vrurg: heh a release manager in me is already shutting down, what do I click… 21:12
this?
Geth nqp/release-2019.11: 34e7d9ff3d | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/templates/MOAR_REVISION
[release] Bump MoarVM revision to 2019.11
 21:13
nqp/release-2019.11: 3e05931f3b | (Aleks-Daniel Jakimenko-Aleksejev)++ | VERSION
[release] Bump VERSION to 2019.11
rakudo/release-2019.11: 2a70c951e8 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/templates/NQP_REVISION
[release] Bump NQP revision to 2019.11
rakudo/release-2019.11: 8fa2b0f6a4 | (Aleks-Daniel Jakimenko-Aleksejev)++ | VERSION
[release] Bump VERSION to 2019.11
AlexDaniel hmm I guess so…
21:14 entonian left
AlexDaniel I'm sorry, serious question, where's moarvm 2019.11 release? :D 21:15
moarvm.org/releases/
samcv: heeyyy… I think you forgot to upload some tars 21:16
Geth nqp: 34e7d9ff3d | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/templates/MOAR_REVISION
[release] Bump MoarVM revision to 2019.11
 21:25
nqp: 3e05931f3b | (Aleks-Daniel Jakimenko-Aleksejev)++ | VERSION
[release] Bump VERSION to 2019.11
nqp: 41f6576e99 | (Aleks-Daniel Jakimenko-Aleksejev)++ | 9 files
Merge branch 'master' into release-2019.11
rakudo/master: 10 commits pushed by (Vadim Belman)++, (Aleks-Daniel Jakimenko-Aleksejev)++
review: github.com/rakudo/rakudo/compare/4...0bf3860455		 21:27
rakudo: 7a0a63078c | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/releasable/github-release.p6
Rakufy the github uploader script
 21:28
rakudo: ece3853117 | (Aleks-Daniel Jakimenko-Aleksejev)++ | 2 files
Fix small formatting error in the changelog
 21:58
22:00 Kaiepi left 22:01 Kaiepi joined 22:05 sena_kun joined 22:06 Altai-man_ left
lizmat is very tired and has a lot to mull about so goes to bed& 22:09
Geth nqp: 5a9be2170a | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/templates/MOAR_REVISION
[MoarVM Bump] 8d0b50d3f Fix JIT compiled nativ […]

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...g8d0b50d3f		 22:12
rakudo: bb44785127 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/templates/NQP_REVISION
[NQP Bump] Brings 4 commits

NQP bump brought: github.com/perl6/nqp/compare/2019....g5a9be2170 5a9be2170 [MoarVM Bump] 8d0b50d3f Fix JIT compiled nativ […] 41f6576e9 Merge branch 'master' into release-2019.11 3e05931f3 [release] Bump VERSION to 2019.11 34e7d9ff3 [release] Bump MoarVM revision to 2019.11
22:13 lizmat left 22:14 lizmat joined
Geth rakudo: 093ed87fdf | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/release_guide.pod
Keep previous format for next releases
 22:17
22:51 entonian joined 22:54 entonian left 23:06 entonian joined 23:07 entonian left 23:19 |Tux| left
[Coke] did the switch from perl6/doc to Raku/doc invalidate my key, or is that something else? 23:56

Powered by Cro and the Raku® Programming Language.

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

Thank you!