There are still some leftovers of the old calling scheme, which I'd like
to get rid of (1,2) or change slightly (3):
1) bare invoke
This opcode assumes P0 = Sub, P1 = Continuation
2) bare invokecc
This opcode assumes P0 = Sub
3) invoke Px
This opcode assumes P1 = Continuation, but it has a
On Wed, Jul 20, 2005 at 10:25:08AM -0700, Mitchell N Charity wrote:
> PGE is currently passing all tests, but failing to run a "large" pugs
> grammar (one for p6 regexps). So I transliterated part of the grammar
> into a (failing) test. Attached. The test can grow into a full regexp
> descrip
Matthew Hodgson wrote:
These rules are all fair enough - but they are then ambiguous for
$::Foo. Is that the leaf name variable Foo in your current (innermost)
namespace?
It is not ambiguous if the sigil rules that expression. I assume
that the parameters of a sub are definining innermost name
On Thu, Jul 07, 2005 at 08:32:47AM -0500, Jones Robert TTMS Contractor wrote:
>
> When I go to the donation page and attempt to make a donation, the
> drop-down box does not give DBI as a valid recipient. Is it possible
> several people may not have donated as they noticed the same results,
On Sat, Jul 02, 2005 at 01:06:02AM +0100, Tim Bunce wrote:
> Once upon a time I said:
I'm back now and, after digesting a small mountain of non-DBI related
emails, I'll start digesting all your replies and getting up to speed
with Perl 6.
Many thanks to all who replied on and off-list.
Tim.
# New Ticket Created by Curtis Rawls
# Please include the string: [perl #36615]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36615 >
This patch moves the dump_cfg() call from reg_alloc.c to cfg.c, making
it more in line
On Thu, 21 Jul 2005, "TSa (Thomas Sandlaß)" wrote:
Matthew Hodgson wrote:
These rules are all fair enough - but they are then ambiguous for $::Foo.
Is that the leaf name variable Foo in your current (innermost) namespace?
It is not ambiguous if the sigil rules that expression. I assume
that t
Matthew Hodgson wrote:
I guess $::('Foo') was a bad example - $Foo="Foo"; $::($Foo) would have
been better at illustrating my point - which was that if $::($Foo)
searches outwards through namespace for a variable whose name is held in
$Foo, then $::Foo should end up referring to the same variab
On 7/20/05, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> Is there a Perl 6 tail call syntax,
> One suggestion was a tweak of `can`'s definition: instead of returning
> a reference to the method, it returns one with the invocant already
> curried into it. Thus, the above becomes this:
chromatic wrote:
On Tue, 2005-07-19 at 18:47 +0200, "TSa (Thomas Sandlaß)" wrote:
I strongly agree. They should share the same namespace. Since
code objects constitute types they also share this namespace.
This means that any two lines of
class Foo {...}
roleFoo {...}
sub Foo {...}
me
On 7/20/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> This is fixed now (r8657).
>
indeed, the results are much better:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t\dynclass\foo.t 8
"Jonathan Worthington" <[EMAIL PROTECTED]> wrote:
"jerry gay" <[EMAIL PROTECTED]> wrote:
if i recall correctly, the options here are: 1) unix-like return value
from spawnw everywhere, 2) return platform-specific value, or 3)
return some object-like thingy.
i don't like option 1, as i believe sp
On Thu, 21 Jul 2005, "TSa (Thomas Sandlaß)" wrote:
Matthew Hodgson wrote:
I guess $::('Foo') was a bad example - $Foo="Foo"; $::($Foo) would have
been better at illustrating my point - which was that if $::($Foo)
searches outwards through namespace for a variable whose name is held in
$Foo, t
chromatic wrote:
Why would a class not also define a type?
It does. A class is an instance generator. So all instances
share the same property of 'beeing instanciated from SomeClass'.
This can be used to type them. Question is where this type is
placed in the type lattice and how it compares to
On Thu, Jul 21, 2005 at 09:59:57AM -0300, Adriano Ferreira wrote:
: I can understand the convenience of turning a method into a subroutine
: by currying the object. Syntactical support for this seems cool too.
: But, can someone remind me why there is the need for an explicit tail
: call syntax? It
Larry said:
> So I guess I agree that .tailcall is probably just a bad synonym for "return".
But is there any other case where we need an explicit tail call with "goto"?
And about a way to curry a method with its receiver to a sub, is there
a shorthand?
Thanks,
Adriano.
HaloO Matthew,
you wrote:
I wasn't getting hung up on whether $::($varname) should somehow be
cached to avoid a dynamic lookup based on the current value of $varname
every time. And I assume that if $*Main::foo hadn't been created,
assigning to $::($varname) would create it as expected (again
Apologies, the submitted patch causes some tests to not terminate.
This patch is the correct version.
-Curtis
On 7/21/05, via RT Curtis Rawls <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Curtis Rawls
> # Please include the string: [perl #36615]
> # in the subject line of all future corr
Hi,
From docs/ROADMAP
* Memory leak - string_to_cstring returns a malloced string, which isn't
freed everywhere
A quick grep through the src folder found a few cases like this. I may have
missed some, but this patch fixes those I spotted. Compiles, passes all
tests (apart from dynclasse
On 7/21/05, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> "Jonathan Worthington" <[EMAIL PROTECTED]> wrote:
> > "jerry gay" <[EMAIL PROTECTED]> wrote:
> >> if i recall correctly, the options here are: 1) unix-like return value
> >> from spawnw everywhere, 2) return platform-specific value, or 3
On 7/20/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> Hi,
>
> # Perl 5
> my %hash = (a => 1, b => 2, a => 3);
> warn $hash{a}; # 3
>
> But I vaguely remember having seen...:
>
> # Perl 6
> my %hash = (a => 1, b => 2, a => 3);
> say %hash;# 1
>
> Can somebody c
"TSa (Thomas Sandlaß)" wrote:
Here your expectations might be disappointed, sorry.
The non-symbolic form $*Main::foo = 'bar' creates code that
makes sure that the lhs results in a proper scalar container.
The symbolic form might not be so nice and return undef!
Then undef = 'bar' of course let'
On Thu, Jul 21, 2005 at 11:21:05AM -0600, Luke Palmer wrote:
: On 7/20/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
: > Hi,
: >
: > # Perl 5
: > my %hash = (a => 1, b => 2, a => 3);
: > warn $hash{a}; # 3
: >
: > But I vaguely remember having seen...:
: >
: > # Perl 6
: >
On 7/21/05, jerry gay <[EMAIL PROTECTED]> wrote:
> i'll apply this patch today. additionally, i'll add some text to
> ops/sys.ops specifying that spawnw should return something
> object-like. i've created a TODO ticket in RT for the spawnw
> object-like return.
>
applied, r8660. also opened [perl
# New Ticket Created by jerry gay
# Please include the string: [perl #36619]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36619 >
the return value from spawnw is highly system dependent as currently
implemented. instead,
# New Ticket Created by Amir Karger
# Please include the string: [perl #36620]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36620 >
editor/ops2vim.pl says:
while (<@ARGV>) {
AFAIK, that should be
while () {
actually, it should be
while(<>) {
applied, thanks.
On 7/21/05, via RT Amir Karger <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Amir Karger
> # Please include the string: [perl #36620]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/rt
On Thu, Jul 21, 2005 at 05:16:39PM +1200, Sam Vilain wrote:
: Making $.foo =:= $?SELF.foo, and getting to the "raw" attribute $.SUPER::foo
: seems like the better solution to me. But of course, it would, because
: that's
: how *I* program, and $?SELF != all(@coders).
:
: Then we could even sneak
> "Michael" == Michael G Schwern <[EMAIL PROTECTED]> writes:
Michael> Nearest Krispy Kreme is in Beaverton on RT 26 or Clackmas
Michael> just off 205. Hmmm, chromatic lives in Beaverton...
So do I, but I'm not allowed *near* that place.
--
Randal L. Schwartz - Stonehenge Consulting Service
HaloO Sam,
you wrote:
This in turn implies that the $.foo syntax is, in general, bad
practice!
Yup.
I claim the opposit. But I might have a very different meaning in mind
when I say that. So it's opposit in an orthogonal direction :)
Not very huffmanised, is it?
The syntax is just right
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #36623]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36623 >
There's currently no way to delete a global or a lexical.
mdiep: you should be
On 7/21/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> Have at it...
The only thing I immediately don't like is the use of the normal identifier
character "_" to indicate the "specialness" of a particular variable (or
attribute or whatever we're calling them these days). IMO, a "_" should
just be a
Larry Wall wrote:
has $x; # private rw, no accessors, not virtual, name lexically scoped
has $_x;# private rw, rw _x accessor, not virtual, name class scoped
Even if I come across as intellectually handicapped but could
someone help me over this mental bridge: What is the diffe
On Thursday 21 July 2005 12:48 pm, Larry Wall wrote:
> * Don't need to topicalize self any more.
>
> * .foo can (again) always be the topic without warnings.
Thank you.
Do the following exist then:
has @x; # private, lexically scoped
has @_x; # private, class scoped, rw _x access
On Thu, Jul 21, 2005 at 02:29:33PM -0600, Paul Seamons wrote:
: On Thursday 21 July 2005 12:48 pm, Larry Wall wrote:
: > * Don't need to topicalize self any more.
: >
: > * .foo can (again) always be the topic without warnings.
:
: Thank you.
:
: Do the following exist then:
:
:has @
Larry,
This means that Roles are now first-class-ish things. Meaning they
cannot just simply be composed into classes since now we have to keep a
table of elements which are private to a Role.
I personally don't like this, I think it brings us back to Mix-ins and
(possibly) looses some of th
On Thu, Jul 21, 2005 at 05:15:34PM -0400, Stevan Little wrote:
: Larry,
:
: This means that Roles are now first-class-ish things. Meaning they
: cannot just simply be composed into classes since now we have to keep a
: table of elements which are private to a Role.
Well, we've kinda been squint
On Thu, Jul 21, 2005 at 03:25:17PM -0400, John Siracusa wrote:
: On 7/21/05, Larry Wall <[EMAIL PROTECTED]> wrote:
: > Have at it...
:
: The only thing I immediately don't like is the use of the normal identifier
: character "_" to indicate the "specialness" of a particular variable (or
: attribut
On Thu, Jul 21, 2005 at 10:17:13PM +0200, "TSa (Thomas Sandlaß)" wrote:
: Larry Wall wrote:
: >has $x; # private rw, no accessors, not virtual, name lexically
: >scoped
: >
: >has $_x; # private rw, rw _x accessor, not virtual, name class scoped
:
: Even if I come across as intellect
On Thu, Jul 21, 2005 at 11:58:41AM -0300, Adriano Ferreira wrote:
: Larry said:
: > So I guess I agree that .tailcall is probably just a bad synonym for
"return".
:
: But is there any other case where we need an explicit tail call with "goto"?
I suppose that depends on whether the tail-call opti
On 7/21/05 8:14 PM, Larry Wall wrote:
> On Thu, Jul 21, 2005 at 03:25:17PM -0400, John Siracusa wrote:
>> The only thing I immediately don't like is the use of the normal identifier
>> character "_" to indicate the "specialness" of a particular variable (or
>> attribute or whatever we're calling th
Larry Wall wrote:
: Do the following exist then:
:has @x; # private, lexically scoped
[...]
:has %y; # private, lexically scoped
[...]
Yes, the sigil is fairly orthogonal to all this, hopefully.
Yes, for isn't the sigil just a compact form of saying "does Hash" or
"does Array" ?
42 matches
Mail list logo
