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: 64747
Status: resolved
Priority: 0/
Queue: PPI

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

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



Subject: Large __DATA__ sections quickly hit source code size limit
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 489
Download (untitled) / with headers
text/plain 489b
The hard-coded limit of 1048576 bytes for source code (in PPI::Tokenizer) is easily tripped by a small source file with a large __DATA__ section. It would be nice if one of the following things cold be done: * Replace the hard-coded 1048576 byte limit with something that can be overridden with an environment variable or package-scoped variable or something. ...or... * Disregard __DATA__ sections when enforcing source code size limits. ...or perhaps you could do both. Thanks.
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-18809-1305905753-1707.64747-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 742
Download (untitled) / with headers
text/plain 742b
On Thu Jan 13 09:59:40 2011, JSIRACUSA wrote: Show quoted text
> The hard-coded limit of 1048576 bytes for source code (in > PPI::Tokenizer) is easily tripped by a > small source file with a large __DATA__ section. It would be nice if > one of the following things > cold be done: > > * Replace the hard-coded 1048576 byte limit with something that can be > overridden with an > environment variable or package-scoped variable or something. > > ...or... > > * Disregard __DATA__ sections when enforcing source code size limits. > > ...or perhaps you could do both. Thanks.
This is also problem for something I'm working on. I'm not sure how this limit was determined. For yucks, I changed it and ran the code using PPI (a dzil plugin). It worked fine.
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-18809-1305905753-1707.64747-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <rt-3.8.HEAD-18809-1305905753-1707.64747-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-16558-1338901624-1272.64747-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 168
Download (untitled) / with headers
text/plain 168b
I would like to use PPI to strip off all POD and comments from a fatpacked (App::FatPacker) file to achieve a smaller size, but the hard coded limit prevents this...
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-7819-1408219519-1679.64747-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 144
Download (untitled) / with headers
text/plain 144b
With the latest release of PPI this limit has been removed: https://metacpan.org/release/PPI Please let me know if you have further issues. :)


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.