Front page | perl.perl5.porters |
Postings from June 2011
On 06/06/2011 01:16 AM, Reini Urban wrote: >> We're not prepared to bend over and give you what you demand. We've offered >> you a route, which you refuse to take. > > "You" proposed that route, not "we". True. > I'm not demanding that "you" fix these issues, I don't care who will fix it. > But they should be fixed. > I offered help, but it was not accepted so far. I do not remember your offering help with what was proposed by Nicholas. Which, incidentally, I agree to. >> Ad-hoc use of any function that seemed useful, rather that working to create >> and update a well-behaved API, has got the perl core into the maintenance >> hell that it currently is. We need to stop making those mistakes. Hell yes. Umm, no. But you know what I mean, don't you? :) > Wrong. It's now "years later" because you blocked it for years. > You are also blocking other bugfixes because you don't like it or have no time. > Who can step up now? You, for example? > Interesting, it was Rafael not you. I certainly remembered it differently. > http://www.xray.mpe.mpg.de/cgi-bin/w3glimpse2html/perl5-porters/2006-09/msg00230.html?58#mfs > > I'm wondering why he was able to remove it without any discussion and > with such a bold statement. Ok, p5p was not able to support it > anymore. > But PAR is by far no comparable solution. PAR makes perl scripts > slower not faster. PAR makes startup slower. Not the execution. Anyway, "solution" to what? I think you're trying to solve a very different problem with the compiler than PAR addresses. Alas, most people trying to use the compiler are trying to solve a problem that PAR solves, too (and IMO better). That is, distribution and deployment, not optimization. Cheers, SteffenThread Previous | Thread Next