# New Ticket Created by Adrian Taylor
# Please include the string: [perl #35450]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=35450 >
With pugs revision 3215 and parrot-0.2.0, I get a null pointer
dereference when runn
Patrick R. Michaud wrote:
... I couldn't find anything about string literals
in the Parrot docs -- is it documented somewhere?
I've updated imcc/docs/syntax.pod yesterday with a small section
regarding string escapes. Baiscally inside double quoted strings the
usual escaping is done, inside sin
Rod Adams skribis 2005-05-14 20:09 (-0500):
> >>o.
> >>O.
> >>this.
> >>self.
> >>me.
> >Not special syntax, meaning you can no longer use these identifiers for
> >your own class. Bad style to use single-letter identifiers, but we know
> >what trouble $a and $b in Perl 5 cause, and the B:: namespac
Rob Kinyon skribis 2005-05-14 21:12 (-0400):
> What's wrong with just defaulting to $self?
Are you kidding, trolling or just completely ignorant of what has been
discussed the past days?
> That's standard P5 OO, expected everywhere
No, Perl 5 has no default for methods. Its -> always needs an L
On Sun, May 15, 2005 at 01:19:53PM +0200, Juerd wrote:
> Or was your choice of words poor, and did you not mean to discuss the
> dot's *default*, but instead a standard way to write the current
> invocant?
I think what Rob suggested is that:
method ($foo)
means
method ($self: $foo)
by
A few days ago, when typing ./pugs,... You can guess the rest :)
I suggest
./method
to mean $?SELF.method, and
../method
to mean $?SELF.SUPER::method, or however that's normally written.
This syntax doesn't clash with anything, doesn't introduce whitespace
asymmetry and doesn't requir
Autrijus Tang skribis 2005-05-15 19:28 (+0800):
> On Sun, May 15, 2005 at 01:19:53PM +0200, Juerd wrote:
> > Or was your choice of words poor, and did you not mean to discuss the
> > dot's *default*, but instead a standard way to write the current
> > invocant?
> I think what Rob suggested is that:
On Sun, May 15, 2005 at 01:44:44PM +0200, Juerd wrote:
> I suggest
> ./method
> to mean $?SELF.method
>
> Your opinions please! (I ask those who already responded off-list, to
> repeat their opinion here)
I like it. Tentatively implemented as r3253 for people to experiment
with. The convert
On Sun, May 15, 2005 at 13:44:44 +0200, Juerd wrote:
> A few days ago, when typing ./pugs,... You can guess the rest :)
>
> I suggest
>
> ./method
>
> to mean $?SELF.method, and
>
> ../method
> Your opinions please! (I ask those who already responded off-list, to
> repeat their opinion
Adrian Taylor <[EMAIL PROTECTED]> wrote:
I can't reproduce the segfault, when running:
> rule name { Larry | Matz | Guido }
> rule project { Perl | Ruby | Python }
> rule description { \s does \s }
> say('Larry does Perl' ~~ //);
> say(!('Larry does Java' ~~ //));
#v+
$ ./pugs at.p6
Larry do
I also like this notation.
However, as a side note, let me voice the opinion that the "bad
reputation" of Perl partially comes from the fact that it often looks
like line noise. I think everybody know this. Now there has been a lot
of discussion on finding different meanings for any two-characte
(Note that "./" and "../" are prefix operators, and unlike ".?", ".*",
".+" and ".=", cannot be used infix. In fact, it requires that "?", "*",
"+" and "=" be thought of as meta-operators to ".", and from now on, to
"./" and "../" as well, so you get "./+method". This isn't as complex as
it looks
For starters, about the only combination harder to hit with on
spanned hand might be ctrl-F5.
I've remapped my keyboard so that I push shift for numbers and leave
it off for the various symbols on the top row. ^ isn't hard to type
for me. (Plus, is it that hard to use two hands with shifted keys
Juerd wrote:
A few days ago, when typing ./pugs,... You can guess the rest :)
I suggest
./method
to mean $?SELF.method, and
../method
to mean $?SELF.SUPER::method, or however that's normally written.
I'm opinionless on the latter, since in my opinion cross-calling
supermethods (calling a s
Abhijit Mahabal skribis 2005-05-15 9:10 (-0500):
> $_ is the topic; the "only" problem is that we have two topics here: an
> immediate and a "main" topic. What if a method call binds the invocant to
> *both* $_ and the "bigger topic" $__?
> (...)
> I like this because things still look a little
Abhijit Mahabal wrote:
(Note that "./" and "../" are prefix operators, and unlike ".?", ".*",
".+" and ".=", cannot be used infix. In fact, it requires that "?", "*",
"+" and "=" be thought of as meta-operators to ".", and from now on, to
"./" and "../" as well, so you get "./+method". This isn't a
On Sun, May 15, 2005 at 01:44:44PM +0200, Juerd wrote:
: A few days ago, when typing ./pugs,... You can guess the rest :)
:
: I suggest
:
: ./method
:
: to mean $?SELF.method, and
:
: ../method
:
: to mean $?SELF.SUPER::method, or however that's normally written.
That's almost termina
On Sun, 15 May 2005, Juerd wrote:
I do think $__ looks too much like $_.
Yeah, lets drop that idea.
A bit better would be to not have
a "bigger" topic, but a "higher" topic, $-, but the problem with seeing
the invocant as a topic on another level, is that
inconsistency/asymmetry would be introduced
Larry Wall skribis 2005-05-15 7:32 (-0700):
> (such as that it makes it too easy to use SUPER semantics rather than
> NEXT semantics)
I'm not intimately familiar with the advantages and disadvantages SUPER
versus NEXT, but they may both be dangerous if used on a *different*
method.
Because of t
On Sun, May 15, 2005 at 04:40:04PM +0200, Juerd wrote:
> Because of that, it is probably better to go with ./method not have ../method
Good. I was having a headache trying to convince myself ../method
was a good idea, but can't. Thanks for delivering me. :)
/Autrijus/
pgpqGzQIfNY4z.pgp
Descri
On 5/15/05, Juerd <[EMAIL PROTECTED]> wrote:
> Autrijus Tang skribis 2005-05-15 19:28 (+0800):
> > On Sun, May 15, 2005 at 01:19:53PM +0200, Juerd wrote:
> > > Or was your choice of words poor, and did you not mean to discuss the
> > > dot's *default*, but instead a standard way to write the curren
Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sun, May 15, 2005 at 01:44:44PM +0200, Juerd wrote:
> : A few days ago, when typing ./pugs,... You can guess the rest :)
> :
> : I suggest
> :
> : ./method
> :
> : to mean $?SELF.method, and
> :
> : ../method
> :
> : to mean $?SELF.SUPER::method, o
On Sun, May 15, 2005 at 12:22:07PM -0400, Matt Diephouse wrote:
: Does this mean private methods will be called like this?
:
: ./:method()
No, I think that's still just
.:method()
Larry
Hi Leo,
OK, you've confused me now :-) You're getting the same results as me
(which I also get with the latest parrot, shown below).
The Bus error from the first pugs command is what I'm reporting as a
bug - you can reproduce that. The callstack from that error suggests
that pugs is using pa
Larry Wall skribis 2005-05-15 9:24 (-0700):
> On Sun, May 15, 2005 at 12:22:07PM -0400, Matt Diephouse wrote:
> : Does this mean private methods will be called like this?
> : ./:method()
> No, I think that's still just
> .:method()
Both, depending on what you're calling it on.
./:metho
In reviewing S29 as it stands now, I see that many builtins both receive
and return boxed basic types. This seems like potentially spurious
overhead in some situations, while essential in others, so I wanted to
work out a set of rules for when boxed vs. unboxed types would be used
in core routines
On Sun, 2005-05-15 at 18:34 +0200, Juerd wrote:
> I've been looking for a good moment to come with this, but there is
> none, making this as good a point as any: I don't like the dot in
> attributes, and the colon that replaces it.
>
> If we have .method and .:method, then we should have $.attr a
On Sat, 16 Apr 2005, Sam Ruby wrote:
[I hope you don't mind me putting this back on the list - I would prefer that
everybody who is interested can follow along and/or participate]
Kevin Tew wrote:
Sam Ruby wrote:
Hey guys,
I didn't see this until just now.
Kevin Tew wrote:
Sam,
Just wondering wha
Now:
Declaration ExplicitImplicit $_ $?SELF
has $.var | $obj.var \ .var \ ./var \
has $:var | $obj.:var \ .:var \ ./:var \
Consistent:
has $.var \ $obj.var \ .var \ ./var \
has $.:var \$
Aaron Sherman wrote:
In reviewing S29 as it stands now, I see that many builtins both receive
and return boxed basic types. This seems like potentially spurious
overhead in some situations, while essential in others, so I wanted to
work out a set of rules for when boxed vs. unboxed types would be u
Michal wrote:
On Sat, 16 Apr 2005, Sam Ruby wrote:
[I hope you don't mind me putting this back on the list - I would
prefer that everybody who is interested can follow along and/or
participate]
Kevin Tew wrote:
Sam Ruby wrote:
Hey guys,
I didn't see this until just now.
Kevin Tew wrote:
Sam,
Jus
On 5/14/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Larry wrote:
>
> > I don't think we can allow this situation to stand. Either we have
> > to make != and !~ and ne transform themselves via "not raising", or
> > we have to disallow negative comparisons on junctions entirely.
> >
> > Opinions
On 5/15/05, Autrijus Tang <[EMAIL PROTECTED]> wrote:
> On Sun, May 15, 2005 at 01:44:44PM +0200, Juerd wrote:
> > I suggest
> > ./method
> > to mean $?SELF.method
Sounds good.
> class Person is Mortal {
> has Weapon %.weapons;
> ...
> method battle_choice (Monster
On 5/15/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> multi sub infix: (Any|Junction $a, Any|Junction $b) {
> !($a == $b);
> }
>
> Then it Just Works.
Also, that's the right way to provide a working != for any object
which defines ==. We all want that, right?
Ashley Winters
> : ../method
> :
> : to mean $?SELF.SUPER::method, or however that's normally written.
>
> That's almost terminally cute, but I like it. Unless someone can
> think of a major objection (such as that it makes it too easy to use
> SUPER semantics rather than NEXT semantics), let's go with it.
On 15/05/05 11:17 -0400, Rob Kinyon wrote:
> On 5/15/05, Juerd <[EMAIL PROTECTED]> wrote:
> > Autrijus Tang skribis 2005-05-15 19:28 (+0800):
> > > On Sun, May 15, 2005 at 01:19:53PM +0200, Juerd wrote:
> > > > Or was your choice of words poor, and did you not mean to discuss the
> > > > dot's *def
.
On 15 May 2005, at 16:17, Rob Kinyon wrote:
Right now, P6 has $?SELF and I'm saying that instead of using $?SELF,
we should use $self wherever $?SELF would be used. $_ is still the
topic and would be the default invocant if you have .method($foo).
What I'm saying is that you can have
method ( Int
Brad Bowman skribis 2005-05-16 9:56 (+1000):
> Would it conflict with range + pattern? Or has that changed anyway?
No, "./" and "../" are prefix only, so they cannot clash with an infix
operator like "..".
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_ha
On 15/05/05 22:48 +0100, Matthew Walton wrote:
> .
>
> On 15 May 2005, at 16:17, Rob Kinyon wrote:
> >Right now, P6 has $?SELF and I'm saying that instead of using $?SELF,
> >we should use $self wherever $?SELF would be used. $_ is still the
> >topic and would be the default invocant if you have .
On 5/15/05, Juerd <[EMAIL PROTECTED]> wrote:
> Brad Bowman skribis 2005-05-16 9:56 (+1000):
> > Would it conflict with range + pattern? Or has that changed anyway?
>
> No, "./" and "../" are prefix only, so they cannot clash with an infix
> operator like "..".
How would
print "Foo" while $
Larry Wall wrote:
On Sun, May 15, 2005 at 12:22:07PM -0400, Matt Diephouse wrote:
: Does this mean private methods will be called like this?
:
: ./:method()
No, I think that's still just
.:method()
This missing design rationale here is that the colon acts as part of the unary
operator:
Luke wrote:
Hmm. I'll just [mention] that if != is implemented like this:
multi sub infix: (Any|Junction $a, Any|Junction $b) {
!($a == $b);
}
Then it Just Works.
I'd be fine with the dwimmy version if that is the underlying rule, since then
the behaviour isn't a special case, and
On Sun, May 15, 2005 at 08:30:06PM -0400, Rob Kinyon wrote:
: On 5/15/05, Juerd <[EMAIL PROTECTED]> wrote:
: > Brad Bowman skribis 2005-05-16 9:56 (+1000):
: > > Would it conflict with range + pattern? Or has that changed anyway?
: >
: > No, "./" and "../" are prefix only, so they cannot clash w
Damian Conway <[EMAIL PROTECTED]> wrote:
> Larry Wall wrote:
>
> > On Sun, May 15, 2005 at 12:22:07PM -0400, Matt Diephouse wrote:
> > : Does this mean private methods will be called like this?
> > :
> > : ./:method()
> >
> > No, I think that's still just
> >
> > .:method()
>
> This missing
On Sun, May 15, 2005 at 06:34:47PM +0200, Juerd wrote:
: .:method # $_.:method
It is almost certainly the case that you can't call a private method
of $_ unless it just happens to have trusted you, and since it's
such an unusual thing, calling into another class's private method
should have
On Sun, May 15, 2005 at 08:54:52PM -0400, Matt Diephouse wrote:
: Damian Conway <[EMAIL PROTECTED]> wrote:
: > Larry Wall wrote:
: >
: > > On Sun, May 15, 2005 at 12:22:07PM -0400, Matt Diephouse wrote:
: > > : Does this mean private methods will be called like this?
: > > :
: > > : ./:method()
On Mon, May 16, 2005 at 10:37:13AM +1000, Damian Conway wrote:
: Luke wrote:
:
: >Hmm. I'll just [mention] that if != is implemented like this:
: >
: >multi sub infix: (Any|Junction $a, Any|Junction $b) {
: >!($a == $b);
: >}
: >
: >Then it Just Works.
:
: I'd be fine with the dw
the 'detatch' threads test hangs on win32. this small patch skips one
Could you try the following code('the detatch' threads test with one tweak)
and tell me if it hangs either and what output you get?
find_global P5, "_foo"
new P2, .ParrotThread
find_method P0, P2, "thread3"
new P6, .TQueue # ne
While reading A05, I saw (and understand, perhaps more importantly)
some more interesting ways to try to abuse the :w modifier. Added tests
of forms of separating the modifier from the rest of the pattern:
:w()foo ...
:w[]foo ...
:w\bfoo ...
:w::foo ...
Pm: The :w()foo and :w[]foo for sep
49 matches
Mail list logo
