--- John M. Dlugosz [EMAIL PROTECTED] wrote:
I want to review and collect the wisdom of what has been discussed
before. Someone mentioned this the other day, as being a significant
consensus. But I can't find anything in the forum archives.
Can someone point to the discussion, position
Hi,
I'm looking for answers/clarification on what (if taken as individual
programs) $x is in each case.
my Int $x; # $x is Int protoobject
say $x; # Int
say $x.WHAT; # Int
class Foo { }
my Foo $x; # $x is Foo protoobject
say $x; # Foo
say $x.WHAT; # Foo
# This
My thoughts:
.HOW returns information concerning the implementation type; .WHAT
returns information concerning the value type.
.HOW and .WHAT stringify to something resembling the declarations that
would be used to create them.
Also bear in mind that Perl 6 uses prototype-based object
I have a fix which currently suits my need. But the real problem, like
you said in IRC is to eventually merge the
PGE and the rakudo implementations of protoobjects.
I note that S12 that .WHAT and .WHO should return objects that
stringifies to strings and not directly strings
like in PGE
HaloO,
David Green wrote:
On 2008-May-3, at 5:04 pm, John M. Dlugosz wrote:
What does this mean?
our sub outer ()
{
...
our sub inner () { ... }
}
inner; # defined?
I don't know why it would be any more illegal than sub foo { our
$var... }. The inner sub would be in the package's
chromatic wrote:
I prefer this patch. It fixes the problem closer to its source. Does it work
for you?
Yes, that works for me. However the fix does not get exercised without
the new test case (or something similar) added in the original patch.
Thanks!
Tom
Hi,
This has been resolved as of r27337.
Thanks!
Jonathan
Upon further review:
It might be possible that $x.WHAT returns a Signature object, with the
value type of $x as the invocant (or return type?), and everything
else empty. But that merely begs the question of how to introspect a
Signature object. If I tell Perl 6 to say a Signature, what gets
On 2008 May 6, at 10:15, Jon Lang wrote:
Signature? If so, what kind of object does the Signature object
return if I ask it to give me its invocant? Surely not another
Signature object? Whatever it is that Perl 6 returns in that case
Turtle? :)
--
brandon s. allbery
Hi,
I've now made grammars a whole lot more class like. They get
proto-objects and inheritance works too, plus the regexen go in the
correct namespaces. There is some work to do getting Foo::bar to work
now (where Foo is a grammar name and bar is a regex name in the
grammar), but that's a
Hi,
I wound up tweaking this patch into shape, as discussed in previous
patches, and applying it with the tweaks. So now Junctions have .perl. :-)
Thanks!
Jonathan
On Tue, May 6, 2008 at 7:42 AM, chromatic [EMAIL PROTECTED] wrote:
I prefer this patch. It fixes the problem closer to its source. Does it
work
for you?
Works for me, but I wonder if the set_string_native function still
needs the fix, or an assertion about a forbidden combination of
I'm still in the dark... I find an positions for manhattan distance
but no definition of what that is. I did find the alternative pod page
earlier.
--John
Ovid publiustemp-perl6language2-at-yahoo.com |Perl 6| wrote:
--- John M. Dlugosz [EMAIL PROTECTED] wrote:
I want to review and
John ():
I'm still in the dark... I find an positions for manhattan distance but no
definition of what that is. I did find the alternative pod page earlier.
I don't have a whole answer for you, but a part that may help. What is
generally meant by Manhattan distance is so-called L1 distance,
Carl Mäsak wrote:
John ():
I'm still in the dark... I find an positions for manhattan distance but no
definition of what that is. I did find the alternative pod page earlier.
I don't have a whole answer for you, but a part that may help. What is
generally meant by Manhattan distance is
HaloO,
Jon Lang wrote:
My thoughts:
.HOW returns information concerning the implementation type; .WHAT
returns information concerning the value type.
My addition to these thoughts is that the WHAT and HOW are
cascaded. Let's say we start at level 0 with the objects,
thingies or however we
HaloO,
Mark A. Biggar wrote:
To do multi method dispatch, you want to select the method that best
matches the parameters in the call.
The fundamental flaw of metric mmd is that it trades degrees of
specificity. Consider the subtype chain E : D : C : B : A
where the rule is that having an E it
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
The fundamental flaw of metric mmd is that it trades degrees of
specificity. Consider the subtype chain E : D : C : B : A
where the rule is that having an E it is better handled by a
method dealing with a D than one dealing with an A. The same
is
On Fri, May 02, 2008 at 02:16:01AM -0500, Patrick R. Michaud wrote:
When you try to invoke a sub that doesn't exist, Parrot currently gives the
unhelpful error message Null PMC access in invoke(). Sometimes you can
figure out what's wrong given the backtrace. Often you can't.
...
The
TSa wrote:
Jon Lang wrote:
My thoughts:
.HOW returns information concerning the implementation type; .WHAT
returns information concerning the value type.
BTW, S12 more or less confirms the above: .WHAT returns a prototype
object that stringifies to its short name, while .HOW allows
In r27351 I've added code to PCT to check for non-existent subs and
throw an exception at the point of the call. So, the problem is
solved for PCT-based languages, at least.
It still doesn't help with the case of non-existent sub names in PIR,
though, for which I recommend something along the
Mark A. Biggar mark-at-biggar.org |Perl 6| wrote:
To do multi method dispatch, you want to select the method that best
matches the parameters in the call. One way to do that is to define a
measure for distances between types and they use the method that's at
the minimum distance. One simple
HaloO,
John M. Dlugosz wrote:
In C++, which must be resolved at compile time, the overloading
resolution mechanism demands that =every= parameter be at least as good
of a match, and one strictly better match. So the implementation never
guesses if worse-left/better-right is a better fit than
On 2008-May-6, at 6:07 am, TSa wrote:
Just to ensure that I get the our behavior right, consider
sub foo
{
our $inner = 3;
}
sub bar
{
our $inner = 4; # redeclaration error?
}
say $inner;
Does this print 3 even when foo was never called?
No, it throws an
HaloO,
John M. Dlugosz wrote:
OK, why would someone create those forms in the first place?
I would think they grow like that historically. A five steps
long subtyping chain is not particularly extraordinary. Note that
multi entries live outside of classes and their single dispatch.
The
On Tuesday 06 May 2008 10:38:38 John M. Dlugosz wrote:
I have problems with a simple sum. The distance is artificially
inflated if you make lots of small derivation steps vs one large
change. The concept of derivation steps is ill-defined for
parameterized types and types that change
On Tuesday 06 May 2008 11:03:08 Patrick R. Michaud via RT wrote:
It still doesn't help with the case of non-existent sub names in PIR,
though, for which I recommend something along the lines of the patch
described by chromatic in
On Saturday 23 February 2008 15:48:23 Bob Rogers wrote:
Oops; I spoke too soon. It turns out that r26025 causes the #50040 test
case to break again (I checked that it still worked in r26024). So
perhaps the change chromatic made didn't actually fix it . . .
Are you still seeing breakage?
Yes, PDD 19 can talk about 'subroutines' rather than 'compilation
units'. (I just did a quick skim of the file, and a simple search and
replace changing 'compilation unit' to 'subroutine' will work fine.)
In imcc.y, change 'compilation_unit' and 'compilation_units' to
something more general like
HaloO,
David Green wrote:
The assignment happens only when foo() is invoked. However, the
variable $*Main::inner is declared at compile-time. Similarly, an our
sub inner inside foo() would declare the name, but you couldn't call
inner() until after running foo() --or bar()-- since you can't
On Tuesday 06 May 2008 12:52:35 [EMAIL PROTECTED] wrote:
Author: allison
Date: Tue May 6 12:52:34 2008
New Revision: 27357
Log:
[pdd25cx]
* Several header changes from rerunning 'make headerizer'.
Modified: branches/pdd25cx/compilers/imcc/optimizer.c
Will Coleda wrote:
On Tue, May 6, 2008 at 1:23 AM, Will Coleda [EMAIL PROTECTED] wrote:
The goal for 1.0 is to ship languages separately from parrot; Can we
get a brief summary of what sort of licensing/copyright issues apply
when the languages are removed from perl.org repository?
My
On Fri, Oct 5, 2007 at 10:50 PM, via RT Paul Cochrane
[EMAIL PROTECTED] wrote:
In src/debug.c:PDB_cond() there is the todo item:
/* XXX Does /this/ have to do with the fact that PASM registers used to
* have
* maximum of 2 digits? If so, there should be a while loop, I think.
*/
On Tue, May 06, 2008 at 08:20:40PM +0200, TSa wrote:
HaloO,
John M. Dlugosz wrote:
In C++, which must be resolved at compile time, the overloading resolution
mechanism demands that =every= parameter be at least as good of a match,
and one strictly better match. So the implementation never
Sorry to reply to the wrong comment, but I lost the original thread in
my mail archives and didn't notice this until now.
On Tue, May 6, 2008 at 1:54 PM, John M. Dlugosz
[EMAIL PROTECTED] wrote:
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
The fundamental flaw of metric mmd is that it
On Tue, May 06, 2008 at 10:54:51AM +0200, Jonathan Worthington wrote:
Hi,
I'm looking for answers/clarification on what (if taken as individual
programs) $x is in each case.
my Int $x; # $x is Int protoobject
say $x; # Int
say $x.WHAT; # Int
What they said. $x is
This ticket is too vague.
There are plenty of specific PDB tickets already; those will serve.
Rejecting ticket.
On Fri Aug 03 13:43:42 2007, [EMAIL PROTECTED] wrote:
On Friday 03 August 2007 13:29:53 Jerry Gay wrote:
i'm having trouble on x86_64. when running a 32bit parrot, i get
occasional deadlock at the OS level, after Parrot_exit. when running a
64bit parrot, it segfaults within Parrot_exit,
On Tue Nov 13 19:01:07 2007, [EMAIL PROTECTED] wrote:
---
osname= freebsd
osvers= 6.2-stable
arch= sparc64-freebsd
cc= cc
---
Flags:
category=install
severity=high
ack=no
---
Parrot 0.4.17r22818
freebsd 6.2-sparc64 gcc 4.3
I have the output of the build up to
On Tue May 06 13:31:40 2008, [EMAIL PROTECTED] wrote:
Will Coleda wrote:
On Tue, May 6, 2008 at 1:23 AM, Will Coleda [EMAIL PROTECTED] wrote:
The goal for 1.0 is to ship languages separately from parrot; Can we
get a brief summary of what sort of licensing/copyright issues apply
when
On Tue May 06 17:15:39 2008, coke wrote:
If the patch is applied, can we close this ticket?
No. I only figured out how to keep track of files generated during
configuration, not during build. We need some of what, IIRC, particle
termed makefile trickery to keep track of files generated
Removing this config step class does not appear to have caused any smoke
failures. Resolving teicket.
On Sunday 27 April 2008 18:08:08 Mark Glines wrote:
In the future, INTVAL will probably be 128 bits for some platforms.
I'd really like to see a set of fixed-width types (similar to what p5
has for pack and unpack), so you have the option of native int or
exactly 32 bits or whatever you need.
Building a class definition is an activity performed by Perl code that runs at
compile time.
Could you take a quick look at Section 2 in
http://www.dlugosz.com/Perl6/class_building.pdf and make sure that view is
orthodox according to @Larry?
Then I will collect details that have been
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
HaloO,
John M. Dlugosz wrote:
In C++, which must be resolved at compile time, the overloading
resolution mechanism demands that =every= parameter be at least as
good of a match, and one strictly better match. So the
implementation never
Sorry, you're not following me at all. I'll try again later.
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
HaloO,
John M. Dlugosz wrote:
OK, why would someone create those forms in the first place?
I would think they grow like that historically. A five steps
long subtyping chain is not
Larry Wall larry-at-wall.org |Perl 6| wrote:
On Tue, May 06, 2008 at 08:20:40PM +0200, TSa wrote:
HaloO,
John M. Dlugosz wrote:
In C++, which must be resolved at compile time, the overloading resolution
mechanism demands that =every= parameter be at least as good of a match,
and one
On Tue, May 06, 2008 at 08:47:47PM -0500, John M. Dlugosz wrote:
Larry Wall larry-at-wall.org |Perl 6| wrote:
On Tue, May 06, 2008 at 08:20:40PM +0200, TSa wrote:
HaloO,
John M. Dlugosz wrote:
In C++, which must be resolved at compile time, the overloading
resolution mechanism
On Friday 25 April 2008 10:49:19 Andy Dougherty wrote:
Ok. Fixed. This version avoids both type-punning and cast alignment
warnings by declaring the 'data' element of a Stack_Chunk_t to be
of type Stack_Entry_t, since that's the only way it is ever used,
at least as far as I could tell.
Larry Wall wrote:
Jonathan Worthington wrote:
role Bar { }
my Bar $x; # $x is ???
say $x; # ???
say $x.WHAT; # ???
# This means we can only assign to $x something that does Bar?
Correct, and for the same reason. The container checks the role--it
has little to do
On Mon, 2008-04-28 at 08:44 -0700, Geoffrey Broadwell wrote:
I'm not wedded to splitting them up as much as I did. In fact, I'd be
fine with core.in, opengl.in, and misc.in. Better for you?
chromatic confirmed on IRC that this was his preference, saying also
that this arrangement solves
From: chromatic via RT [EMAIL PROTECTED]
Date: Tue, 06 May 2008 12:18:19 -0700
On Saturday 23 February 2008 15:48:23 Bob Rogers wrote:
Oops; I spoke too soon. It turns out that r26025 causes the #50040 test
case to break again (I checked that it still worked in r26024). So
On Tue, May 06, 2008 at 07:01:29PM -0700, Jon Lang wrote:
: 1. Apparently, my presumption that $x.WHAT was for retrieving the
: value type was wrong; from the above, it's sounding like it is
: supposed to retrieve the implementation type.
I don't know what you mean by those terms. .WHAT gives
On Tue, May 6, 2008 at 8:09 PM, Larry Wall [EMAIL PROTECTED] wrote:
On Tue, May 06, 2008 at 07:01:29PM -0700, Jon Lang wrote:
: 1. Apparently, my presumption that $x.WHAT was for retrieving the
: value type was wrong; from the above, it's sounding like it is
: supposed to retrieve the
I think this ticket is ready to be closed. A lot of the PMC_* items
were likely fixed as part of the pdd15oo change, and the problem I cited
has apparently been fixed.
Pm
On Tuesday 06 May 2008 19:26:46 Geoffrey Broadwell wrote:
On Mon, 2008-04-28 at 08:44 -0700, Geoffrey Broadwell wrote:
I'm not wedded to splitting them up as much as I did. In fact, I'd be
fine with core.in, opengl.in, and misc.in. Better for you?
chromatic confirmed on IRC that this
56 matches
Mail list logo
