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
On Aug 23, 2005, at 18:21, Sam Ruby wrote:
Kevin Tew wrote:
We don't have to pass self around, parrot
makes it available to us automatically.
I added self on Leo's request. Now it is unneccessary. *shrug*
Parrot's new calling conventions are passing 'self' as the first
argument of
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
On Tue, Aug 23, 2005 at 12:21:42PM -0400, Sam Ruby wrote:
> Kevin Tew wrote:
> > I've ripped out a lot of the explicit passing of self as the first
> > argument of pmc methods. - We don't have to pass self around, parrot
> > makes it available to us automatically.
>
> I added self on Leo's reques
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
31 matches
Mail list logo
