Dan Sugalski wrote:
At 3:49 PM -0500 11/4/04, Sam Ruby wrote:
Background: Pmc2c.pm emits code which references Parrot_PMC_typenum.
This code is present in libparrot.so, which currently is not
referenced as a library by the link step for dynclasses.
Options include:
1) eliminating
Sam Ruby wrote:
I have a simple unit test[1], one that was not intended to be a
benchmark.
I probably should have included the following in my email *blush*:
[1] http://intertwingly.net/stories/2004/11/05/parrot/t/dynclass/pyint.t
- Sam Ruby
Jeff Clites wrote:
On Nov 3, 2004, at 8:09 AM, Dan Sugalski wrote:
At 11:04 AM -0500 11/3/04, Sam Ruby wrote:
A single pow_p_p_p op backed by a (non-MMD) vtable entry would make
it easier to support code like the following:
def f(x): return x**3
print f(3), f(2.5)
Yeah, it would. I know
Dan Sugalski wrote:
At 10:07 AM +0100 11/4/04, Leopold Toetsch wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
Attached patch makes building in the dynclass ghetto a bit less
inhospitable...
Thanks, applied.
Are we comfortable adding the dynclasses to the default build target? I
want to at some point
into each shared library
3) linking to libparrot.so
As an added complication, the link step for dynclasses is by default run
from a different directory than the main build.
Preferences?
- Sam Ruby
This omission seems odd. Was this intentional?
A single pow_p_p_p op backed by a (non-MMD) vtable entry would make it
easier to support code like the following:
def f(x): return x**3
print f(3), f(2.5)
- Sam Ruby
Dan Sugalski wrote:
At 11:04 AM -0500 11/3/04, Sam Ruby wrote:
This omission seems odd. Was this intentional?
Nope.
A single pow_p_p_p op backed by a (non-MMD) vtable entry would make it
easier to support code like the following:
def f(x): return x**3
print f(3), f(2.5)
Yeah, it would. I
syntax won't be a problem, it's quite straightforward).
(2): what is causing my strange result (see below).
[snip]
# foo(q)
.arg q
$P0()
Try this instead:
$P0(q)
- Sam Ruby
Attached patch makes building in the dynclass ghetto a bit less
inhospitable...
- Sam Ruby
? pyint.imc
? test.imc
? config/gen/makefiles/.dynclasses_pl.in.swp
? dynclasses/pyboolean.pmc
? dynclasses/pydict.pmc
? dynclasses/pyfloat.pmc
? dynclasses/pyfunc.pmc
? dynclasses/pyint.pmc
? dynclasses
+ print S0
- Sam Ruby
and perform a
us-ascii uppercase on them. The remaining bytes are left alone.
Example output:
u'\u0061\u00e1'.upper()
u'A\xc1'
'\x61\xe1'.upper()
'A\xe1'
u'\u0061\u00e1'.encode('iso-8859-1').upper()
'A\xe1'
- Sam Ruby
Dan Sugalski wrote:
At 5:43 PM + 11/2/04, Nicholas Clark wrote:
On Tue, Nov 02, 2004 at 12:35:26PM -0500, Sam Ruby wrote:
However, str has an upper() method defined on it. The way it operates
is to take the range of bytes that correspond to us-ascii and perform a
us-ascii uppercase on them
@MAIN
$P0=new PerlInt
$P0=1
$P1=new PerlInt
set $P1, $P0
$P2=new PerlInt
setref $P2, $P0
$P0=2
print $P1 =
print $P1
print \n
print $P2 =
print $P2
print \n
.end
- Sam Ruby
Dan Sugalski wrote:
At 1:16 PM -0500 11/2/04, Sam Ruby wrote:
Dan Sugalski wrote:
At 5:43 PM + 11/2/04, Nicholas Clark wrote:
On Tue, Nov 02, 2004 at 12:35:26PM -0500, Sam Ruby wrote:
However, str has an upper() method defined on it. The way it
operates
is to take the range of bytes
interpreter has exactly one const_cstring_table, and
there is no string_register function. Additionally, c2str.pl would need
to maintain a separate all_cstring.str file per library.
Does this sound about right?
- Sam Ruby
be ignored.
If all this seems too abstract or complicated, remember that it can be
implemented incrementally, and as needed.
If logger methods map to a vtable, performance when logging is disabled
should not be a significant concern.
I'm willing to help.
- Sam Ruby
[1] http://logging.apache.org/log4j
={a:a}
a=2
print d
a=[1]
d={a:a}
a[0]=2
print d
The correct result is:
{'a': 1}
{'a': [2]}
With pie-thon, the results are:
{'a': 2}
{'a': [2]}
- Sam Ruby
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Objects/dictnotes.txt?view=markup
http://cvs.sourceforge.net
: previously base_type for dynclasses was set twice in dynclasses.
I'm not clear why this was done. If this is important, this will need
to be restored; but without it dynclasses/dynfoo.pasm passes anyway.
- Sam Ruby
Index: config/gen/makefiles/root.in
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
for int is
attached). I want to pass the CPython test suite. And pass the
parrot/languages/python/t/pie tests.
- Sam Ruby
entry in the VTABLE for each object.
- Sam Ruby
on the mailing list. Suggestions welcome, in
particular, a PIR equivalent to the Perl would be most helpful.
- 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
Sam Ruby wrote:
Unfortunately, these PMCs don't seem to have test cases.
Correction: t/pmc/sub.t
- Sam Ruby
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
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
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 difference
Leopold Toetsch wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
It still doesn't make sense to me. Try adding the following line to
both fixedpmcarray.pmc and perlint.pmc:
METHOD INTVAL inheritme() { return 42; }
Ok, that's exactly that part, which currently *is* broken. If you have
some time please
Leopold Toetsch wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
Concrete example: should ResizablePMCArray inherit sort from FixedPMCArray?
Yes. But the inheritance should be (and is AFAIK already partially) in
the method lookup. But it's not quite finished. Objects derived from
PMCs inherit methods
Dan Sugalski wrote:
At 9:33 AM -0400 10/15/04, Sam Ruby wrote:
Leopold Toetsch wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
Concrete example: should ResizablePMCArray inherit sort from
FixedPMCArray?
Yes. But the inheritance should be (and is AFAIK already partially) in
the method lookup. But it's
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
for such cases is warranted.
- Sam Ruby
#! perl -w
# Copyright: 2001-2003 The Perl Foundation. All Rights Reserved.
# $Id$
=head1 NAME
t/pmc/buildin-meths.t - Builtin Methods
=head1 SYNOPSIS
% perl -Ilib t/pmc/builtin-meths.t
=head1 DESCRIPTION
Tests the ability to add methods
Dan Sugalski wrote:
At 4:23 PM -0400 10/9/04, Michal wrote:
On Sat, 9 Oct 2004, Sam Ruby wrote:
Inheritance can reduce the combinatorial problem, but it can
introduce a
precendence question. The most interesting case still seems to be:
mmd_lookup(MMD_ADD, PerlString, PyString)
What
this into a complete Python object model, focusing first on
being a faithful implementation of Python, initially at the expense of
interlanguage interop.
Seems like the right thing to do to me.
As I am doing this work, should I put this on my server some place?
Check it in some place? Send it as patches?
- Sam
Fix for a minor problem. Found by inspection.
- Sam Ruby
.sub main @MAIN
$P1 = new PerlInt
$P1 = 5
$P2 = new PerlNum
$P2 = 0.2
$P3 = new PerlNum
$P3 = $P1 / $P2
print $P3
print \n
.end
? classes/pyboolean.pmc
? classes/pydict.pmc
? classes/pyfloat.pmc
? classes
of
PMCs per language.
Inheritance can reduce the combinatorial problem, but it can introduce a
precendence question. The most interesting case still seems to be:
mmd_lookup(MMD_ADD, PerlString, PyString)
- Sam Ruby
in this function)
src/dynext.c:147: error: (Each undeclared identifier is reported only once
src/dynext.c:147: error: for each function it appears in.)
src/dynext.c:176: error: `PARROT_SHARE_EXT' undeclared (first use in this function)
make: *** [src/dynext.o] Error 1
- Sam Ruby
Leopold Toetsch wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
Doesn't compile for me on Debian. Did a header file change not get
checked in?
Did you reconfigure: perl Configure.pl, possibly after make clean?
DOH! Thanks.
- Sam Ruby
be removed from the Perl PMCs? If
so, when?
- Sam Ruby
error:imcc:parse error, unexpected FLOATV, expecting IDENTIFIER
in file 'test/for.pir' line 2
- Sam Ruby
/10/04/summary.html
http://intertwingly.net/stories/2004/10/05/summary.html
- Sam Ruby
Comparison of various Python implementations for conformance:
http://www.intertwingly.net/blog/2004/10/04/Comparing-Pythons
- Sam Ruby
... not so much sense.
Here's another one:
http://www.onlamp.com/pub/a/python/2003/04/17/metaclasses.html
- Sam Ruby
to identify what
codebase is most likely to attract a sustainable community of developers.
- Sam Ruby
Please forgive the newbie question, but I am trying to see if I can
assess the current state of Python on Parrot to see if I can help in any
way.
I've jotted down some of what I have found so far here:
http://www.intertwingly.net/blog/2004/10/02/Pyrate
- Sam Ruby
101 - 145 of 145 matches
Mail list logo
