Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the PPI CPAN distribution.

Report information
The Basics
Id: 30448
Status: resolved
Priority: 0/
Queue: PPI

People
Owner: Nobody in particular
Requestors: jgangemi [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: ppi enhancements for use as eclipse editor parser
hello - i am interested in using PPI as the underlying parser implementation for an eclipse plugin that i am working on. my previous attempts at contact through email have gone unanswered, and i though i would try this route given the recent activity on the project. i have a basic implementation working, but i am noticing some performance issues with large/complex files (Twig.pm for example, takes 5-6 seconds to process). i also had to make some modifications to the PPI source to make my life slightly easier (calculating document offsets when indexing locations). i output the pdom document as xml that i am deserializing into classes on the eclipse side that will represent the document. i wanted to contact you to start a dialog and perhaps pick your brain and discuss what may and may not be possible to accomplish using PPI as the underlying parser.
From: cpan [...] chrisdolan.net
Have you looked at http://e-p-i-c.sourceforge.net/ yet? That's the leading Perl plugin for Eclipse. I don't think they use PPI, but they;ve already built a ton of Perl-specific features for Eclipse. It would be VERY useful if you were to try to incorporate your work into the groundwork they have already laid. I think what you're going to want to do to help performance is to parse just fragments of documents at a time instead of whole documents. Chris On Sat Nov 03 15:03:11 2007, JAE wrote: Show quoted text
> hello - > > i am interested in using PPI as the underlying parser implementation > for an eclipse plugin that i am working on. my previous attempts at > contact through email have gone unanswered, and i though i would try > this route given the recent activity on the project. > > i have a basic implementation working, but i am noticing some > performance issues with large/complex files (Twig.pm for example, takes > 5-6 seconds to process). i also had to make some modifications to the > PPI source to make my life slightly easier (calculating document offsets > when indexing locations). i output the pdom document as xml that i am > deserializing into classes on the eclipse side that will represent the > document. > > i wanted to contact you to start a dialog and perhaps pick your brain > and discuss what may and may not be possible to accomplish using PPI as > the underlying parser. >
Subject: Re: [rt.cpan.org #30448] ppi enhancements for use as eclipse editor parser
Date: Sun, 4 Nov 2007 22:04:00 +1100
To: bug-PPI [...] rt.cpan.org
From: "Adam Kennedy" <adamkennedybackup [...] gmail.com>
Email me directly at adamk@cpan.org... I'm not sure why your email there wouldn't be getting through... As for using PPI in Eclipse, speed will be the biggy, it's relatively slow, and not really suitable for real-time processing. On 04/11/2007, Jae Gangemi via RT <bug-PPI@rt.cpan.org> wrote: Show quoted text
> > > Sat Nov 03 15:03:11 2007: Request 30448 was acted upon. > Transaction: Ticket created by JAE > Queue: PPI > Subject: ppi enhancements for use as eclipse editor parser > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: jae@gmail.com > Status: new > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=30448 > > > > hello - > > i am interested in using PPI as the underlying parser implementation > for an eclipse plugin that i am working on. my previous attempts at > contact through email have gone unanswered, and i though i would try > this route given the recent activity on the project. > > i have a basic implementation working, but i am noticing some > performance issues with large/complex files (Twig.pm for example, takes > 5-6 seconds to process). i also had to make some modifications to the > PPI source to make my life slightly easier (calculating document offsets > when indexing locations). i output the pdom document as xml that i am > deserializing into classes on the eclipse side that will represent the > document. > > i wanted to contact you to start a dialog and perhaps pick your brain > and discuss what may and may not be possible to accomplish using PPI as > the underlying parser. > > >
On Sat Nov 03 20:45:09 2007, CDOLAN wrote: Show quoted text
> Have you looked at http://e-p-i-c.sourceforge.net/ yet? That's the > leading Perl plugin for Eclipse. I don't think they use PPI, but > they;ve already built a ton of Perl-specific features for Eclipse. It > would be VERY useful if you were to try to incorporate your work into > the groundwork they have already laid. > > I think what you're going to want to do to help performance is to parse > just fragments of documents at a time instead of whole documents.
the project i am working for leverages the dynamic languages toolkit that is being developed by eclipse (i am also a committer on the project). i am in need of an editor that supports the dbgp protocol for debugging and i am not interested in using komodo. the e-p-i-c plugin wouldn't be able to provide this functionality w/o some serious re-work, and last time i checked, the current maintainer wasn't interested.
email sent, let me know if you don't receive it. On Sun Nov 04 06:04:26 2007, adamkennedybackup@gmail.com wrote: Show quoted text
> Email me directly at adamk@cpan.org... I'm not sure why your email there > wouldn't be getting through... > > As for using PPI in Eclipse, speed will be the biggy, it's relatively
slow, Show quoted text
> and not really suitable for real-time processing. > > > > On 04/11/2007, Jae Gangemi via RT <bug-PPI@rt.cpan.org> wrote:
> > > > > > Sat Nov 03 15:03:11 2007: Request 30448 was acted upon. > > Transaction: Ticket created by JAE > > Queue: PPI > > Subject: ppi enhancements for use as eclipse editor parser > > Broken in: (no value) > > Severity: (no value) > > Owner: Nobody > > Requestors: jae@gmail.com > > Status: new > > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=30448 > > > > > > > hello - > > > > i am interested in using PPI as the underlying parser implementation > > for an eclipse plugin that i am working on. my previous attempts at > > contact through email have gone unanswered, and i though i would try > > this route given the recent activity on the project. > > > > i have a basic implementation working, but i am noticing some > > performance issues with large/complex files (Twig.pm for example, takes > > 5-6 seconds to process). i also had to make some modifications to the > > PPI source to make my life slightly easier (calculating document offsets > > when indexing locations). i output the pdom document as xml that i am > > deserializing into classes on the eclipse side that will represent the > > document. > > > > i wanted to contact you to start a dialog and perhaps pick your brain > > and discuss what may and may not be possible to accomplish using PPI as > > the underlying parser. > > > > > >
From: cpan [...] chrisdolan.net
On Sun Nov 04 11:35:59 2007, JAE wrote: Show quoted text
> the project i am working for leverages the dynamic languages toolkit > that is being developed by eclipse (i am also a committer on the > project). i am in need of an editor that supports the dbgp protocol for > debugging and i am not interested in using komodo. > > the e-p-i-c plugin wouldn't be able to provide this functionality w/o > some serious re-work, and last time i checked, the current maintainer > wasn't interested.
Got it, I see. I've never delved into the EPIC source code, so I didn't know what it was using on the inside. I already use Eclipse for Java, Groovy and C++, so any improvements to the Perl support would be VERY welcome. I lack time to help with coding, but let me know if you need help testing. If you get far enough along, I'd be willing to help with Perl::Critic integration. Chris
This is old, and big performance improvements on PPI were released recently, so i am closing this. Feel free to poke us on github for any further changes you'd like to see. I promise we'll react faster this time. :)