HaloO,
John M. Dlugosz wrote:
I do see that the use in a role is like a generic.
But you would use the sigil every time, e.g.
method doit (::?CLASS $self: ::?CLASS $other --> ::?CLASS)
that is not three separate generics with conflicting names, but the same
thing. With generics you can o
HaloO,
Larry Wall wrote:
In general, we're trying to get away from want-based context dependency
and instead attempting to encourage lazy semantic constructs such
as Captures that can behave with a wide dynamic range when actually
bound later.
Shouldn't we then change the heading of the respec
HaloO,
John M. Dlugosz wrote:
How about sub foo (--> Seq^Item) {...}?
Interesting idea, but that doesn't tell the compiler that the return is
keyed to the context. The compiler should know what return type to
expect, if only I could explain it.
Sorry, the type has nothing to do with how th
HaloO,
Larry Wall wrote:
That is, coro and loop tend to violate single-assignment semantics, and
single-assignment semantics are easier to map into functional semantics.
So if we do allow coro in Perl 6, it'll probably be a second-class
citizen like loop and goto and die (and anything else cons
HaloO,
John M. Dlugosz wrote:
Great. So the flip side is, what do I return from a function so that it
gives a single value if called simply, but provides optional named
returns that are there if you catch them? As a capture with one
positional and one named argument?
Yeah, just that.
An
HaloO,
John M. Dlugosz wrote:
Perl 6 has a concept of a "candidate list". The candidate list are
those that could handle the call, typically inherited methods and
multi variations.
"Candidate set" would be a better term. It is a subset of all long names
of a multi in a lexical scope.
It se
"John M. Dlugosz" and I have both replied to "whiteringmoon"'s query, so I
don't think anyone else need to. (If he's genuine, we don't want to
bombard him with multiple replies, and if not, let's not give out too much
spambait.)
--
Email and shopping with the feelgood factor!
55% of income t
# New Ticket Created by François PERRAD
# Please include the string: [perl #53120]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53120 >
2008/4/20 James E Keenan <[EMAIL PROTECTED]>:
> This morning I noticed that the foll
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Apr 21 13:00:02 2008 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with m
? Multiple-assignment second-class? I don't see how you get that out
of Larry's message...
On 4/21/08, TSa <[EMAIL PROTECTED]> wrote:
> HaloO,
>
> Larry Wall wrote:
> > That is, coro and loop tend to violate single-assignment semantics, and
> > single-assignment semantics are easier to map int
HaloO,
Mark J. Reed wrote:
? Multiple-assignment second-class? I don't see how you get that out
of Larry's message...
Well, he explicitly says that loop is second-class because
it uses multi-assignment. Actually he says it "tends to
violate single-assignment". But I interpret that sort of
int
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
"Candidate set" would be a better term. It is a subset of all long names
of a multi in a lexical scope.
List, not set, because it is ordered. nextsame/nextwith/etc. are
described as invoking the next candidate on the list. Therefore, there
is
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
You are right and I didn't address this, sorry. Actually the
only solution I see is dropping the ::? twigil altogether and
specify that CLASS is lexically declared by the compiler.
Otherwise we have to make a special case exception out of
::? vari
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
I guess with strong you mean as lossless as possible?
I think the type is just :( $: :named$ ) if you want to extract the
invocant with a $ prefix. Otherwise it would be :( $, :named$ ) and you
extract the item positionally with prefix @ or .[].
HaloO,
John M. Dlugosz wrote:
I don't want to have to "extract" it. I want to be able to say
$x = foo
I guess that does not collapse the capture that foo returns. So
it goes into $x unaltered. If you later use $x as an invocant
of a method this extracts the invocant slot from the captur
James Keenan (via RT) a écrit :
# New Ticket Created by James Keenan
# Please include the string: [perl #53126]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53126 >
I noticed that a new step, auto::digest, has been adde
On Mon Apr 21 07:11:23 2008, [EMAIL PROTECTED] wrote:
>
> Previously, the generation was done by src/dynpmc/Makefile (generated
> from config/gen/makefiles/dynpmc.in) and use some perl -pe "s///" from a
> template src/dynpmc/mdx.pmc.
> So it was not the standard way, and it was not enought smart
On Sat, Apr 19, 2008 at 08:00:07AM -, John M. Dlugosz wrote:
: Perl 6 has a concept of a "candidate list". The candidate list are those
that could handle the call, typically inherited methods and multi variations.
:
: It seems that multi variations, at least with respect to the semicolon
On Apr 20, 8:38 pm, [EMAIL PROTECTED] wrote:
> "John M. Dlugosz" and I have both replied to "whiteringmoon"'s query, so I
> don't think anyone else need to. (If he's genuine, we don't want to
> bombard him with multiple replies, and if not, let's not give out too much
> spambait.)
>
> --
>
> Email
On Mon, Apr 21, 2008 at 12:25 AM, Mark Glines <[EMAIL PROTECTED]> wrote:
> (Still debatable whether the rest of that #else clause in parrot.h is
> valid, if it's causing issues like this one.)
This patch can avoid future problems, by defining and using using
specific macros.
I searched the sou
HaloO,
John M. Dlugosz wrote:
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
"Candidate set" would be a better term. It is a subset of all long names
of a multi in a lexical scope.
List, not set, because it is ordered. nextsame/nextwith/etc. are
described as invoking the next candidate on
On Thu, Apr 17, 2008 at 10:10:29PM -0500, Jonathan Scott Duff wrote:
> I was annoyed that
>parrot perl6.pbc --target=PAST -e 'say "Hello"'
> didn't seem to work, so I modified PCT/HLLCompiler so that it does.
>
> I'm not sure it's entirely correct though as I only tested it for the
> limited
HaloO,
John M. Dlugosz wrote:
I hope you have a few minutes to look it over.
I started to think it through. There are two quick remarks.
In
module M
{
class C { ... }
class D
{
# lexical region where C refers to M::C
method m1 () { my
I'm still exploring the Rakudo build progress as a profiling target for likely
optimizations. After this weekend's work, I have src/gen_actions.pir
generation down to 27,788,055,796 instructions (with an optimized Parrot). A
big chunk of that time goes to support bsr_ic:
7,784,136,854 core.
On Apr 21, 2008, at 9:39 , John M. Dlugosz wrote:
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
I think the type is just :( $: :named$ ) if you want to extract
the invocant with a $ prefix. Otherwise it would be :( $, :named
$ ) and you
extract the item positionally with prefix @ or .[].
On Mon, Apr 21, 2008 at 10:19:08AM -0700, chromatic wrote:
> I'm still exploring the Rakudo build progress as a profiling target for
> likely
> optimizations. After this weekend's work, I have src/gen_actions.pir
> generation down to 27,788,055,796 instructions (with an optimized Parrot). A
>
hi,
Currently, the pct tutorial language is "out there", mostly on the
parrotblog entries, and I uploaded a .zip onto the wiki.
However, updating it is now a pain, because I have to recreate a .zip
and replace it on the wiki.
What do people think about adding it in the examples directory? At
firs
On Mon, Apr 21, 2008 at 08:34:49PM +0100, Klaas-Jan Stol wrote:
> hi,
>
> Currently, the pct tutorial language is "out there", mostly on the
> parrotblog entries, and I uploaded a .zip onto the wiki.
>
> However, updating it is now a pain, because I have to recreate a .zip
> and replace it on the
On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 21, 2008 at 10:19:08AM -0700, chromatic wrote:
> > I'm still exploring the Rakudo build progress as a profiling target for
> likely
> > optimizations. After this weekend's work, I have src/gen_actions.p
On Monday 21 April 2008 12:25:53 Patrick R. Michaud wrote:
> To me, the scary part of src/stacks.c is at the beginning:
>
> The stack is stored as a linked list of chunks (C),
> where each chunk has room for one entry.
>
> Eek! For something like bsr_ic, which is really just pushing a
> r
On Mon, Apr 21, 2008 at 08:48:10PM +0100, Klaas-Jan Stol wrote:
> On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> > I think we'd get a BIG win if we changed the dynamic_env stack to
> > have an approach similar to ResizableIntegerArray, where we allocate
> > arra
I've applied the patch from RT#52838 which updates the documentation.
I'm now working on eliminating the restoreall/saveall opcodes themselves
from Parrot, as well as working on the related user stack ops in RT#52842.
Pm
On Mon, Apr 21, 2008 at 8:41 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 21, 2008 at 08:34:49PM +0100, Klaas-Jan Stol wrote:
> > hi,
> >
> > Currently, the pct tutorial language is "out there", mostly on the
> > parrotblog entries, and I uploaded a .zip onto the wiki.
> >
>
On Mon, Apr 21, 2008 at 02:25:53PM -0500, Patrick R. Michaud wrote:
>
> The parts of the stack code we've discussed eliminating is actually
> the user_stack, used for push/pop/saveall/restoreall opcodes.
I inadvertently wrote push/pop here where I really meant save/restore.
The push/pop opcode
Author: pmichaud
Date: Mon Apr 21 13:08:48 2008
New Revision: 27082
Modified:
trunk/docs/pdds/draft/pdd06_pasm.pod
Changes in other areas also in this revision:
Modified:
trunk/editor/kate_syntax.pl
trunk/languages/BASIC/compiler/compile.pl
Log:
[core]:
* Updates for the restoreall/save
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 14:25:53 -0500
. . . this seems to be the case for everything using the
"generic stack", which AFAICT is the &interp->dynamic_env structure.
Your point is correct, except that you are talking about the "dynamic
envi
On Mon, Apr 21, 2008 at 04:31:17PM -0400, Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>Date: Mon, 21 Apr 2008 14:55:21 -0500
>
>> On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]>
> wrote:
>> > I think we'd get a BIG win if we changed t
On Mon, Apr 21, 2008 at 04:38:52PM -0400, Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>Date: Mon, 21 Apr 2008 14:25:53 -0500
>
>. . . this seems to be the case for everything using the
>"generic stack", which AFAICT is the &interp->dynamic_env structure.
>
>
On Monday 21 April 2008 13:44:44 Patrick R. Michaud wrote:
> On Mon, Apr 21, 2008 at 04:38:52PM -0400, Bob Rogers wrote:
> Thanks again. I was misreading from comments in stack_push, which
> say that it pushes things onto the "generic stack" when in reality
> it seems to use whatever stack is pa
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 14:55:21 -0500
> On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]>
wrote:
> > I think we'd get a BIG win if we changed the dynamic_env stack to
> > have an approach similar to ResizableInt
Am Montag, 21. April 2008 22:49 schrieb chromatic:
> On Monday 21 April 2008 13:44:44 Patrick R. Michaud wrote:
> > On Mon, Apr 21, 2008 at 04:38:52PM -0400, Bob Rogers wrote:
> >
> > Thanks again. I was misreading from comments in stack_push, which
> > say that it pushes things onto the "generic
# New Ticket Created by "Clark Cooper"
# Please include the string: [perl #53156]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53156 >
Using Parrot 0.6.1 on Fedora Core 5, linux 2.6.15-1.2054_FC5
The program, classinfo.p
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 15:42:27 -0500
On Mon, Apr 21, 2008 at 04:31:17PM -0400, Bob Rogers wrote:
>There is another solution that ought to speed up "bsr" dramatically:
> Give the "bsr" return addresses their own stack.
I thou
Author: pmichaud
Date: Mon Apr 21 15:58:26 2008
New Revision: 27092
Modified:
trunk/docs/pdds/draft/pdd06_pasm.pod
Log:
[docs]:
* PDD06: Remove documentation of some opcodes that have been absent for
a long time.
Modified: trunk/docs/pdds/draft/pdd06_pasm.pod
==
On Monday 21 April 2008 10:26:21 Clark Cooper wrote:
> Using Parrot 0.6.1 on Fedora Core 5, linux 2.6.15-1.2054_FC5
>
> The program, classinfo.pir :
> #
> .const string Indent=' '
> .const int MaxDepth = 6
>
> .sub main :m
On Sun, 2008-04-20 at 19:01 -0700, James Keenan wrote:
> auto::gettext (r26100 | particle | 2008-02-27)
> auto::crypto (r26359 | fperrad | 2008-03-14)
> auto::glibc (r26946 | particle | 2008-04-12)
> auto::opengl (r27022 | infinoid | 2008-04-18)
> gen::opengl (r27022 | infinoid | 2008-04-18)
> gen:
On Mon Apr 21 16:21:18 2008, geoff wrote:
>
> Two of these are from me (auto::opengl and gen::opengl). I had
> attempted to discuss OpenGL bindings on p-p and in IRC multiple times in
> the past; in each case the discussion either veered off into technical
> details or was Warnocked.
>
> No, I d
On Sun, 20 Apr 2008 19:01:44 -0700
James Keenan (via RT) <[EMAIL PROTECTED]> wrote:
Hi! As one of the guilty parties, I'm not sure whether I get a vote,
but...
> * Is new configuration step X::X *necessary* for the functioning
> of the Parrot virtual machine?
Frankly, probably nothing but the
On Mon Apr 21 16:21:18 2008, geoff wrote:
>
> As a non-core contributor, my impression is that there is no top-down
> plan. Parrot's development appears very much guided by dynamic tension
> between the real bottom-up work, docs ranging from prescriptive to
> descriptive to imaginative, and a *de
On Mon Apr 21 07:11:23 2008, [EMAIL PROTECTED] wrote:
>
> I prefer the die behavior, because with it, I don't forget to add tests
> with auto::crypto.
>
So I'm not alone, after all ;-)
> Now, I think the name gen::digest is not good.
> I prefer gen::crypto because :
> 1) same as auto::crypto
On Sun, 2008-04-20 at 19:28 -0700, James Keenan via RT wrote:
> As to the question of whether people know how to write tests: I think
> there is empirical evidence that people know how to write tests for the
> configuration steps. For example, when François earlier submitted
> config/auto/crypto.
On Mon Apr 21 17:02:58 2008, [EMAIL PROTECTED] wrote:
[snip]
>
> > * Is new configuration step X::X *necessary* for the functioning
> > of the Parrot virtual machine?
>
> Frankly, probably nothing but the basic "does the compiler exist, and is
> it sane" type of tests meet that qualification.
>
On Mon, 2008-04-21 at 17:06 -0700, James Keenan via RT wrote:
> I'm mostly in agreement. It just seems to me that the configuration
> ought to be settling down as we near 1.0.
Absolutely. However, as of 0.6.1 we are at the stage where outsiders
like myself can finally meaningfully contribute --
Bob Rogers wrote:
I don't expect to be able to co-lead (since, for one thing, that would
require putting in significant time in advance), but I would be willing
to help TA such a thing. I suspect it would be valuable to have a
number of TAs with diverse areas of trouble-shooting expertise, sin
1. If you have had a Parrot- or Rakudo-oriented presentation accepted
at YAPC::NA::2008 in Chicago, please add your name and presentation's
name to: http://www.perlfoundation.org/parrot/index.cgi?yapc_na_2008
2. The Parrot/Rakudo buildfest workshop has been accepted. If you are
able to be
On Mon, 2008-04-21 at 17:02 -0700, Mark Glines wrote:
> 1. It seemed more relevant than some stuff that's already in
> parrot. (I have more machines with OpenGL installed than have
> postgresql, for example.)
Ditto, but of course, I'm biased. :-)
> 2. The author (Geoff) was responsive, willin
On Monday 21 April 2008 17:02:27 Mark Glines wrote:
> Another note, slightly off-topic: does OpenGL actually need a
> configuration/detection step at all? I notice neither SDL or
> PostgreSQL seem to have one. Maybe they're detecting everything at
> runtime, or maybe their generated stuff runs f
On Sat, Apr 12, 2008 at 08:26:34PM -0700, Bob Rogers wrote:
>The ops in src/ops/stack.ops are holdovers from the bad old days of
> limited registers. In modern times, it is more versatile (and probably
> faster) to create an array and use it as an explicit stack via push and
> pop operations.
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Second, I don't like the concept of a virtual method that returns
a type. That horribly mixes type level and value level. From the
They are mixed! Perl treats types as first-class objects. For
functions, types don't need to be treated specia
Brandon S. Allbery KF8NH allbery-at-ece.cmu.edu |Perl 6| wrote:
my ($x, :$named) = foo; # or something like that
That looks to me like a form of positional extraction. (Of course, my
hit rate on p6 stuff has been remarkably low of late...)
It's not just positional, but allows fo
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 18:54:19 -0400
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 15:42:27 -0500
. . . If it looks like having a separate stack for bsr/ret is
workable then I'll go at it that way.
Fai
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 18:54:19 -0400
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 15:42:27 -0500
. . . If it looks like having a separate stack for bsr/ret is
workable then I'll go at it that way.
Fai
From: "Patrick R. Michaud via RT" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 18:00:31 -0700
On Sat, Apr 12, 2008 at 08:26:34PM -0700, Bob Rogers wrote:
>The ops in src/ops/stack.ops are holdovers from the bad old days of
> limited registers. In modern times, it is more versatil
On Monday 21 April 2008 19:17:34 Bob Rogers wrote:
> The hack is attached; it isn't headerized, has some coding standards
> failures, and leaks memory, so it's incomplete. Disappointingly, it
> produces an overall speedup of less than 4% in building gen_actions.pir
> in r27087 (which has chromati
I found the results of an experiment (done in r26933) where I used
the attached patch to disable all stack ops, and then did "make test".
(I had misplaced it, which is why I didn't post it earlier; sorry about
that.) Here are the failing tests:
Failed Test Stat Wstat Tota
On Mon, Apr 21, 2008 at 11:04:13PM -0400, Bob Rogers wrote:
Content-Description: message body text
> t/op/jit.t 1 256621 1.61% 55
This one requires removing saveall and restoreall handling from imcc
(done in the stacks branch).
> t/op/stacks.t
As of r27105 these have all been recoded to avoid the stack.ops .
The only exception is t/op/stacks.t, which can be removed when we remove
the stack.ops in RT#52842 .
Closing ticket, and thanks!
Pm
Done as of r27113.
Pm
# New Ticket Created by Bob Rogers
# Please include the string: [perl #53168]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53168 >
Here's what I get when I attempt "make headerizer" in r27087:
. . .
ad
rrot/library/TGE.pbc --output-pbc TGE.pir
make -C compilers/nqp
../../parrot
/opt/src/perl6/build-20080421-b/runtime/parrot/library/PGE/Perl6Grammar.pir
\
--output=src/Grammar_gen.pir src/Grammar.pg
make[1]: *** [nqp.pbc] Bus error
make: *** [compilers.dummy] Error 2
herodotus:build-
Tonight I resolved RT#52838 and RT#52840, eliminating the saveall/restoreall
opcodes, the register stack, and fixing up tests and other items
to avoid save/restore/etc. opcodes.
I've also created a "userstack" branch where I've got the details
for removing the rest of stack.ops . I've already im
ns with both "make -j2" and a plain "make".
>
> ../../parrot -o TGE/Tree.pbc --output-pbc TGE/Tree.pir
> ../../parrot -o ../../runtime/parrot/library/TGE.pbc --output-pbc TGE.pir
> make -C compilers/nqp
> ../../parrot
> /opt/src/perl6/build-2008
Question 1:
What is meant by:
has $attribute # lexical alias for $!attribute.
Here is more concrete example. There is none in S12.
class C {
has $a;
method foo ()
{
my $y = $a; # is the correct?
}
In that scope, is $a really a shortcut for $self!a ?
If so,
73 matches
Mail list logo
