Chris,
Thanks for your comments, I'm still trying to hone my perl abilities
and I really appreciate your feedback. I certainly need help
sometimes with my regular expressions...
A few comments:
* No, this shouldn't go into UseParrotCoda. Separately enabled
policies are more flexible.
Actua
Chris,
This one is still a false negative on "#!perl -Tw" and is a false positive
on "package main; #!!! my co-worker provided this non-Perl-licensed code to
Parrot!!!". Yes, that's a highly contrived example. :-) But the false
positive would be avoidable by checking the line and column numbe
> To remove the deprecated C opcode does one simply remove
> the references to it in src/ops/object.ops (and other .ops files), and
> remove the function from src/ops/ops.num? Does one then move all of
> the ops numbers "up" so that there isn't a gap caused by removing the
> opcodes? Is this rel
No problem with the two patch files.
Could you add the patches for the amber *.pmc ?
Attached to this email. Odd that I missed those files before...
Regards,
Paul
files affected:
languages/amber/lib/kernel/pmc/amber_character.pmc
languages/amber/lib/kernel/pmc/amber_integer.pmc
languages/amb
On 10/9/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
Smylers wrote:
> To be consistent your proposal should also suggest that these become
> equivalent:
>
> * "{ function() }"
> * qq[ {function() }]
> * qq{ function() }
> * eval "function()"
How so? AFAIK, string literal syntax requires you to
Markus Laire wrote:
According to S02 bare curlies do interpolate in double-quoted strings:
Yeah; that was subsequently pointed out to me. Oops.
--
Jonathan "Dataweaver" Lang
At 18:52 07/10/2006 -0400, Bob Rogers wrote:
From: François PERRAD <[EMAIL PROTECTED]>
Date: Wed, 04 Oct 2006 08:55:34 +0200
I've tried without success to implement coroutine in language Lua . . .
Help is welcome.
François.
I am not surprised that you have had difficulty. I can
Hi Mehmet,
you might have run into a Garbage-Collector bug. Try
parrot --no-gc main.pir 'x' 'identifier'
I had similar problems using PGE::P6Regex. '--no-gc' helped.
Regards,
Kiwi
Hi Mehmet,
you might have run into a Garbage-Collector bug. Try
parrot --no-gc main.pir 'x' 'identifier'
I had similar problems using PGE::P6Regex. '--no-gc' helped.
Regards,
Kiwi
The same problem.
I think that I now know the problem: the grammar is not complete. I
was thinking that pgc
On Oct 10, 2006, at 3:12 AM, Paul Cochrane wrote:
* This would be a nice addition to core Perl::Critic!
Do you want me to supply a patch for Perl::Critic too, or will the
file added to Parrot suffice?
That's completely up to you. You seem to have a knack for writing
policies, so we'd lov
HaloO,
Darren Duncan wrote:
Within a system that already has an underlying set-like type, the
Junction in this case, a test for uniqueness is (pardon any spelling):
all(@items).elements.size === @items.size
The all() will strip any duplicates, so if the number of elements in
all(@items) is
Chris,
This one is still a false negative on "#!perl -Tw" and is a false positive
on "package main; #!!! my co-worker provided this non-Perl-licensed code to
Parrot!!!". Yes, that's a highly contrived example. :-) But the false
positive would be avoidable by checking the line and column numbe
Chris,
Attached are three new P::C policies for Parrot:
prohibit_shebang_warnings_arg.patch: checks for C
misplaced_shebang.patch:checks for shebang not on
first line of script
require_portable_shebang.patch:checks for non-portable shebang line
That's complete
On Oct 10, 2006, at 11:03 AM, Paul Cochrane wrote:
I've been playing around for a while with the shebang line tests, and
it struck me that the is_script() function will return true on your
contrived example.
Yeah, I saw that and fixed it in SVN yesterday. :-) It now checks
that column == 1
Hi all,
Here's an experiment I worked on yesterday to make creating objects a little
easier from PIR. The MakeObject library allows you to create an object by
passing its name (or, more usefully, a Key PMC) and a set of named arguments
to the initializer.
It then calls the class's BUILDALL()
Author: larry
Date: Tue Oct 10 11:57:24 2006
New Revision: 13014
Modified:
doc/trunk/design/syn/S03.pod
Log:
For hypers, break out dimensional dwimmery from ordinary shape processing.
Dwimming hyperinfixes now point the small end at the "runt".
Unaries never dwim. :)
Modified: doc/trunk/des
Author: larry
Date: Tue Oct 10 12:10:23 2006
New Revision: 13015
Modified:
doc/trunk/design/syn/S03.pod
Log:
Forgot to update version and date.
Also forgot to mention self-extending lists using *. :)
Modified: doc/trunk/design/syn/S03.pod
=
Author: larry
Date: Tue Oct 10 12:16:52 2006
New Revision: 13016
Modified:
doc/trunk/design/syn/S03.pod
Log:
Clarified dwimminess relationship to * list extension.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/tr
On Sun, Oct 08, 2006 at 04:07:37PM +0200, Juerd wrote:
: S03 says that hypers recurse into subarrays.
:
: That's a nice and useful feature, but that not-recursing is even more
: useful. Especially given that many objects will probably does Array, you
: want to be explicit about recursion.
:
: S0
Author: larry
Date: Tue Oct 10 13:09:12 2006
New Revision: 13019
Modified:
doc/trunk/design/syn/S03.pod
Log:
typo from wolverian++
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(or
[EMAIL PROTECTED] skribis 2006-10-09 0:22 (-0700):
> P5's s[pat][repl] syntax is dead, now use s[pat] = "repl"
Why keep the s?
substr works perfectly as both rvalue and lvalue, and I think m[], also
known as //, can do the same. No need to do things based on delimiter
(bracket versus non-bracket
On Tue, Oct 10, 2006 at 10:49:11PM +0200, Juerd wrote:
: [EMAIL PROTECTED] skribis 2006-10-09 0:22 (-0700):
: > P5's s[pat][repl] syntax is dead, now use s[pat] = "repl"
:
: Why keep the s?
Because @Larry felt it was better to keep the intent out in front.
: substr works perfectly as both rvalu
On Tue, Oct 10, 2006 at 02:17:50PM -0700, Larry Wall wrote:
: $str ~~ s(/pat) = "replacement";
Er, cut-n-paste error. Make that:
$str ~~ s[pat] = "replacement";
Larry
The example in S05 under "Subpattern numbering" isn't quite complex
enough to give the reader a full understanding of the ramifications of
the re-numbering that occurs with alternations, especially with respect
to the combination of capturing and non-capturing subpatterns. I've
written a small
At 4:08 PM +0200 10/10/06, TSa wrote:
HaloO,
Darren Duncan wrote:
Within a system that already has an underlying set-like type, the
Junction in this case, a test for uniqueness is (pardon any
spelling):
all(@items).elements.size === @items.size
The all() will strip any duplicates, so if t
On Tuesday 10 October 2006 12:23, Leopold Toetsch wrote:
> PPS: new opcode variant count is 20 now.
>
> I can imagine that we just have these:
>
> new P0, .Class # plain form
> new P0, .Class,
> new P0, [class],
Is a PMC (Hash) or a list of named arguments? Creating a Hash
Am Dienstag, 10. Oktober 2006 20:41 schrieb chromatic:
> Hi all,
>
> Here's an experiment I worked on yesterday to make creating objects a
> little easier from PIR.
For reference:
Subject: PMC and object creation
http://groups.google.de/group/perl.perl6.internals/browse_frm/thread/e68dc0a0a96585b7
Am Dienstag, 10. Oktober 2006 21:32 schrieb chromatic:
> > new P0, [class],
>
> Is a PMC (Hash) or a list of named arguments? Creating a Hash for
> every initializer is a real bummer in PIR.
As said, ought to be everything conforming to current calling
conventions.
o = new .TypeId, 1, 'b
From: François PERRAD <[EMAIL PROTECTED]>
Date: Tue, 10 Oct 2006 13:39:30 +0200
Thank for your long response.
I included your code in languages/lua/lib/luacoroutine.pir (r14877).
I encountered 2 problems :
1) coroutine_yield needs a current coroutine (not surprising)
Yes, this
Hi all,
In doing a bit of work with traits (roles) in Perl 5
(http://perlmonks.org/?node_id=577477), I've realized some edge cases
which could be problematic.
First, when a role is applied to a class at runtime, a instance of that
class in another scope may specifically *not* want that role. Is
Author: larry
Date: Tue Oct 10 16:55:33 2006
New Revision: 13022
Modified:
doc/trunk/design/syn/S03.pod
Log:
Clarification of non-ambiguity of «*»
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S0
TSa wrote:
TSa wrote:
Note that the superclass interface of roles should be mostly inferred
from the usage of next METHOD. As such it is a useful guidance for
error reports in the class composition process.
Actually 'next METHOD' doesn't catch all superclass interface issues.
There is the simp
Brad Bowman wrote:
TSa wrote:
> TSa wrote:
>> Note that the superclass interface of roles should be mostly inferred
>> from the usage of next METHOD. As such it is a useful guidance for
>> error reports in the class composition process.
>
> Actually 'next METHOD' doesn't catch all superclass inte
TSa wrote:
Jonathan Lang wrote:
> TSa wrote:
> > Dispatch depends on a partial ordering of roles.
>
> Could someone please give me an example to illustrate what is meant by
> "partial ordering" here?
In addition to Matt Fowles explanation I would like to
give the following example lattice build
Author: coke
Date: Tue Oct 10 19:16:37 2006
New Revision: 14888
Modified:
trunk/docs/pdds/clip/pddXX_cstruct.pod (props changed)
trunk/docs/pdds/clip/pddXX_pmc.pod (props changed)
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
trunk/apps/p3/README
35 matches
Mail list logo
