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
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
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 Sun, 15 May 2005, Kevin Tew wrote:
I've taken the code from
http://www.intertwingly.net/stories/2004/10/05/pyrate.zip,
which I assume to be Sam's code. It was basically stubs
with a few AST nodes implemented when I started with it.
Er. Yes. I can't speak for Sam, but I interpreted his post
as a
Re: Pyrate( Sam's stub code )
I've taken the code from
http://www.intertwingly.net/stories/2004/10/05/pyrate.zip, which I
assume to be Sam's code.
It was basically stubs with a few AST nodes implemented when I started
with it.
And am working to generate a python to pir translator/compiler that 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 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
Sam Ruby <[EMAIL PROTECTED]> wrote:
Hi Sam, long not hear ;)
> ... The overwhelming majority of that work
> is in getting the PMCs right.
I'm currently working on that. Some of the MMD functions are already
rewritten so that they can return new result PMCs. With the now working
MMD system I'v a
[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:
Kevin Tew wrote:
Sam,
Just wondering what the status is on python/parrot/pirate/pyrate.
These both look outdated.
http://
Kevin Tew wrote:
Sam,
Just wondering what the status is on python/parrot/pirate/pyrate.
These both look outdated.
http://www.intertwingly.net/stories/2004/10/05/pyrate.zip
http://pirate.versionhost.com/viewcvs.cgi/pirate/
I haven't looked at it for a few months now. I do plan to revisit it
enough
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> # find_method class 'A' method '__absolute': Sub
>> # Calling sub '__absolute'
> But only for classes that inherit from delegate.
Yes of course. Objects's derived from ParrotObject (i.e. Parrot standard
objects) dispatch to overload
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I continue to disagree with the part of this conclusion where you insert
find_method into the discussion. To give a concrete example: at the
moment the lookup involved in abs_p_p does not involve the use of
find_method.
$ cat abs.imc
.sub
Sam Ruby <[EMAIL PROTECTED]> wrote:
> I continue to disagree with the part of this conclusion where you insert
> find_method into the discussion. To give a concrete example: at the
> moment the lookup involved in abs_p_p does not involve the use of
> find_method.
$ cat abs.imc
.sub main
.loc
Leopold Toetsch wrote:
Leo - at one point you indicated that you might be interested in helping
to factor out the common code again.
Sure, and I'm not stopping that. The overall conclusion of (even infix
operator) method lookup was that it has to be done at runtime. It is up to
the PMCs to provide
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> Sam Ruby <[EMAIL PROTECTED]> wrote:
>>
>> [ snipped - all ok }
>>
>>>If I define an __add__ method with 16 arguments, Python will not throw
>>>an exception.
>>
>> I didn't write that. I've said: *if* you call it via "a + b", Python
>>
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
[ snipped - all ok }
If I define an __add__ method with 16 arguments, Python will not throw
an exception.
I didn't write that. I've said: *if* you call it via "a + b", Python
throws an exception - that one I've shown. Anyway...
What you wro
Sam Ruby <[EMAIL PROTECTED]> wrote:
[ snipped - all ok }
> If I define an __add__ method with 16 arguments, Python will not throw
> an exception.
I didn't write that. I've said: *if* you call it via "a + b", Python
throws an exception - that one I've shown. Anyway...
> If this is done at runtim
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
Here's the part that you snipped that addresses that question:
> And there is a piece that I haven't written yet that will do the
> reverse: if MMD_ADD is called on a PyObject that has not provided
> such beha
On 2004-12-03 at 14:46:16, John Siracusa wrote:
> Anyway, I thought it was interesting to see the ease of "forward
> compatibility" for simple attributes touted as a feature of Python. I'd
> like to tout it as a feature of Perl 6 too, because I also hate writing
> getters and setters... :)
Amen.
On Fri, Dec 03, 2004 at 02:05:16PM -0500, John Siracusa wrote:
> >From http://dirtsimple.org/2004/12/python-is-not-java.html
>
> "In Java, you have to use getters and setters because using public fields
> gives you no opportunity to go back and change your mind later to using
> getters and setter
John Siracusa writes:
> I guess I wasn't asking if it would be "possible" (I think that's been
> established), but if it would be "easy", "reasonable", or "clean" (as
> it appears to be in Python, although I'm just going by what the quoted
> web page says). I recall some discussions about the "bes
On Fri, Dec 03, 2004 at 04:13:01PM -0500, John Siracusa wrote:
: On Fri, 3 Dec 2004 22:06:43 +0100, Paul Johnson <[EMAIL PROTECTED]> wrote:
: > http://www.nntp.perl.org/group/perl.perl6.language/9576
:
: Wow, that's a blast from the past. I wonder how much of it is still
: valid... :)
Almost all
On Fri, 3 Dec 2004 22:06:43 +0100, Paul Johnson <[EMAIL PROTECTED]> wrote:
> http://www.nntp.perl.org/group/perl.perl6.language/9576
Wow, that's a blast from the past. I wonder how much of it is still
valid... :)
-John
Juerd skribis 2004-12-03 21:09 (+0100):
> $foo.bar .= "foo"
Meant ~= there.
Juerd
John Siracusa skribis 2004-12-03 14:46 (-0500):
> Anyway, I thought it was interesting to see the ease of "forward
> compatibility" for simple attributes touted as a feature of Python. I'd
> like to tout it as a feature of Perl 6 too, because I also hate writing
> getters and setters... :)
Of cou
On Fri, 3 Dec 2004 20:37:40 +0100, Juerd <[EMAIL PROTECTED]> wrote:
> John Siracusa skribis 2004-12-03 14:05 (-0500):
>> From http://dirtsimple.org/2004/12/python-is-not-java.html
>>
>> "In Java, you have to use getters and setters because using public fields
>> gives you no opportunity to go back
John Siracusa skribis 2004-12-03 14:05 (-0500):
> I'd like to be able to s/Python/Perl 6/ above, but after many discussions on
> this topic, I'm still not sure if I can.
Anything can be anything. I'm sure that despite the ability to run all
the code you want upon reading/writing an attribute, some
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Yes, I meant the ability to do things like '$P0 = new "Py_int"'.
> Could this be JITed? The mapping between string class name and assigned
> PMC type is constant throughout the life of the VM...
Not really or not easily. Fastest is to have type enum numbers
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I'm now converting to dynclasses. To be honest, I'm not thrilled with
this. What I would really prefer is a Parrot_new_p_s opcode with the
runtime worrying about caching class names across sub and module boundaries.
$P0 = new "Py_int"
o
Sam Ruby <[EMAIL PROTECTED]> wrote:
> I'm now converting to dynclasses. To be honest, I'm not thrilled with
> this. What I would really prefer is a Parrot_new_p_s opcode with the
> runtime worrying about caching class names across sub and module boundaries.
$P0 = new "Py_int"
or some such ha
At 12:51 PM -0500 10/20/04, Allen Short wrote:
On Tue, Oct 19, 2004 at 11:23:13AM +0200, Leopold Toetsch wrote:
* the import statement is simulated too by storing the lexicals into the
caller's frame. This would very likely be another Python opcode.
I should point out that this is much more li
On Tue, Oct 19, 2004 at 11:23:13AM +0200, Leopold Toetsch wrote:
> * the import statement is simulated too by storing the lexicals into the
> caller's frame. This would very likely be another Python opcode.
I should point out that this is much more like Python's semantics for
"import *" than Da
Sam Ruby <[EMAIL PROTECTED]> wrote:
> ... Suggestions welcome, in
> particular, a PIR equivalent to the Perl would be most helpful.
It could be something like below. Some remarks:
* we don't have a notion to create a Closure PMC, so these closures are
handcrafted. (NB: a subroutine with a .yi
Sam Ruby wrote:
Consider the following code:
def f(x): return len(x)
for i in [0,1]:
print f("foo")
f = lambda x: x.upper()
No, don't. Consider the following code instead:
def f(x): return len(x)
for i in [0,1]:
print f("foo")
len = lambda x: x.upper()
Key differenc
Dan Sugalski wrote:
At 7:55 AM -0400 10/18/04, Sam Ruby wrote:
I've been trying to make sense of Python's scoping in the context of
Parrot, and posted a few thoughts on my weblog:
http://www.intertwingly.net/blog/2004/10/18/Python-Parrot-and-Lexical-Scopes
While I posted it on my weblog for for
At 7:55 AM -0400 10/18/04, Sam Ruby wrote:
I've been trying to make sense of Python's scoping in the context of
Parrot, and posted a few thoughts on my weblog:
http://www.intertwingly.net/blog/2004/10/18/Python-Parrot-and-Lexical-Scopes
While I posted it on my weblog for formatting and linking re
Sam Ruby wrote:
It seems like everything on that page boils down to: all functions
are module-scoped closures.
A closer translation: "How do I implement module-scoped closures in
Parrot?"
OK, I've roughed out an implementation:
http://intertwingly.net/stories/2004/10/18/scopes.pir
http://intertwin
Sam Ruby wrote:
Unfortunately, these PMCs don't seem to have test cases.
Correction: t/pmc/sub.t
- Sam Ruby
Aaron Sherman wrote:
On Mon, 2004-10-18 at 07:55, Sam Ruby wrote:
I've been trying to make sense of Python's scoping in the context
of Parrot, and posted a few thoughts on my weblog:
http://www.intertwingly.net/blog/2004/10/18/Python-Parrot-and-Lexical-Scopes
It seems like everything on that page b
On Mon, 2004-10-18 at 07:55, Sam Ruby wrote:
> I've been trying to make sense of Python's scoping in the context of
> Parrot, and posted a few thoughts on my weblog:
>
> http://www.intertwingly.net/blog/2004/10/18/Python-Parrot-and-Lexical-Scopes
It seems like everything on that page boils down
Perl5 has the notion of contexts, where an expression may behave very
differently in string, boolean, or list context. Perl6 intends to expand
that notion. What if the whole context notion were moved down into
Parrot? Every function call and every MMD dispatch could have an
additional context param
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
> In Python terms, __add__ is but one of several methods that strings
> have. Other common ones include index, join, lower, replace, and split.
I just used __add__ as an example. Of course all (differing) vtables and
methods would need
Leopold Toetsch wrote:
Dan Sugalski wrote:
At 2:03 PM -0400 10/11/04, Sam Ruby wrote:
Separate op won't work for Python. Consider:
def f(x,y): return x+y
print f(5,6) # 11
print f("a","b") # ab
Oh, sure it'd work, if you had an ADD_OR_CONCATENATE op with an
appropriate MMD table. :)
Yes
On Oct 6, 2004, at 11:49 PM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
3) I won't mention the problem of languages which allow an object to
have instance variables and instance methods of the same name (so that
in Python, "a.b" would be ambiguous if "a" is an object from such a
Jeff Clites <[EMAIL PROTECTED]> wrote:
> 2) I'd expect the method cache to be per-class, but Python can change
> an attribute slot on a per-instance basis (as well as a per-class
> basis), so we can't really use a per-class method cache (or, we need a
> flag on particular instances which tell us n
Jeff Clites <[EMAIL PROTECTED]> wrote:
> Python's method call semantics allows you to look up a method of an
> object as an attribute, store it in a variable, and later invoke it
> like a regular function.
Random note: this sounds very much like a Df^H^HC# delegate.
> This works similarly if you
On Oct 6, 2004, at 1:11 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
To put it another way, the expression "foo.bar()" in Python doesn't
really parse as "invoke method bar on object foo", but rather as
"lookup attribute bar on object foo
Well, there isn't much difference here.
Jeff Clites <[EMAIL PROTECTED]> wrote:
> Do we have plans on how we might implement this via Parrot?
Sure.
> To put it another way, the expression "foo.bar()" in Python doesn't
> really parse as "invoke method bar on object foo", but rather as
> "lookup attribute bar on object foo
Well, there i
On Thu, 2004-07-15 at 22:46, Dan Sugalski wrote:
> And language builtin namespaces in general. We need a standard, and
> now's as good a time as any, so...
>
> All language-specific builtin functions go into the _core_Language
> namespace. (So for Python it's _core_Python, Perl 5 is _core_Perl5,
On Fri, Jul 16, 2004 at 12:02:15AM -0400, Dan Sugalski wrote:
> At 10:17 PM + 7/15/04, Steve Peters wrote:
> >On Friday 16 July 2004 02:46 am, Dan Sugalski wrote:
> >> And language builtin namespaces in general. We need a standard, and
> >> now's as good a time as any, so...
> >>
> >> All langu
At 10:17 PM + 7/15/04, Steve Peters wrote:
On Friday 16 July 2004 02:46 am, Dan Sugalski wrote:
And language builtin namespaces in general. We need a standard, and
now's as good a time as any, so...
All language-specific builtin functions go into the _core_Language
namespace. (So for Python
On Friday 16 July 2004 02:46 am, Dan Sugalski wrote:
> And language builtin namespaces in general. We need a standard, and
> now's as good a time as any, so...
>
> All language-specific builtin functions go into the _core_Language
> namespace. (So for Python it's _core_Python, Perl 5 is _core_Perl5
On Mon, 12 Jul 2004, Gregor N. Purdy wrote:
> Leo --
>
> I had tinkered around with this stuff back in 2003, and ended up writing
> Python::Bytecode::SAX to help me visualize bytecode. IIRC, I ran into
> the same issue of only disassembling one code block.
I've finished up (yay, free time at lunc
Leo --
I had tinkered around with this stuff back in 2003, and ended up writing
Python::Bytecode::SAX to help me visualize bytecode. IIRC, I ran into
the same issue of only disassembling one code block. I'd be interested
to know if P::B::S treats your example python bytecode any better than
P::B. I
Leopold Toetsch wrote:
... is on CPAN (said Dan) and is broken. I'd be glad if people could fix
it and send me a running version ;)
* constants are messed up
* it doesn't disassemble all code objects of a .pbc - just one
If you could give me a bit more to go on, I'd be willing to give this a
sho
Leopold Toetsch wrote:
... is on CPAN (said Dan) and is broken. I'd be glad if people could fix
it and send me a running version ;)
* constants are messed up
* it doesn't disassemble all code objects of a .pbc - just one
If you could give me a bit more to go on, I'd be willing to give this a
shot
On Mon, 2004-07-05 at 19:27, Dan Sugalski wrote:
UNARY_NEGATIVE: restore $Px; new $Py, Undef; $Py = $Px * -1; save $Py |
$Px = -1 * $Px
Wouldn't something this do what is desired? I'm just guessing, though.
Brian
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The translation for a number of the python ops depends on whether
> we're going with runtime stack action or compile-time stack->register
> translations.
My experiments[1] show that the latter should be doable, the more because
...
> BINARY_:
>restor
I don't think that Dan meant that Python-on-Parrot would be 20x faster.
He's saying that it's easy to speed up Python if you leave out the slow
parts, and that the Python-on-.NET implementation has left out the slow
parts so far. So when it's complete, Python-on-.NET will end up slower
than "re
Michal Wallace <[EMAIL PROTECTED]> wrote:
> Looking more at exceptions here... I
> used to be able to put arbitrary
> stuff in the _message slot of a
> ParrotException... Now we can only use
> strings. Is that permanent?
Depends on what exceptions finally are. But the standard entries like
"_mess
David Grove <[EMAIL PROTECTED]> writes:
>> Perl is far more practical than experimental.
> Not at the moment. That's the problem.
Pretty much everything proposed, even in the wildest RFCs during the
brainstorming phase, was still stuff that's been done elsewhere by other
languages. That's the
> Perl is far more practical than experimental.
Not at the moment. That's the problem.
(Note the subtle subject change back to its original intent.)
p
Vijay Singh <[EMAIL PROTECTED]> writes:
> I always expected Perl to be leading the way, *the* language that broke
> new ground..."where only camels dared to tread..."
Er... that strikes me as a strange expectation. I can't think of much in
Perl that hasn't appeared elsewhere earlier. Perl make
> Perl is looking a bit shaky at the moment.
Yeah. I think I understand what you mean by "shaky".
I always expected Perl to be leading the way, *the* language
that broke new ground..."where only camels dared to tread..."
Now we find that Perl6 is just huffin' and puffin' its way
to *catch up*
> -Original Message-
> From: Vijay Singh [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, June 02, 2001 10:02 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Python...
>
>
>
> Python? Didn't know you were so into tuples...
>
> I thought you
On Sun, Jun 03, 2001 at 10:48:11PM +0100, Piers Cawley wrote:
> > Oh, hrm. I wonder if I could use the functions from the Ruby runtime
> > as custom ops.
>
> You are a very bad man. Go to it.
I would do, but I'm getting segfaults when I reimplement op.c in Perl.
Unfortunately, I'm not joking.
-
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Sun, Jun 03, 2001 at 09:42:37PM +0100, Piers Cawley wrote:
> > Apart from the minor issue of Leon not having ported all the runtime
> > libraries (in annoying C) yet.
>
> Because I'm hacking at the bytecode level, I can replace the relevant
> subrout
On Sun, Jun 03, 2001 at 09:42:37PM +0100, Piers Cawley wrote:
> Apart from the minor issue of Leon not having ported all the runtime
> libraries (in annoying C) yet.
Because I'm hacking at the bytecode level, I can replace the relevant
subroutine calls to Perl builtins.
Oh, hrm. I wonder if I co
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Sun, Jun 03, 2001 at 02:02:03AM +, Vijay Singh wrote:
> > I thought your head would be turned by Ruby ;-)
> >
> > BTW - There's a Ruby "Inline::Perl" module in alpha testing
> > now...this will be a nice complement to the "Inline::Python"
> > mod
On Sun, Jun 03, 2001 at 02:02:03AM +, Vijay Singh wrote:
> I thought your head would be turned by Ruby ;-)
>
> BTW - There's a Ruby "Inline::Perl" module in alpha
> testing now...this will be a nice complement to the
> "Inline::Python" module already available...
And today I put the finishin
Python? Didn't know you were so into tuples...
I thought your head would be turned by Ruby ;-)
BTW - There's a Ruby "Inline::Perl" module in alpha
testing now...this will be a nice complement to the
"Inline::Python" module already available...
Must dash - Vijay
--
__
84 matches
Mail list logo
