Post closed tickets in your report. | Note: This channel is for our weekly status meetings (Tuesdays at 19:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/
Set by moderator on 6 October 2013.
06:31 denis_boyun joined 06:35 denis_boyun joined 12:10 denis_boyun joined 12:28 denis_boyun joined 12:32 denis_boyun joined 13:35 darbelo joined 13:39 bluescreen joined 14:34 denisboyun joined 15:10 denisboyun joined 16:07 denisboyun joined 18:02 denisboyun joined
Util Pre-report: 19:29
# Done:
19:30 rurban joined, pmichaud joined
Util * Abandoned plan for September Parrot release 19:30
+ because it is October :^(
* Fixed `make fulltest` examples fail spotted by jkeenan++
# Doing:
* Prepping for GSoC Mentor Summit
+ Potential talk (Unconference) 19:31
+ Stickers
* Helping prep of October Parrot release.
* Starting to help with new-packfile-api branch.
+ FYI: contention exists regarding the timing of this branch-merge vs Release schedule.
.end
sa1 Util: hello 19:33
rurban Tested and fixed new-packfile-api (ready to be merged) and readall on eof (this being merged)
Util Hello! Who all is in attendance?
sa1 I've spent some time reading, so no new updates
I'd like to mention however, that GSoC 2014 has been announced already. 19:34
rurban icu detection broken with debian testing, postponed after 5.9
Util rurban: Do you own that ICU-detect bug? (i.e. are you fixing it, or just reporting it?) 19:36
19:37 Zefram joined
rurban I reported it, and probably I'm the only one who can repro and fix it. But I have no time right now 19:37
Util sa1: Great news!
rurban typically not_gerd beats me 19:38
Util Left out of my pre-report: # Done: Helped Zefram to flesh-out and report 20+ more bugs. .end 19:39
rurban: I understand. Thanks!
rurban Util: very good stuff in there. We should probably discuss this also
Util rurban: I missed getting the Priority-tag that Zefram gave them into the tickets, and have just started adding that info. 19:41
rurban: Do you have any favorites to discuss?
rurban The only conflicti e non-consense I see is the recursion limit 19:42
I'm for keeping 1000 as default. Zefram is against it. 19:43
pmichaud iirc, the low recursion limit was set on purpose so that developers would quickly know when they had a recursion problem
and that stable language platforms could then raise the limit as appropriate
rurban Agreed. The rest seems to be consensual, we just need devs to pick it up :) 19:44
pmichaud so, for example, one of the first things that Rakudo does when it initializes is to bump up the recursion limit
Util pmichaud: That was my take on the r.limit decision. It really boils down to whether you view PIR&Parrot as something to implement general-purpose code in, vs a platform for building&running Languages. 19:46
rurban One more conflict of interests #1008: Stylistic issue. The bad parrot ops compiler adds superfluous (()) to logical checks. parrot langs on clang need to use -Wno-parentheses-equality then or we find a way to improve the compiler 19:47
Util rurban: I am in favor of improving the compiler. It is not trivial, but neither a *deep* problem, and will resolve some of our outstanding Coverity bugs. 19:52
rurban I was also in favor when I trampled into this clang problem last year. But it was not that easy :) 19:54
Util rurban: OK, lets bring this back up after the release, when we have had time to look at that part of the compiler code again. 19:56
If we cannot resolve it by end-of-October, we should implement -Wno-parentheses-equality, at least temporarily. 19:59
rurban We already do. The problem is only at nqp, which doesn't take over this flag
nqp is pretty sloppy regarding warnings and strictness. g++ compilation is e.g. impossible 20:00
pmichaud can that statement be made a little more precise, please? 20:02
I'm totally confused by it.
rurban try a parrot compiled with g++ and see the nqp compilation errors 20:03
pmichaud nqp, or nqp-rx ?
rurban nqp. nqp-rx is fine
pmichaud iirc, nqp just grabs the flags it's using from parrot config
rurban yes, and then it runs into nqp coding_std problems 20:04
pmichaud feel free to file nqpissues for it, then
(and if you have already, thanks) 20:05
rurban yes, I'll try to properly repro it now. I just stumbled upon this while testing the new packfile-api on nqp
pmichaud new packfile-api with nqp is going to require a lot of intricate bootstrapping help 20:06
it's not at all going to be a matter of simply rebuilding nqp on the new parrot
(because nqp is built from an older version of nqp, which will require the older parrot)
rurban I see. I did: perl Configure.pl --without-icu --cc=g++ --link=g++ 20:07
pmichaud for parrot or nqp?
I guess for parrot.
rurban Yes, The nqp problem was with -fpermissive 20:08
pmichaud trying to build nqp now via g++ 20:09
Util Are we agreed to hold *both* parts of the new-packfile-api merge until after the October release?
rurban like nqp_ops.c:11937:47: warning: invalid conversion from ‘void*’ to ‘char*’ [-fpermissive]
I don't care. I would vote to merge both before 20:10
pmichaud "both parts"?
rurban pf api and eval removal 20:11
Util rurban is correct about "both parts"
rurban eval removal is the last commit in that branch, so we could keep eval for one more round
pmichaud oh, I didn't know there was an option to keep eval.
if both can coexist, it makes the nqp bootstrap easier.
rurban there is, but I don't like it
pmichaud (until it's completed) 20:12
rurban pick b77f276 Add Parrot_pf_single_sub_by_tag() to packfile API. Additionally, add method first_sub_in_const_table() to PackfileView PMC as
pick 2c730f5 Enable new API by returning PackfileView instead of Eval from IMCCompiler
pick 8e7165b Use new packfile API
#pick e38b4cb Remove Eval PMC
pick d40e79e [coding_std] minor #937 issues
d40e79e also needs to be changed. I'm testing that now 20:14
Util I had proposed (in #parrot) splitting the branch into pre-release and post-release merges. However, holding it all off for just one more week is more prudent.
Util is straddling the line as a former Release Manager, but not the RM for *this* release, while the current RM has *just* been notified. 20:16
pmichaud rurban: if I'm reading commit e38b4cb correctly, all it does is remove EvalPMC from the compilation. Prior to that the "PIR" compiler has already switched over to generating PackFile instead of EvalPMC 20:17
rurban yes
pmichaud oh, that doesn't help then.
nqp and rakudo expect the result of C< compreg "PIR" > to return something that produces EvalPMC objects. 20:18
we'll change that to PackFile PMC, of course... but there's a bootstrap issue involved. 20:19
rurban like this? github.com/perl6/nqp/commit/a93c7c...ca195d6128 20:20
pmichaud yes, that's the version that gerd put together, but it's not really "correct".
and that doesn't get through the bootstrap issue. 20:21
rurban but it compiles and tests ok in the old nqp/new-packfile-api branch, even with the kept EvalPMC 20:22
pmichaud then I'll look into it more. 20:23
it may be only rakudo that ends up with an issue here.
(which wouldn't have a bootstrapping problem, in all likelihood)
rurban that could be. I haven't tested that yet. I only had nqp rebase conflicts 20:24
So I only could test gerds old branch
So I would summarize: Lets defer new-packfile-api to Nov and give nqp/rakudo some time to test that branch 20:25
pmichaud in nqp/new-packfile-api, did you bring it up-to-date with latest nqp/master at all? 20:26
rurban Esp. rebasing nqp/new-packfile-api. There were a LOT of nqp changes since that
pmichaud right
nqp went through a major refactor about the same time as new-packfile-api was being developed... which is also part of the reason it wasn't merged back in jan/feb
rurban All nqp tests pass with and without the single EvalPMC removal commit. So from parrot side we are good. 20:28
Util I am enthused that new-packfile-api is getting such attention.
The rest of the discussion should move to #parrot
(or elsewhere; just tell us where to watch)
, so that we can finish this meeting.
pmichaud I don't follow "all nqp tests pass" because I don't know what version of nqp rurban is referring to.
rurban new-packfile-api c1675fc
the old gerdr branch 20:29
pmichaud ...the 8-month old version of nqp.
rurban the new master not. This fails with missing elements() from PackFilePMC or so
pmichaud I disagree with the "from parrot side we are good" conclusion, but it's not my call. 20:30
rurban I was only referring to the new-pf-api branch being good or not. 20:31
pmichaud the parrot one or the nqp one?
rurban both 20:32
pmichaud the nqp branch is no good.
it's 8 months out of date.
rurban but the nqp one needs to be rebased which is huge
pmichaud it can't be done with a simple rebase
rurban yes, easier would be a rewrite
pmichaud the nqp/new-packfile-api branch has patches to the stage0 files, which of course are completely different now.
rurban so this is not good. that's why I thought we should wait until this is done. 20:33
pmichaud I'm fine with waiting, yes.
Now that there is an up-to-date parrot branch I can work with, we can make progress on the nqp side again. 20:34
Util rurban++ pmichaud++ 20:35
Any other issues, before we adjourn?
pmichaud not from me :) 20:36
Util I will watch for further discussion of new-packfile-api in #parrot, unless someone tells us that it has moved elsewhere. 20:37
Meeting adjourned.
22:39 lizmat joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!