# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40519]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40519 >
Hi,
This patch removes t/tools from the list of directories searched for
by Parrot::
Leopold Toetsch wrote:
>
> Above Parrot interface function tries to locate Sub objects in the
> namespace of the invocant's class and in the MRO of it. When you go back
> to the PIR translation of your code there is e.g.
>
> class Foo:
> def g(self,y):
>
> I have translated this to:
>
> .
On Wed, 24 Aug 2005, Sam Ruby wrote:
[huge cut]
> Below is from the sample that Leo provided.
>
> > # print foo.f(2)
> >
> > # emulate python find_name, which checks attributes too
> > push_eh m_nf
> > $P0 = foo."f"(2)
> > clear_eh
> > goto m_f
> > m_nf:
> > # getattri
On Aug 24, 2005, at 23:34, Sam Ruby wrote:
Leopold Toetsch wrote:
Note that you would then be caching the results of a curried function
call. This result depends not only on the method string, but also on
the particular object upon which it was invoked.
No the "inner" Parrot_find_method_
Leopold Toetsch wrote:
>
>> Note that you would then be caching the results of a curried function
>> call. This result depends not only on the method string, but also on
>> the particular object upon which it was invoked.
>
> No the "inner" Parrot_find_method_with_cache just caches the method fo
On Aug 24, 2005, at 19:45, Sam Ruby wrote:
Leopold Toetsch wrote:
Sam Ruby wrote:
The return value is a callable sub.
More precisely: a curried function call. This is an important
distinction; to see why, see below.
A callable sub may be of course a curried one - yes.
The interest
Leopold Toetsch wrote:
> Sam Ruby wrote:
>
>> Leopold Toetsch wrote:
>
>>> A stripped down PIR-only, pythonless translation is below.
>
>> (example: classes aren't global in Python),
>
> Yes, of course. The stripped down means essential the absence of any
> lexical handlings. But as you say,
Sam Ruby wrote:
Leopold Toetsch wrote:
A stripped down PIR-only, pythonless translation is below.
(example: classes aren't global in Python),
Yes, of course. The stripped down means essential the absence of any
lexical handlings. But as you say, this doesn't matter for these sub and
m
I agree this following would be cool.
However in the general case this type of code inference is HARD to do.
I believe that the optimizations you are looking for would require a
combination of type inference and graph reduction.
PyPy may be the eventual answer.
Don't get me wrong, I think it is gre
Leopold Toetsch wrote:
> Sam Ruby wrote:
>
>> Let me try again to move the discussion from subjective adjectives to
>> objective code. Consider:
>
> [ example code ]
>
>> If you run this, you will get 1,2,3.
>>
>> When called as a function, f will return the value of the second
>> parameter. W
Sam Ruby wrote:
Let me try again to move the discussion from subjective adjectives to
objective code. Consider:
[ example code ]
If you run this, you will get 1,2,3.
When called as a function, f will return the value of the second
parameter. When called as a method, the same code will nee
Chip Salzenberg wrote:
> On Tue, Aug 23, 2005 at 07:15:41PM -0400, Sam Ruby wrote:
>
>>Leopold Toetsch wrote:
>>
>>>I've stated several times that calling conventions need changes to
>>>properly support HLLs with minor success at these times.
>>
>>With the diversity of HLLs out there, I'm not cert
On Tue, Aug 23, 2005 at 07:15:41PM -0400, Sam Ruby wrote:
> Leopold Toetsch wrote:
> > I've stated several times that calling conventions need changes to
> > properly support HLLs with minor success at these times.
>
> With the diversity of HLLs out there, I'm not certain that it is wise to
> decl
Leopold Toetsch wrote:
>
> On Aug 23, 2005, at 22:48, Sam Ruby wrote:
>
>>> From December 16, 2004:
>>
>> http://tinyurl.com/8smmq
>
> Sounds like a really ugly misunderstanding, the more that I've proposed
> not to pass the object (P2 in old parlance) out of band. I've stated
> several times
On Aug 23, 2005, at 22:48, Sam Ruby wrote:
From December 16, 2004:
http://tinyurl.com/8smmq
Sounds like a really ugly misunderstanding, the more that I've proposed
not to pass the object (P2 in old parlance) out of band. I've stated
several times that calling conventions need changes to
On Tue, Aug 23, 2005 at 03:48:03PM -0400, Sam Ruby wrote:
> How will Perl6 evaluate defaults?
I would like to help with this question, but I can't, and in general
p6i won't be the right place to ask. Nobody knows the final form of
Perl 6; nobody knows the currently understood form of Perl 6 excep
Chip Salzenberg wrote:
> I apologize to Leo for accidentally making this reply to the list.
> It was supposed to be private mail, but I hit 'y' just a _little_
> too soon. I had no intention of embarassing anyone. Sorry.
You did, however, cause me to cancel the email I was composing. If
people
On Tue, Aug 23, 2005 at 03:48:03PM -0400, Sam Ruby wrote:
: How will Perl6 evaluate defaults?
:
: Like Python:
:
: global x
: x=1
: def f(p1=x):
: return p1
: x=2
: print f()
:
: or like Ruby:
:
: $x=1
: def f(p1=$x)
: return p1
: end
: $x=2
: puts f()
By default, d
I apologize to Leo for accidentally making this reply to the list.
It was supposed to be private mail, but I hit 'y' just a _little_
too soon. I had no intention of embarassing anyone. Sorry.
On Tue, Aug 23, 2005 at 01:04:58PM -0700, Chip Salzenberg wrote:
> On Tue, Aug 23, 2005 at 09:58:21PM +0
On Tue, Aug 23, 2005 at 09:58:21PM +0200, Leopold Toetsch wrote:
> Sam, please follow Parrot dev (or stop spreading FUD) - thanks.
Be gentle, please. Parrot needs language developers. I'm not saying
you're right or wrong. I'm just asking you to be a little more
diplomatic.
--
Chip Salzenberg <
On Aug 23, 2005, at 20:28, Sam Ruby wrote:
Leopold Toetsch wrote:
I do agree with test-driven development. That is exactly the
approach I
took.
Well, I agree - until I see such tests (pyint_1):
$P2 = $P1.__abs__($P1)
Take a look at the difference between r7254 and r7312.
I just
How will Perl6 evaluate defaults?
Like Python:
global x
x=1
def f(p1=x):
return p1
x=2
print f()
or like Ruby:
$x=1
def f(p1=$x)
return p1
end
$x=2
puts f()
- Sam Ruby
P.S. The former prints "1", the latter, "2".
Kevin Tew wrote:
>>
> Point well taken, I've been leaning back between, rewrite and evolving
> your work.
> I have a current change set that is passing most of your original tests
> that are in t/dynclasses/py*.t
> It is more of an evolution than a rewrite, which I favor.
> Some test fail due to re
My current work.
Python PMC Patch to leo5-cxt5
Sam, Thanks for the comments,
They were very much appreciated.
Sam Ruby wrote:
>I added self on Leo's request. Now it is unneccessary. *shrug*
>
I understand completely.
>Check out parrot/t/dynclass/pyint_2.pmc. __add__ style methods were
>working, and tested.
>
Yes many are working, I shou
Leopold Toetsch wrote:
>
>> I do agree with test-driven development. That is exactly the approach I
>> took.
>
> Well, I agree - until I see such tests (pyint_1):
>
> $P2 = $P1.__abs__($P1)
Take a look at the difference between r7254 and r7312.
The tests originally passed without a self a
as the first
argument of a method. Therefore all the old workarounds like:
METHOD PMC* __abs__(Interp* interp, PMC* SELF, PMC* self) {}
aren't needed any more.
Sam's PMC's were also incomplete, they lacked support for a lot of the
__add__ style python methods. This is qui
On Tue, Aug 23, 2005 at 06:35:39PM +0200, Leopold Toetsch wrote:
> On Aug 23, 2005, at 17:09, Kevin Tew wrote:
> >Problem:
> >Python PMC's just don't work in the leo-cxt5 branch which will become
> >head/trunk at some time in the hopefully not to distant future
x27;s implementation of Python PMC is old and outdated. He did a lot of
> > pioneering work in the realm of the python object system on parrot.
> > Probably the first real attempt at a full object system on top of parrot.
> > Parrot has changed drastically since then.
> > S
On Aug 23, 2005, at 17:09, Kevin Tew wrote:
Problem:
Python PMC's just don't work in the leo-cxt5 branch which will become
head/trunk at some time in the hopefully not to distant future.
Err, I hope to merge RSN ;-)
I had a conversation a long time ago with Dan, in which he a
Kevin Tew wrote:
> Problem:
> Python PMC's just don't work in the leo-cxt5 branch which will become
> head/trunk at some time in the hopefully not to distant future.
>
> What I've done up time now:
> I've ported pyint.pmc, pystring.pmc to pass all tests i
Problem:
Python PMC's just don't work in the leo-cxt5 branch which will become
head/trunk at some time in the hopefully not to distant future.
What I've done up time now:
I've ported pyint.pmc, pystring.pmc to pass all tests in leo-cxt5
I've written t/dynclasses/pystr
=> PMC_int_val(SELF)
$1->vtable->bet_bool() => VTABLE_get_bool(INTERP, $1)
and so on. For details you might consult include/parrot/pmc.h.
> *any body offer some advice that learn PMC C source code and PMC's theory?
Just have a look at existing PMCs in classes. Commonly
hi,folks.
I am reading PMC C source code and reading some document("
http://www.perl.com/pub/a/2002/01/30/pmcs.html";).
Some questions:
*this PMC design have changed?
*any body offer some advice that learn PMC C source code and PMC's theory?
Thanks.
/*
p2p is a protocol or a compiler?
*/
On Thu, 2002-07-25 at 03:12, [EMAIL PROTECTED] wrote:
> Aaron Sherman <[EMAIL PROTECTED]> writes:
> > my @x is Hashed::ByValues = (1,2,3);
> > %h = (@x => 1);
> > @x[1] += 4;
>
> Personally I don't like the C< is Hashed::ByValues > because it smacks
> of spooky action at a distance;
I can comment on a bit of this at least :)
On Wed, 24 Jul 2002, Melvin Smith wrote:
> It is not clear to me yet that there needs to be a 1-to-1 correlation
> from PMC's to upper level "classes".
There won't be. In general, there well be far fewer PMC classes than
On 25 Jul 2002 [EMAIL PROTECTED] wrote:
> Luke Palmer <[EMAIL PROTECTED]> writes:
>
> > On 25 Jul 2002 [EMAIL PROTECTED] wrote:
> > >
> > > Personally I don't like the C< is Hashed::ByValues > because it smacks
> > > of spooky action at a distance; I much prefer my notion of C< %h{*@x}
> > > =
On 25 Jul 2002 [EMAIL PROTECTED] wrote:
>
> Personally I don't like the C< is Hashed::ByValues > because it smacks
> of spooky action at a distance; I much prefer my notion of C< %h{*@x}
> = 1>. And in Perl 6 I have the horrible feeling that C<< %h = (*@x =>
> 1) >> would expand to C<< %h = (1,2,
With the mass of discussion revolving around PMCs lately, I
just want to put my 2 cents in.
It is not clear to me yet that there needs to be a 1-to-1 correlation
from PMC's to upper level "classes". I can't see Parrot ever
providing enough "vtable" methods for
gt; >
> > > What's going to get printed from that?
> >
> > IMHO, it should print 'ok 1'. The idea of the hash function is to use
> > PMC's as hash keys. That means that different content PMC (as an array
> > with different elements) must retu
is ever useful? Of
> course! You're just associating a unique collection to some value. There
> are any number of places where you would want to do that.
Note: I don't want this behaviour in Perl itself. I want this behaviour
at least on some special PMC for my own project, a speci
On Wed, 2002-07-24 at 12:34, Fisher Mark wrote:
> > But then sometimes you'd *want* hashing to be based on the
> > content.
>
> OK, I'll bite -- when would you want this behavior? This behavior means
> that once you change the contents, the hash value would become irretrievable
> unless you rest
> But then sometimes you'd *want* hashing to be based on the
> content.
OK, I'll bite -- when would you want this behavior? This behavior means
that once you change the contents, the hash value would become irretrievable
unless you restored the contents of the key. (Is this useful in functional
As the last person to change the key hash algorithm, I'd like to chime in
here with a request that each PMC provide a string that the key hashing
algorithm can operate on. To some degree this is just selfish on my part --
I've got plans for upgrading the key hash algorithm in Perl 5 and Perl 6
wh
Dan Sugalski wrote:
> Yes. Hashes will take either strings or object IDs, depending on the
> hash. (The hash can choose)
Seems to me it would be mighty useful to have integer keys as well.
For large sparse arrays, e.g.
--
John Douglas Porter
At 9:36 AM +0100 7/22/02, [EMAIL PROTECTED] wrote:
>Um... not necessarily. Bordering on the 'not at all'. Perl 6 will
>apparently allow one to have things other than strings as keys to
>hashes. If I have:
Yes. Hashes will take either strings or object IDs, depending on the
hash. (The hash can ch
On Mon, 2002-07-22 at 04:36, [EMAIL PROTECTED] wrote:
> > Now, I ask for PMC programmers to take care implementing this! Notice
> > that, for example in arrays, arrays with the same length but different
> > elements should return different hash codes (or try). But for the same
> > elements MUST r
[EMAIL PROTECTED] wrote:
> Also, how deep should we go if we decide to have the hash algorithm
> work on the contents?
>
> One starts to understand why scheme has C, C and
> C.
Indeed. It's also why it allows to specify, in AA accesses,
what equality-testing operator you want keys to be compar
From: [EMAIL PROTECTED]
> If I have:
>
>$a = [ 1, 2, 3 ];
>$b = [ 1, 2, 3 ];
>
>%foo{$a} = 'A';
>%foo{$b} = 'B';
>
> Then I want C< (%foo{$a} == 'A') && %foo{$b} == 'B' > to be true.
Maybe this a case of "And Now For Something Completely Similar". This
looks like something we
exists %hash{ [] };
> > print "ok 2" if exists %hash{ ['This would change the hash key for
> > @foo?'] }; print "ok 3" if exists %hash{@foo};
> >
> > What's going to get printed from that?
>
> IMHO, it should print 'ok 1'. T
does it...
>
> Actually there's a whole can of worms here. Assuming I've just run
> the above code. I want to be able to do C< $b[0] = 3 > and still be
> able to lookup %foo{$b}, which implies that C should be based
> on some invariant of the PMC that's independe
ould change the hash key for @foo?';
> >
> > print "ok 1" if exists %hash{ [] };
> > print "ok 2" if exists %hash{ ['This would change the hash key for @foo?'] };
> > print "ok 3" if exists %hash{@foo};
> >
> > What&#
; print "ok 2" if exists %hash{ ['This would change the hash key for @foo?'] };
> print "ok 3" if exists %hash{@foo};
>
> What's going to get printed from that?
IMHO, it should print 'ok 1'. The idea of the hash function is to use
PMC's as h
On Tuesday 23 July 2002 08:27 am, Ashley Winters wrote:
> push @foo, 'This would change the hash key for @foo?';
>
> print "ok 1" if exists %hash{ [] };
> print "ok 2" if exists %hash{ [10] };
Err, I meant:
print "ok 2" if exists %hash{ ['This would change the hash key for @foo?'] };
Also, the
On Tuesday 23 July 2002 07:47 am, Alberto Manuel Brandão Simões wrote:
> Now, I ask for PMC programmers to take care implementing this! Notice
> that, for example in arrays, arrays with the same length but different
> elements should return different hash codes (or try). But for the same
> element
Resuming:
- Dan proposed an 'id' method returning an INTVAL;
- Brent Dax proposed to return a string;
- Nicholas Clark asked to return an unsigned value;
- Piers didn't like the 'id' name unless globally guaranteed to be
unique;
So, I propose another name (hash). Returning a string can be done
a
Dan Sugalski:
# At 5:52 PM +0100 7/22/02, Alberto Manuel Brandão Simões wrote:
# >Dan, can we create this new vtable method? returning an
# integer (long
# >integer)... with name hashValue, or asHash.. or something else.
#
# Yep. Call it id and have it return an INTVAL.
Can we have it return a
On Mon, 22 Jul 2002, Dan Sugalski wrote:
> At 5:52 PM +0100 7/22/02, Alberto Manuel Brandão Simões wrote:
> >Dan, can we create this new vtable method? returning an integer (long
> >integer)... with name hashValue, or asHash.. or something else.
>
> Yep. Call it id and have it return an INTVAL.
On Mon, Jul 22, 2002 at 01:12:57PM -0400, Dan Sugalski wrote:
> At 5:52 PM +0100 7/22/02, Alberto Manuel Brandão Simões wrote:
> >Dan, can we create this new vtable method? returning an integer (long
> >integer)... with name hashValue, or asHash.. or something else.
>
> Yep. Call it id and have i
At 5:52 PM +0100 7/22/02, Alberto Manuel Brandão Simões wrote:
>Dan, can we create this new vtable method? returning an integer (long
>integer)... with name hashValue, or asHash.. or something else.
Yep. Call it id and have it return an INTVAL.
>On Mon, 2002-07-22 at 17:07, Leon Brocard wrote:
>
Dan, can we create this new vtable method? returning an integer (long
integer)... with name hashValue, or asHash.. or something else.
Alberto
On Mon, 2002-07-22 at 17:07, Leon Brocard wrote:
> Alberto Manuel Brandão Simões sent the following bits through the ether:
>
> > This means one more fun
Alberto Manuel Brandão Simões sent the following bits through the ether:
> This means one more function to the vtable!
FWIW every object in Java must implement a hashCode method:
http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#hashCode()
Leon
--
Leon Brocard
On Mon, 2002-07-22 at 14:05, Simon Cozens wrote:
> Alberto writes:
> > Finally, we need to hash PMC's. While I don't know what hash function
> > we should use
>
> Nor can you know, in the general case. Let PMCs hash themselves.
This means one more function to th
Alberto writes:
> Finally, we need to hash PMC's. While I don't know what hash function
> we should use
Nor can you know, in the general case. Let PMCs hash themselves.
--
4.2BSD may not be a complete disaster, but it does a good job of emulating one.
My last mail didn't have many answers, maybe this one makes people think
and give ideas...
RFC: Hashing PMC's
Current PerlHash implementation accepts PMC's as keys, as long as they
can be transformed into Strings. While this can be
Applied.
Hi
I've sent these files to Dan, but still didn't any answer. Meanwhile,
somebody can have some more time than he too look into these files.
They are POD's documenting PMC's (Arrays, PerlArrays and PerlHashes).
If you think they are interesting, put them on the doc dir for
# New Ticket Created by "Sean O'Rourke"
# Please include the string: [netlabs #793]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=793 >
This patch adds shl and shr for PMC's.
# New Ticket Created by "Sean O'Rourke"
# Please include the string: [netlabs #792]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=792 >
This patch does the following:
- add defined() to PerlUndef
- add neg(PMC) to Per
At 9:05 AM +0100 7/1/02, Alberto Manuel Brandão Simões wrote:
>Hi.
>Some questions I got when start looking to PMC's:
>
>- Is there planned a set PMC? If not, a parrot application can't create
> it's own PMC?
Yup, there's a planned set, but I don't
Hi.
Some questions I got when start looking to PMC's:
- Is there planned a set PMC? If not, a parrot application can't create
it's own PMC?
- There are PMC examples other than the test suite?
Thanks for the good work ;)
Alberto
--
Alberto Manuel B. Simoes
Departamento
At 9:25 AM + 1/23/02, Alberto Manuel Brandao Simoes wrote:
> Hellows
>
> Can anybody give me a simple but complete explanation of the
>PMC register
>type? Thanks
Sure--a PMC register is, in C terms:
struct PMC *;
And the register set is just an array of PMC pointers. If tha
72 matches
Mail list logo
