|
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 1 February 2014. |
|||
|
09:31
denis_boyun joined
09:56
denis_boyun joined
11:38
denis_boyun joined
16:23
bluescreen joined
17:13
denisboyun joined
|
|||
| Util | Pre-report: | 19:26 | |
| # Done: Nil ($WORK, plus weather cancelled my Atlanta.pm talk) | |||
| # Plan to do: | |||
| * Participate in GSoC planning | |||
| .end | |||
|
19:26
rurban joined
|
|||
| Util | Hello! Who all is in attendance? | 19:31 | |
| rurban | me. not much to report, still busy with the perl5 compiler | 19:32 | |
| mentally preparing for the release next week | |||
|
19:33
kurahaupo joined
|
|||
| Util | rurban: Do you need any help for the release? From me or anyone else? | 19:33 | |
| rurban | nope. all clear. I just wanted to fix more issues before, but ran out of time | ||
| Util | OK | 19:34 | |
| BTW, where is the best summary of your P5compiler project? I thought I might mention it at our next PM meeting, but I want to get the details right. | 19:35 | ||
| rurban | www.perl-compiler.org/ | 19:36 | |
| Util | Thanks | ||
| rurban | or perldoc B::C | ||
| Util | After `cpanm B::C` :^) | 19:37 | |
| rurban | after alias perldoc=cpandoc :) | 19:38 | |
| cpanm B:C will be tricky (20 min. testsuite, longer than Moose) | |||
| no more volunteers for issue fixing? :( | 19:40 | ||
| Util | issue fixing in B::C or Parrot? | 19:41 | |
| rurban | re PM: you can mention that cPanel is using the p5 compiler in production for ~15 years and runs on ~70% of the internet | ||
| parrot issues of course | |||
| Util | I expect that, as we just saw with Nick Clark, people will work on Parrot bugs to adjust for Rakudo changes, but little else right now. | 19:43 | |
| (Besides us perhaps) | |||
| It is a low point in manpower for the project, but I am not discouraged. | 19:44 | ||
| Either: A. MoarVM will become completely faster *and* more capable that Parrot for Rakudo, in which case we just keep the lights on until that day, or | 19:45 | ||
| B: MoarVM will falter or fail in some way, and some of its developers will return to Parrot. | |||
| I am still interested in getting GSoC volunteers for Parrot this year, since I don't know if it will be A or B, | 19:46 | ||
| and some of the tasks we listed last week would smooth the way for case B. | 19:47 | ||
| www.perl-compiler.org/status.html says 5.16 works with B::C, but is not stable. Is this still true? What about 5.18? | 19:49 | ||
| nm. I see code.google.com/p/perl-compiler/so...wse/STATUS now. | 19:50 | ||
| rurban | I consider 5.16 too instable for production use at all. 5.18 50% better | 19:55 | |
| for B::C 5.16 passes all tests, but 5.14.4 is still the best and recommended version | |||
| 5.18 has some bugs with the bytecode compiler, which I suspect are upstream B bugs | 19:56 | ||
|
19:56
kurahaupo joined
|
|||
| Util | Building on 5.18.0 right now; I started it before I thought to check on versioning issues. | 19:56 | |
| rurban | 5.20 is a bit better security-wise, but I still need warnings on use strict 'names' | 19:57 | |
| which is not implemented yet | |||
| Util | By 5.20, do you mean 5.19.8? | 19:58 | |
| rurban | you'd probably need to force install 5.18, as I didn't TODO all failing 5.18 bytecode tests yet. And sometimes bytecode just works | ||
| yes | |||
| 5.19.9 now | |||
| and performance-wise 5.6 is still 2x faster than 5.14 on startup | |||
| I'll profile the phases this week to prove where 5.14 is so slow (loading the utf8 folding tables I assume) | 19:59 | ||
| Util | I don't see 5.19.9 in www.cpan.org/src/5.0/ l should I be looking elsewhere? | 20:00 | |
| rurban | git only | ||
| not yet released | |||
| Util | OK | ||
| rurban | but now with full sigs | ||
| Util | Cool! | ||
| rurban | just @_ is still filled, which is not needed with the new sigs. So it's slower, not faster | 20:01 | |
| They also haven't deprecated @_ with sigs and no optional args yet. @_ should only hold optional args, not all. my $arg = shift vs my $arg = @_ | 20:02 | ||
| Util | they will just need to decide on a policy mechanism, to eliminate the @_ issue. | ||
| rurban | they decided not to decide (as usual) | ||
| even with new subs which are declared with sigs they keep filling @_ | 20:03 | ||
| So it will be super-hard to change it later. Oh my. But you cannot talk to them. | |||
| Util | Frustrating, I am sure. | 20:04 | |
| Anything else to discuss before adjourning? Anyone? | 20:06 | ||
| OK, then. Meeting adjourned. Thanks to all! | 20:09 | ||
|
20:10
denisboyun joined
20:21
denisboyun joined,
rurban joined,
bluescreen joined,
Tene joined,
PerlJam joined,
wagle joined,
Coke joined,
Zefram joined,
kshannon_ joined,
Util joined,
slavorg joined,
cotto joined,
atrodo joined
|
|||
| sa1 | missed the meeting, reading backlog | 20:21 | |
| hmm, nothing to add | 20:28 | ||
| Zefram | re signatures in perl5, there was a positive decision that @_ setup will be decoupled from signatures. we get signatures in 5.20, and @_ suppression is on the agenda for 5.22 | 20:38 | |
| signatures are not a performance feature, they're syntactic sugar | 20:39 | ||
|
21:14
denisboyun joined
|
|||
| rurban | I know. Such p5p decisions are questionable and also not discussable in the p5p realm. And of course I see the wrong result. | 21:34 | |
| With 5.20 people will start using $_[0] for references with sigs, or $_[n] for the rest args, and then 5.22 cannot deprecate it. doing it right from the beginning is the only solution | 21:38 | ||
| and don't introduce another crazy magic optional signature sigil. @_ is enough for the optional @rest args | 21:39 | ||