[perl #59862] [TODO][PIRC] Fix Makefile for compilers/pirc

# New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #59862] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=59862 > Recently I updated config/gen/makefiles/pirc.in to generate a Makefile for the macro,

Parrot Bug Summary

Parrot Bug Summary http://rt.perl.org/rt3/NoAuth/parrot/Overview.html Generated at Mon Oct 13 13:00:01 2008 GMT --- * Numbers * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with m

Re: [perl #44457] [TODO] make sure files match test files for DYNPMCs and DYNOPs etc

--- El mié 8-oct-08, Christoph Otto <[EMAIL PROTECTED]> escribió: De:: Christoph Otto <[EMAIL PROTECTED]> Asunto: Re: [perl #44457] [TODO] make sure files match test files for DYNPMCs and DYNOPs etc A: "Igor" <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Fecha: miércoles, 8 octubre, 2008, 11:17 pm

Re: Modules

Moritz (>): > [...] > > Most perl hackers agree that the parameter parsing and the HTML > generation part of perl 5's CGI.pm should be split up into two modules, > because they are only weakly coupled, and if you use only of them the > other half is bloat for you. There is previous discussion on p

[perl #59870] Tcl/Glob.pbc broken in head

# New Ticket Created by Will Coleda # Please include the string: [perl #59870] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=59870 > Tcl/Glob (which happens to be used only by Tcl at the moment, but provides a glob-style i

Re: [perl #59830] [PROPOSAL][PDD19] Split .line directive into separate .line and .file directives.

On Mon, Oct 13, 2008 at 2:10 AM, Andrew Whitworth <[EMAIL PROTECTED]>wrote: > On Sun, Oct 12, 2008 at 9:27 AM, via RT Klaas-Jan Stol > <[EMAIL PROTECTED]> wrote: > > currently, the .line directive takes both an integer (for line number) > and a > > string (for filename) argument. > > I propose to

Re: Store captures and non-captures in source-string order

On Sun, Oct 12, 2008 at 05:34:49PM +0200, Moritz Lenz wrote: : Patrick R. Michaud wrote: : > On Sun, Oct 12, 2008 at 11:44:05AM +0200, Moritz Lenz wrote: : >> When we write regexes, we generally capture stuff in a way that makes : >> the following semantic analysis easier. For example we could have

Re: Store captures and non-captures in source-string order

Or maybe we're not thinking big enough here. Maybe we're looking at a generalized tree query language that, as limiting cases, defines the .splits and .allsplits as (re)linearized query results, where .splits linearizes the top level nodes, and .allsplits linearizes the leaves, but may intermediat

Re: Store captures and non-captures in source-string order

* Larry Wall <[EMAIL PROTECTED]> [2008-10-13 19:00]: > Maybe we're looking at a generalized tree query language That’s an intriguing observation. Another case for having some XPath-ish facility in the language? Regards, -- Aristotle Pagaltzis //

[perl #59874] t/op/arithmetics.t test 27 fails on 32-bit Intel OS X build in r31926

# New Ticket Created by "Seneca Cunningham" # Please include the string: [perl #59874] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=59874 > Test 27 of t/op/arithmetics.t fails when parrot is built as a 32-bit binary on In

[perl #52478] [BUG] unwanted string -> int conversion for array-like PMCs

On Tue Apr 08 19:11:10 2008, pmichaud wrote: > On Fri, Apr 04, 2008 at 02:15:26PM -0700, Christoph Otto (Volt) wrote: > > When running the following PIR code, Parrot does the Perlish thing > > and implicitly converts s to an int. This violates the principle > > of least surprise and makes it unn

[perl #59880] DOD crash in r31926, t/op/bitwise.t #27 on linux/x86_64

# New Ticket Created by Mark Glines # Please include the string: [perl #59880] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=59880 > This GDB was configured as "x86_64-pc-linux-gnu"... (gdb) run t/op/bitwise_27.pir Startin

[perl #59876] Test 2 of t/native_pbc/header.t fails on 64-bit Intel OS X builds in r31926

# New Ticket Created by "Seneca Cunningham" # Please include the string: [perl #59876] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=59876 > Test 2 of t/native_pbc/header.t passes 32-bit Intel OS X builds (10.5) but fails

[perl #59886] Segfault in pcre.t

# New Ticket Created by Moritz Lenz # Please include the string: [perl #59886] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=59886 > Hello, with r31926 the pcre.t tests fails due to a segfault: (gdb) run pcre.pir Startin

Re: [perl #59880] DOD crash in r31926, t/op/bitwise.t #27 on linux/x86_64

On Monday 13 October 2008 13:11:45 Mark Glines wrote: > This GDB was configured as "x86_64-pc-linux-gnu"... > (gdb) run t/op/bitwise_27.pir > Starting program: /work/parrot-dev/parrot-trunk/parrot > t/op/bitwise_27.pir > [Thread debugging using libthread_db enabled] > warning: Lowest section in /u

Re: [perl #59546] [PATCH] Combine hash exists/get into a new opcode (5% performance gain)

On Thursday 02 October 2008 07:35:09 NotFound wrote: > I think will be better the other way, using the return value to flag > existence, and passing a pointer to store the result. This will allow > shorter and cleaner code. A 5% improvement in some subsystems is nice, but nothing else uses out p

Re: [perl #58852] [PATCH] enhance tools/install/smoke.pl

On Sunday 14 September 2008 07:05:26 Reini Urban wrote: > Enhance tools/install/smoke.pl to test already installed parrot by using > %PConfig and a DESTDIR arg for a temporary installation. Thanks, applied as r31931. -- c

Re: [perl #58460] [PATCH] Bug with ResizablePMCArray::Append

On Friday 29 August 2008 21:47:41 Stephen Weeks wrote: > I tried using resizablepmcarray's append() in cardinal and I got 'double > fre or corruption' on program exit. > > I tried to fix it, but I'm not sure about GC issues. > > As far as I can tell, the attached shouldwork.patch (which adds > GC_

Re: [perl #56622] [BUG?] 'isa' opcode returns inconsistent results

On Saturday 05 July 2008 11:58:07 Patrick R. Michaud (via RT) wrote: > This one takes a bit of lengthy explanation, but the bottom > line is that the 'isa' opcode can returns different results > when given a String PMC versus a string register or constant. I can't reproduce that as of r31933, but

Re: [perl #59886] Segfault in pcre.t

On Monday 13 October 2008 14:23:21 Moritz Lenz wrote: > with r31926 the pcre.t tests fails due to a segfault: > > (gdb) run pcre.pir > Starting program: /home/moritz/src/parrot/parrot pcre.pir > [Thread debugging using libthread_db enabled] > [New Thread -1232648512 (LWP 21873)] > warning: Lowest

Re: [perl #59886] Segfault in pcre.t

chromatic wrote: > On Monday 13 October 2008 14:23:21 Moritz Lenz wrote: > >> with r31926 the pcre.t tests fails due to a segfault: >> >> (gdb) run pcre.pir >> Starting program: /home/moritz/src/parrot/parrot pcre.pir >> [Thread debugging using libthread_db enabled] >> [New Thread -1232648512 (LWP

Re: [perl #59544] open(null) kills parrot

NotFound wrote: Where to put a test for this? There is no t/ops/io.t and creating a file for each io opcode seems excessive Create a t/ops/io.t. We'll add to it in the I/O milestone (the next one on the list, which I'll create a branch for later this week). Allison