On Saturday 12 July 2008 14:01:17 [EMAIL PROTECTED] wrote:
> Added:
>trunk/t/op/lexicals-2.t (contents, props changed)
> Modified:
>trunk/MANIFEST
>
> Log:
> * t/op/lexicals-2.t (added), MANIFEST:
>+ Add three more lexical tests, pursuant to RT#56398. The second is
> "todo", wi
HaloO,
I know that the hot phase of the operator discussions are over.
But here's a little orthogonalizing idea from my side. The observation
is that * can be regarded as repeated addition: 5 * 3 == 5 + 5 + 5
and ** as repeated multiplication. Now imagine having a meta_postfix:<*>
that gives +* as
On Mie. Mar. 14 11:46:38 2007, [EMAIL PROTECTED] wrote:
> I keep getting a test failure on t/op/stringu.t with test 25 on
> ppc-darwin(and likely all big endian systems with icu installed).
> Parrot outputs "\x00A\x00B" when the test expects "A\x00B\x00" to be
> printed.
Is this still a proble
2008/7/12 Bob Rogers <[EMAIL PROTECTED]>:
> 9 days and no complaints; done.
>
When the coda is added by the generator, that's fine.
But MANIFEST is generated (with MANIFEST.SKIP)
and MANIFEST.generated is not a generated file (but the file that contains
all the generated/built files that could
On Thu Feb 21 13:52:31 2008, coke wrote:
> On Fri Nov 02 07:56:44 2007, particle wrote:
> > as per PDD07 (r22655,) c macro args *must* be wrapped in parens inside
> > macro bodies, to allow expressions passed as macro parameters.
> >
> > for example, i expect:
> > #define CLASS_has_alien_parents_
# New Ticket Created by Will Coleda
# Please include the string: [perl #56892]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56892 >
Working on this, I see that we have a ^L before the coda in quite a
few files in, e.g.:
On Sunday 13 July 2008 09:33:31 Will Coleda wrote:
> Working on this, I see that we have a ^L before the coda in quite a
> few files in, e.g.: tools/build/; This isn't Tidy.
>
> ISTR this was done purposefully. Anyone remember why?
Emacs needs its read-only marking in the final logical page of t
So you're suggesting that
A op* n
should map to
[op] A xx n
?
--
Jonathan "Dataweaver" Lang
# New Ticket Created by Will Coleda
# Please include the string: [perl #56894]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56894 >
If you upgrade to Perl::Critic 1.088, you'll start seeing the
following warnings on this
On Sun, Jul 13, 2008 at 12:56 PM, chromatic <[EMAIL PROTECTED]> wrote:
> On Sunday 13 July 2008 09:33:31 Will Coleda wrote:
>
>> Working on this, I see that we have a ^L before the coda in quite a
>> few files in, e.g.: tools/build/; This isn't Tidy.
>>
>> ISTR this was done purposefully. Anyone r
# New Ticket Created by Will Coleda
# Please include the string: [perl #56896]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56896 >
The following directories are empty in the svn repo. We should remove
them and verify tha
This problem is fixed by other similar problem whose ticket was not
linked to this. r29358 unskip the test.
Closing ticket.
Will Coleda (via RT) schrieb:
# New Ticket Created by Will Coleda
# Please include the string: [perl #56894]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56894 >
The P::C author recommends we ditch the syntax 'use 5.008
Hi,
I'm reviewing the tests in S09, and the file
t/spec/S02-builtin_data_types/multi_dimensional_array.t uses the [0][0]
indexing format interchangeably with [0;0].
These two formats mean two different things, correct? The [0][0] form isn't
mentioned much in the spec, nor is [0;0] or if they
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #56900]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56900 >
I read ROADMAP again the other day, and thought about topics that we
could offer new hack
Two of the three directories were left over from earlier development of
testing of configuration steps, so I was familiar with them. The third
had apparently last been used > 20K revisions ago, in the long distant
past of 2005.
3 directories removed. Ticket marked resolved.
kid51
From: chromatic <[EMAIL PROTECTED]>
Date: Sun, 13 Jul 2008 00:39:38 -0700
On Saturday 12 July 2008 14:01:17 [EMAIL PROTECTED] wrote:
> Added:
>trunk/t/op/lexicals-2.t (contents, props changed)
> Modified:
>trunk/MANIFEST
>
> Log:
> * t/op/lexicals-2.t (adde
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Sun, 13 Jul 2008 18:34:32 -0400
I must have messed up; for some reason, I thought this was on
chromatic's hit list. Fixed in revision 29408.
Er, I mean 29409.
-- Bob
On Sunday 13 July 2008 15:27:10 Bob Rogers wrote:
> I'm open to suggestions.
>
>(I'm not sure it needs to be a separate file.)
>
> At the time, I was thinking that having a separate file for longer cases
> was a good idea. But "prove t/op/lexicals.t" takes only 4s on my
> machine, so I guess
On Sat, Jul 12, 2008 at 11:00:29AM -0700, James Keenan via RT wrote:
> On Sat Jul 12 09:33:35 2008, coke wrote:
> >
> > Another solution here would be to not run them by default. The purpose
> > of 'make test'
> > should be to verify that the parrot functionality works on the target
> > system.
>
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Wed, 9 Jul 2008 01:27:29 -0400
Oops; r28763 seems to be the source of one of my problems, a "lexical
not found" error. With this change, Parrot gets confused when multiple
calls to the :outer sub have been made, such as when it is recursiv
On Fri Jul 11 09:41:21 2008, julianalbo wrote:
>
> There is a problem with the autogenerated name: in several cases there
> are other things with that name. For example, for the float.pmc we
> have the Parrot_Float type defined in include/parrot/config.h
>
> Given that the name will be mainly use
On Saturday 12 July 2008 21:52:52 Christoph Otto via RT wrote:
> The test now passes, although I'll leave this ticket open until someone
> can confirm that it still does the right thing.
>
> The new version of t/codingstd/c_macro_args.t as of r29372 has several
> special cases: stringification, co
23 matches
Mail list logo
