Hi,
I've tracked the bug down some and ci'd a workaround for this tonight,
with a comment that some more digging maybe is wanted in the future. But
it solves the problem just fine at the moment.
Jonathan
Hi~
lanny noticed yesterday that the Synopses on the smoke server were
different from the ones on feather. Because I am maintaining the
feather ones, I know the synopses there are being resync'd every hour
as expected.
As of this writing, the feather synopses are at r12466 while the ones
on the
Trey Harris wrote:
In a message dated Wed, 27 Sep 2006, Aaron Sherman writes:
Any thoughts?
I'm still thinking about the practical implications of this... but
what immediately occurs to me:
The point of multiple, as opposed to single, dispatch (well, one of
the points, and the only point t
Minor nitpick:
Any types used will constrain multis to explicitly matching those types
or compatible types, so:
our Int proto max(Seq @seq, *%adverbs) {...}
Would not allow for a max multi that returned a string (probably not a
good idea).
IIRC, perl 6 doesn't pay attention to the le
Mark Stosberg wrote:
>
> When Perl 5 has references and Perl 6 doesn't, I don't know what to
> expect to when I need to pass a hash reference to a Perl 5 routine.
>
> Such details make no appearance currently in the Perl 6 spec, but I'm
> trying to gather them on the wiki if you have anything to
Hi,
Some first thoughts that come to mind after reading leo's two proposals.
+A typical C structure:
+
+ struct foo {
+int a;
+char b;
+ };
+
+could be created in PIR with:
+
+ cs = subclass 'CStruct', 'foo' # or maybe cs = new_c_class 'foo'
+ addattribute cs, 'a'
+ addattribute
On Wed, Sep 27, 2006 at 09:12:02PM +, [EMAIL PROTECTED] wrote:
> The documentation should distinguish between those that are just
> pre-defined characters classes (E.G., and ) and
> those that are special builtins (E.G., and .
> The former are things that you should be freely allowed to r
The documentation should distinguish between those that are just pre-defined
characters classes (E.G., and ) and those that are special
builtins (E.G., and . The former are things that you
should be freely allowed to redefine in a derived grammar, while the other
second type may want to be t
Congratulations! Many thanks for all the work you've done, and the work
still to come. :)
Allison
Leopold Toetsch wrote:
Hi folks,
After a long period of fulltime parrot addiction, I've to reduce my parrot
domestication time in favor of a day $job.
I'll try to follow & continue parrot deve
Hi folks,
After a long period of fulltime parrot addiction, I've to reduce my parrot
domestication time in favor of a day $job.
I'll try to follow & continue parrot development as time permits. Reduced dev
time also implies that I will not use much time for reviewing or committing
patches that
On Wed, Sep 27, 2006 at 11:59:32AM -0700, David Brunton wrote:
> A quick scan of S05 reveals definitions for these seven special named
> assertions:
> [...]
I don't think that <'...'> or <"..."> are really "named assertions".
I think that (as well as <+xyz> and <-xyz>) are simply special form
Hi folks,
There are 2 new docs in docs/pdds/clip now (r14774):
1) pddXX_pmc.pod
2) pddXX_cstruct.pod
I'll start with 2) first: it'll be the metaclass of all (publically
accessible, C-derived) structures used in Parrot, it'll be the Class PMC of
PMC based objects therefore. As a PMC C CStruct
Author: leo
Date: Wed Sep 27 12:57:22 2006
New Revision: 14774
Added:
trunk/docs/pdds/clip/pddXX_cstruct.pod (contents, props changed)
trunk/docs/pdds/clip/pddXX_pmc.pod (contents, props changed)
Changes in other areas also in this revision:
Modified:
trunk/MANIFEST
Log:
add 2 new d
Leo and I just chatted on the phone for a bit. I'll summarize here.
We went over two proposals that he put together, one on variable-sized
PMCs and one on creating a shared base class for some of the common PMC
types. (He's checking the proposals into the repository, so you can all
see them. I
In a message dated Wed, 27 Sep 2006, Aaron Sherman writes:
Any thoughts?
I'm still thinking about the practical implications of this... but what
immediately occurs to me:
The point of multiple, as opposed to single, dispatch (well, one of the
points, and the only point that matters when we'
Audrey (>):
Indeed... Though what I'm wondering is, is there a hidden implementation
cost or design cost of making /+/ always behave such that
$.from
returns something, compared to the current treatment with the workaround
you suggested?
Has this been settled or addressed off-list? Because from
>From an IRC conversation earlier today:
A quick scan of S05 reveals definitions for these seven special named
assertions:
<'...'>
Twenty-four more are listed in docs/Perl6/Overview/Rule.pod (some of which are
used in S05, but I don't think there are definitions).
<"...">
Executive summary:
I suggest a signature prototype that all multis defined in or exported
to the current namespace must match (they match if the proto would allow
the same argument list as the multi, though the multi may be more
specific). Prototypes are exportable. Documentation tie-ins are a
On Wed, Sep 27, 2006 at 10:43:00AM -0600, Luke Palmer wrote:
: Well, there are a few ways to do that:
:
:given lc $lang {...}
:
:when { lc eq 'perl' } {...}
:
:when insensitive('perl') {...}
With the latest change to S05 that auto-anchors direct token calls,
you can now alo write:
Am Mittwoch, 27. September 2006 19:08 schrieb chromatic:
> While we
>
> > could of course check, what type P0 is, such a check would be needed for
> > every IO opcode. (And see below)
>
> I don't buy this argument. If the cost for checking the type of P0 is
> greater than the cost of doing IO, th
Author: larry
Date: Wed Sep 27 10:27:18 2006
New Revision: 12466
Modified:
doc/trunk/design/syn/S05.pod
Log:
Made directly called tokens and rules auto-anchor for readability.
Modified: doc/trunk/design/syn/S05.pod
=
On Wednesday 27 September 2006 03:40, Leopold Toetsch wrote:
> Now compare this with an I/O opcode:
>
> read S0, P0, 10 # PIO_reads(... P0 ...)
>
> If P0 isn't a ParrotIO opcode, this segfaults. See t/pmc/io_1.pir. While we
> could of course check, what type P0 is, such a check would be needed
On 9/27/06, Aaron Sherman <[EMAIL PROTECTED]> wrote:
BTW: for the above, it would be nice to be able to say:
when m:i/^perl$/ {...}
without all the "noise". That is, it would be nice to have something like:
when 'perl':i {...}
Well, there are a few ways to do that:
given
# New Ticket Created by Will Coleda
# Please include the string: [perl #40419]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40419 >
There are currently two PDD 07's in the repository:
docs/pdds/clip/pdd07_codingstd.pod
Larry Wall wrote:
On Mon, Sep 25, 2006 at 09:02:56PM -0500, Mark Stosberg wrote:
:
: eval($yaml, :lang);
:
: Still, these options may not substitute for the kind of role-based
: solution you have mind.
I'm not sure it's wise to overload eval this way. Seems like a
great way to defeat MMD. P
On Wed, Sep 27, 2006 at 11:38:10AM +0200, Leopold Toetsch wrote:
> Am Mittwoch, 27. September 2006 09:12 schrieb Allison Randal:
>
> > The basic problem is inconsistency. For hand-written code the current
> > PIR method call syntactic sugar is mildly annoying. (It'd be nice to
> > safely get rid o
On Tue, Sep 26, 2006 at 04:44:53PM -0700, Allison Randal wrote:
> One piece that is currently missing is a discussion of which lightweight
> concurrency model we're going to use for the asynchronous operations.
> I've had ongoing back-channel conversations with various people, but I
> need to co
Am Mittwoch, 27. September 2006 01:44 schrieb Allison Randal:
> I've committed an updated I/O PDD. I'm close to pronouncing this ready
> to implement, so get in your comments now.
I/O Stream Opcodes
I really don't like opcodes, when dealing with I/O.
1) opcodes are needed for native int o
Am Mittwoch, 27. September 2006 09:12 schrieb Allison Randal:
> The basic problem is inconsistency. For hand-written code the current
> PIR method call syntactic sugar is mildly annoying. (It'd be nice to
> safely get rid of the quotes around the method name.)
Not easily:
obj.'foo'() # a met
On Tue, Sep 26, 2006 at 04:44:53PM -0700, Allison Randal wrote:
> I've committed an updated I/O PDD. I'm close to pronouncing this ready
> to implement, so get in your comments now.
>
> One piece that is currently missing is a discussion of which lightweight
> concurrency model we're going to us
Leopold Toetsch wrote:
There seems to be the impression that generating PIR calls from a compiler is
hard because it may look like:
$S0 = obj.'_meth'(arg1, arg2)
but this also works:
.pcc_begin
.arg "hello"
.arg "\n"
.invocant obj
.meth_call "_meth"
.result $S0
.
31 matches
Mail list logo
