Skip Menu |
 

This queue is for tickets about the Devel-Declare CPAN distribution.

Report information
The Basics
Id: 47544
Status: resolved
Priority: 0/
Queue: Devel-Declare

People
Owner: Nobody in particular
Requestors: zefram [...] fysh.org
Cc:
AdminCc:

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



Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by diesel.bestpractical.com (Postfix) with SMTP id C5A6019B8282 for <bug-Devel-Declare [...] rt.cpan.org>; Fri, 3 Jul 2009 10:42:49 -0400 (EDT)
Received: (qmail 1821 invoked by uid 103); 3 Jul 2009 14:42:49 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 3 Jul 2009 14:42:49 -0000
Received: from pond.fysh.org (HELO pond.fysh.org) (166.84.7.109) by 16.mx.develooper.com (qpsmtpd/0.80) with ESMTP; Fri, 03 Jul 2009 07:42:43 -0700
Received: from zefram by pond.fysh.org with local (Exim 4.69 #1 (Debian)) id 1MMjyH-0006Ar-N8; Fri, 03 Jul 2009 15:42:37 +0100
Delivered-To: cpan-bug+Devel-Declare [...] diesel.bestpractical.com
MIME-Version: 1.0
Subject: toke_scan_str multiline fail
X-Spam-Status: No, hits=0.0 required=8.0 tests=
Return-Path: <zefram [...] fysh.org>
X-Spam-Check-BY: 16.mx.develooper.com
X-Original-To: bug-Devel-Declare [...] rt.cpan.org
Content-Disposition: inline
Date: Fri, 3 Jul 2009 15:42:37 +0100
X-Spam-Level: *
X-Virus-Checked: Checked by ClamAV on 16.mx.develooper.com
Content-Type: multipart/mixed; boundary="2fHTh5uZTiUOsy+g"
Message-ID: <20090703144237.GA22936 [...] fysh.org>
To: bug-Devel-Declare [...] rt.cpan.org
From: Zefram <zefram [...] fysh.org>
Content-Length: 0
content-type: text/plain; charset="utf-8"
Content-Disposition: inline
X-RT-Original-Encoding: us-ascii
Content-Length: 594
Download (untitled) / with headers
text/plain 594b
The attached test script illustrates some ways in which I've seen toke_scan_str fail when parsing across multiple lines. I get these test results: single_with_filler: success (this is the control case) single_no_filler: forced to realloc PL_linestr (not a multiline issue) newline0: suprising len=-12 newline1: suprising len=-11 newline2: success newline3: success three_line: content length doesn't match len The newline-related faults occur when parsing code from a file or from -e, but not in a string eval. Hence the test script puts the code under test into a temporary file. -zefram
Content-Type: application/x-troff
content-disposition: attachment; filename="scanstr_test.t"
Content-Transfer-Encoding: quoted-printable
Content-Length: 2348
Download scanstr_test.t
text/x-perl 2.2k

Message body is not shown because sender requested not to inline it.

MIME-Version: 1.0
In-Reply-To: <20090703144237.GA22936 [...] fysh.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <20090703144237.GA22936 [...] fysh.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-20564-1315737261-1862.47544-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 158
Download (untitled) / with headers
text/plain 158b
Think I was mistaken about how toke_scan_str is meant to be used. It *is* damned confusing, but it can be used correctly (as I do in ork codebase). -zefram
MIME-Version: 1.0
In-Reply-To: <20090703144237.GA22936 [...] fysh.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <20090703144237.GA22936 [...] fysh.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-20561-1315752395-732.47544-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 158
Download (untitled) / with headers
text/plain 158b
On third thoughts: actually the way I use it correctly at work is to not use toke_scan_str but to reimplement it by char-by-char parsing. There is a problem.
MIME-Version: 1.0
In-Reply-To: <20090703144237.GA22936 [...] fysh.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <20090703144237.GA22936 [...] fysh.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-20559-1315854441-903.47544-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 55
Fixed in Devel-Declare 0.006007, just uploaded to CPAN.


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.