Bug #74593 for Parse-RecDescent: Recent changes break Module::ExtractUse and its dependents

In case anyone else is interested, here is a list of more related tickets on how the unfortunately non-backwards compatible changes have broken other modules: https://rt.cpan.org/Ticket/Display.html?id=74733 https://rt.cpan.org/Ticket/Display.html?id=74618 https://rt.cpan.org/Ticket/Display.html?id=74637 https://rt.cpan.org/Ticket/Display.html?id=74640 Any thoughts about keeping (or adding back in) backwards compatibility for a release or two instead of just pulling the rug out of others that use this Parse::RecDescent?

Yes, I'm interested. Let me think about it over the weekend. I'm certainly open to it, though it will be challenging to maintain backwards compatibility for P:RD's internals. Adding backwards-compatibility back in will either hurt performance, require two copies of the internals to be maintained, or re-introduce other parsing bugs that were fixed. None of which are good options. Is there a better way to reach out to the users of Parse::RecDescent to get them to update their modules to use the standalone parsing feature(s)? Did you just search rt.cpan.org for "Parse::RecDescent" and fails, or am I not on a critical mailing list where these are getting discussed? Jeremy On Thu Mar 01 23:16:19 2012, PLOBBES wrote: Show quoted text
for Show quoted text

On Fri Mar 02 16:59:35 2012, phil@perkpartners.com wrote: Show quoted text
You might want to look at this list: http://deps.cpantesters.org/depended-on-by.pl?module=Parse%3A%3ARecDescent It includes all distributions that depend on Parse::RecDescent. They would have to be tested individually to see whether they are broken by the new release.

On Tue Mar 13 00:22:57 2012, jtbraun wrote: Show quoted text
I spoke too soon. Two things happened: 1.966_002 introduced some extra arguments to internal rules/functions (this was probably the first break). I think that this is easily fixed by swapping the argument ordering around. Recent namespace cleanup improvements cause instances of precompiled parsers to delete their own namespaces (preventing future parse calls). This is typically guarded against by precompiled parsers setting their $self->{_precompiled} flag. For some reason Module::ExtractUse doesn't have this flag set, likely M::EU pre-dates this change to P::RD. I can add an extra guard around that, and more of the test cases begin to work. I'll work through the rest of the failures this week and see if I can come up with a comprehensive strategy for fixing these errors, as well as providing some sort of warning to users of modules dependent on Parse::RecDescent that older precompiled modules will break in the future. Jeremy

Hi Peter, thank you for your patience while I got back to you. First off, let me assure you that I have no interest in breaking current uses of P::RD. I have every intention of preserving the current behavior of the module, while improving the interface and performance. I would recommend against using the current version (v1.967009) of standalone parsers with SQL::Translator. The standalone parsers generated with this version will end up including most of P::RD as the package Parse::RecDescent::_Runtime. This works to isolate your module from future changes to P::RD, and against past implementations of P::RD. But if your user 'use's your precompiled parser with someone else's precompiled parser, they will end up with numerous redefinitions of functions in the "Parse::RecDescent::_Runtime" namespace. Annoying. I've pushed some modifications to the standalone precompiled parser generator (https://github.com/jtbraun/Parse-RecDescent/commit/21f9ad82aba94ee05b806b4e99f21e6d1dc47e4b) to github. It allows you to do two things: 1. Declare the package name where P::RD's internals are copied to, so that it avoids the redefinition problem above. 2. Change the name of the Parse::RecDescent dependencies to the package from (1), without including P::RD. This will be of particular interest to you, as you'll want to include a single copy of the P::RD run-time as SQL::Translator::ParseRD::_Runtime (or equivalent), as well as reference that package from each of your parsers. I'd appreciate your assistance in vetting this feature, as SQL::Translator is the only module I know of that would be shipping multiple pre-compiled parsers. t2: My intention is that precompiled _standalone_ parsers should be 100% independent of the P::RD installed on the system. Standalone parsers should not 'use' or 'require' P::RD. The only dependencies will be on: 1. The P::RD installed on the module maintainer's machine when they compile the standalone parser. 2. The P::RD installed on the user's machine at module build/install time, when that module's build process creates the standalone parsers. I do not believe that there is currently a way to determine which version of P::RD precompiled a given parser. I've filed RT#77001 to track adding this. No worries about re-opening the ticket. I'm excited to see P::RD improve, and I'm rather embarrassed that I broke so many modules by changing the calling convention of &_parserepeat. I _REALLY_ appreciate any testing help or suggestions you can provide to ensure that my and your users are not adversely impacted by the changes I'm making to P::RD. Please take a look at the most recent changes to P::RD on github, and let me know if the interface works for you. Once we agree on an implementation, I'll push out a release on PAUSE. Jeremy On Sat Apr 28 11:26:43 2012, RIBASUSHI wrote: Show quoted text