Re: [PROPOSAL] VTABLE_call_method
Sam Ruby [EMAIL PROTECTED] wrote: Ramblings on creating a new VTABLE_call_method slot to help with implementing Python's bound vs unbound methods: http://www.intertwingly.net/blog/2005/01/03/Bound-Methods 1) Methods are functions, where the first parameter is the object. We are currently passing the object (or the invocant) in current_object In subs denoted with method we have the magic self, which makes it available for user code. This doesn't match HLLs expectations and sematics. Proposal: P5 := object := invocant for method calls ex-P2 := current_invocant (now current_object aka self) So given: def index(self, substr) We have the common case of a method call and matching arguments: parrot.index(r) P5 ... parrot P6 ... r current_invocant ... parrot With an unbound method call: str.index(parrot, r) with this register setup prior to the call: P5 ... str P6 ... parrot P7 ... r current_invocant ... str we have to do: if (PObj_is_class_TEST(object)) shift_arguments(...); and we have again arguments matching. 2) WRT the proposed VTABLE_call_method() This just moves the burden of doing a method call down to all classes and doesn't really fix anything. 1) is not python-specific. Moving the code into language-specific PMCs hinders interoperbility and causes unneeded code duplication. - Sam Ruby leo
Re: cvs commit: parrot/t/pmc resizablestringarray.t
On Mon, Jan 03, 2005 at 10:13:53PM -, Simon Glover wrote:
+output_is('CODE', 'OUTPUT', 'pop many values');
+ new P0, .ResizableStringArray
+ set I0, 0
+L1: set S0, I0
+ set P0[I0], S0
+ inc I0
+ lt I0, 10, L1
^this^
really really hurts.
The test seems to hang. Actually, it's just taking forever (not sure how
close an approximation that is) for --gc-debug. If I run without -gc-debug
it completes.
Timings for a run of 10,000 (not 100,000) on a 1.2 GHz Powerbook are
$ time ./parrot --gc-debug t/pmc/resizablestringarray_11.pasm
ok
real0m18.438s
user0m15.880s
sys 0m0.420s
whereas 9000 is
real0m18.438s
user0m15.880s
sys 0m0.420s
so the slowdown is worse than linear.
It's also tying up a fast x86 FreeBSD box, so it's not something PPC or
OS X specific.
Did it really need to be higher than (say) 5000?
Nicholas Clark
Re: pop_pad
Peter Christopher [EMAIL PROTECTED] wrote: Hi there, Is there a reason that `op pop_pad(out PMC)' has not been implemented yet? (It's in ops/var.ops). If so, could someone give me a quick heads up as to that reason. Forgotton? Anyway, it's in. Tests welcome. Pete leo
Re: Resizable array questions
Simon Glover [EMAIL PROTECTED] wrote: 1) When we resize a Resizable*Array (where * = Integer, Float or String) by calling set_integer_native, we also set the PMC's active_destroy flag. However, we don't do this when resizing a ResizablePMCArray (which also has a different memory allocation strategy). Is this because we don't strictly need to, or is this just an oversight? Just an oversight as well as in FixedPMCArray. 2) Why does the ResizablePMCArray PMC use a different memory allocation strategy, i.e. what advantage does it have over the strategy used by the other Resizable arrays? Just doubling the allocation size isn't a really good strategy beyond some big size. So I've implemented a IMHO better strategy in the PMCArray. Additionally the helper structure Size*Data isn't really needed. Simon leo
Re: parrot-0.1.1 make test and nci
Ian Joyce [EMAIL PROTECTED] wrote: Pardon me if this is the wrong list for this question. No, you are quite right here. I'm attempting to build parrot-0.1.1. Parrot is evolving quickly. You might consider to use the CVS version. t/pmc/nci..NOK 5# Failed test (t/pmc/nci.t at line 181) libnci.so exists at runtime/parrot/dynext/libnci.so This is fixed in CVS. But you could do: perl Configure.pl --prefix=$(pwd) to get the install and test paths matching. --Ian leo
Re: cvs commit: parrot/t/pmc resizablestringarray.t
Nicholas Clark [EMAIL PROTECTED] wrote: On Mon, Jan 03, 2005 at 10:13:53PM -, Simon Glover wrote: + lt I0, 10, L1 ^this^ really really hurts. It's already reduced in CVS. Nicholas Clark leo
Re: [PROPOSAL] VTABLE_call_method
Leopold Toetsch wrote: Sam Ruby [EMAIL PROTECTED] wrote: Ramblings on creating a new VTABLE_call_method slot to help with implementing Python's bound vs unbound methods: http://www.intertwingly.net/blog/2005/01/03/Bound-Methods 1) Methods are functions, where the first parameter is the object. We are currently passing the object (or the invocant) in current_object In subs denoted with method we have the magic self, which makes it available for user code. This doesn't match HLLs expectations and sematics. Proposal: P5 := object := invocant for method calls ex-P2 := current_invocant (now current_object aka self) So given: def index(self, substr) We have the common case of a method call and matching arguments: parrot.index(r) P5 ... parrot P6 ... r current_invocant ... parrot With an unbound method call: str.index(parrot, r) with this register setup prior to the call: P5 ... str P6 ... parrot P7 ... r current_invocant ... str we have to do: if (PObj_is_class_TEST(object)) shift_arguments(...); and we have again arguments matching. How should the following be handled: f = parrot.index ... print f(r) 2) WRT the proposed VTABLE_call_method() This just moves the burden of doing a method call down to all classes and doesn't really fix anything. 1) is not python-specific. Moving the code into language-specific PMCs hinders interoperbility and causes unneeded code duplication. I've learned to expect such a predictable response. The exact same number of lines of code, and the exact same external behavior somehow magically hinders interoperability and causes unneeded code duplication. Whatever. - Sam Ruby
Re: [PROPOSAL] VTABLE_call_method
Sam Ruby [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
How should the following be handled:
f = parrot.index
The CPython code is:
1 0 LOAD_CONST 0 ('parrot')
3 LOAD_ATTR0 (index)
6 STORE_NAME 1 (f)
The interesting thing is hidden in LOAD_ATTR. It seems that it creates a
call stub for the given (object, method) pair.
...
print f(r)
That looks like and is a plain function call (BTW it's not covered by
your call_method proposal). The f object (the method call stub) has to
shift up call arguments and place the object as the first argument.
2) WRT the proposed VTABLE_call_method()
This just moves the burden of doing a method call down to all classes
and doesn't really fix anything. 1) is not python-specific. Moving the
code into language-specific PMCs hinders interoperbility and causes
unneeded code duplication.
I've learned to expect such a predictable response. The exact same
number of lines of code, and the exact same external behavior somehow
magically hinders interoperability and causes unneeded code duplication.
What is unclear about: This just moves the burden of doing a method
call down to all classes and doesn't really fix anything.?
Whatever.
Again: the problem is *not* python-specific.
- Sam Ruby
leo
Re: cvs commit: parrot/t/pmc resizablestringarray.t
On Tue, 4 Jan 2005, Nicholas Clark wrote:
On Mon, Jan 03, 2005 at 10:13:53PM -, Simon Glover wrote:
+output_is('CODE', 'OUTPUT', 'pop many values');
+ new P0, .ResizableStringArray
+ set I0, 0
+L1: set S0, I0
+ set P0[I0], S0
+ inc I0
+ lt I0, 10, L1
^this^
really really hurts.
Sorry about that - I converted the test from an existing one for
ResizableFloatArray, but forgot that in the string case there's a
much higher load on the GC system due to all the string headers.
I see no reason why it shouldn't be smaller.
Simon
Re: Perl 6 Summary for 2004-12-20 through 2005-01-03
Matt Fowles wrote: Perl 6 Summary for 2004-12-20 through 2005-01-03 s/conses/consensus/g ?
Re: [PROPOSAL] VTABLE_call_method
Leopold Toetsch [EMAIL PROTECTED] wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
How should the following be handled:
f = parrot.index
The CPython code is:
1 0 LOAD_CONST 0 ('parrot')
3 LOAD_ATTR0 (index)
6 STORE_NAME 1 (f)
The interesting thing is hidden in LOAD_ATTR. It seems that it creates a
call stub for the given (object, method) pair.
Thinking a bit further about that: we have one part of the method call,
i.e. the method lookup thingy:
str = new String
str = parrot
meth = find_method str, index # [1]
Now we'd have to associate the invocable PMC with the object, e.g.
assign meth, str # set an object slot inside the invocable
or maybe more explicit with a distinct PMC class:
func = new MethStub, meth# create a new PMC for invocable meth
assign func, object # associate object with it
Calling this PMC then has to shift up arguments by one and place the
remembered object as current_invocant and P5.
[1] The find_method is probaly just getattribute or whatever the HLL
compiler emits.
Comments?
leo
Re: parrot on x86 solaris 2.5.1 (and 2.7)
On Mon, Jan 03, 2005 at 01:29:10PM -0600, [EMAIL PROTECTED] wrote:
Please let me know if I'm being too dense or too, er, flippant here, I've
No, you seem to be spot on.
The 2.7 doesn't have Sun's cc/CC (too expensive) and so
(config/init/hints/solaris.pl):
my $link = Configure::Data-get('link');
# Going to assume Sun's compiler
# In which case we need to link with the C++ compiler (CC) rather than the
# C compiler (cc)
$link =~ s/\bcc\b/CC/;
Configure::Data-set('link', $link);
...
choked early on:
Determining what C compiler and linker to
use.done.
Determining if your C compiler is actually gcc..Linker failed (see
test.ldo)
test.ldo
Can't exec CC: No such file or directory at lib/Parrot/Configure/Step.pm
line 279.
which seems to say its not doing whatever that link stuff is doing, its
not working for the CC/g++ switch. Changing that subst:
# C compiler (cc)
#$link =~ s/\bcc\b/CC/;
# YAassumption - g++
$link =~ s/\bcc\b/g++/;
Configure::Data-set('link', $link);
I think I might have been at least part responsible for that code to use
CC for linking. The problem is that the linker really needs to be set
correctly (either way) later on. I tried this (the machine I have only
has the Sun compiler):
# If we're using Sun's compiler then we need to link with the C++ compiler (CC)
# rather than the C compiler (cc)
# If it turns out we're using gcc, then we need to make sure we're linking
# with g++, not gcc. We can't make this decision until later, because the
# gcc test hasn't been run yet.
my $solaris_cb = sub {
my ($key, $gccversion) = @_;
my $link = Configure::Data-get('link');
if ($gccversion) {
$link =~ s/g?cc/g\+\+/;
} else {
$link =~ s/\bcc\b/CC/;
}
Configure::Data-set('link', $link);
Configure::Data-deltrigger(gccversion, solaris_hints);
};
Configure::Data-settrigger(gccversion, solaris_hints, $solaris_cb);
but it seems that that doesn't change 'link':
$ grep ^LINK Makefile LINK = ccache cc -D_XPG6
LINKFLAGS = -xarch=v9 -L/usr/lib/sparcv9 -L/usr/ccs/lib/sparcv9
-L/opt/SUNWspro/prod/lib/v9 -L/usr/local/lib -g
(should be CC)
so I'm inferring that that callback didn't get called when gccversion is
false. So this gets me to limit of my Parrot Configure knowledge - how do
we run a callback unconditionally after gccversion is known, independent
of its value?
Nicholas Clark
Re: [PROPOSAL] VTABLE_call_method
Leopold Toetsch wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
How should the following be handled:
f = parrot.index
The CPython code is:
1 0 LOAD_CONST 0 ('parrot')
3 LOAD_ATTR0 (index)
6 STORE_NAME 1 (f)
The interesting thing is hidden in LOAD_ATTR. It seems that it creates a
call stub for the given (object, method) pair.
...
print f(r)
That looks like and is a plain function call (BTW it's not covered by
your call_method proposal). The f object (the method call stub) has to
shift up call arguments and place the object as the first argument.
2) WRT the proposed VTABLE_call_method()
This just moves the burden of doing a method call down to all classes
and doesn't really fix anything. 1) is not python-specific. Moving the
code into language-specific PMCs hinders interoperbility and causes
unneeded code duplication.
I've learned to expect such a predictable response. The exact same
number of lines of code, and the exact same external behavior somehow
magically hinders interoperability and causes unneeded code duplication.
What is unclear about: This just moves the burden of doing a method
call down to all classes and doesn't really fix anything.?
First you state The f object (the method call stub) has to
shift up call arguments and place the object as the first argument.
In other words, moving the burden of doing the marshalling of parameters
down to the class really *does* fix something.
Then you state that moving the burden in a similar case doesn't fix
anything.
Whatever.
Again: the problem is *not* python-specific.
Analogy: is classes/string.pmc Perl Specific?
I anticipate each language will need a language specific string class.
Hopefully each will inherit much of their functionallity from Parrot's
string class once all the multiple inheritance and MMD issues are worked
out.
In a similar manner, I expect many languages will need a language
specific class class. Again, hopefully each will inherit much of
their functionallity from a Parrot class class.
If you take a look at my recent commit, you will see that the way that
bound methods are implemented in Python leverages the way that Python
Properties are defined. This isn't merely an implementation choice -
this is the way the language is defined, and t/pie/b0.t seems carefully
crafted to ensure that the implementation faithfully implements this
part of the Python language definition.
I suspect that much of this is Python specific. That's why it is nice
that VTABLE_get_attr_str is a VTABLE entry and not hardwired into
Parrot_getattribute_p_p_sc.
In a similar manner, I expect most languages to implement call_method to
either simply inherit the default or to implement the same basic flow of
find_method followed by invoke. What is in between those two calls,
however, may vary based on language - for example, what exception is to
be thrown if the method is not found may vary from language to language.
However, I can't override this behavior if it remains hardcoded in the
op. Moving the burden down to the classes *does* allow me to fix
something - it enables me to throw the exception that Python developers
will expect, and will allow me to avoid the creation of bound method
objects in many cases.
- Sam Ruby
Re: Perl 6 Summary for 2004-12-20 through 2005-01-03
Austin Hastings [EMAIL PROTECTED] writes: s/conses/consensus/g ? I assumed it was a Lisp reference. ;-) Jon
Re: Perl 6 Summary for 2004-12-20 through 2005-01-03
--- Jon Ericson [EMAIL PROTECTED] wrote: Austin Hastings [EMAIL PROTECTED] writes: s/conses/consensus/g ? I assumed it was a Lisp reference. ;-) contheth? (No, I'm not really *quite* that clueless.) Cheers, Ovid = Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: strictness and fully qualified global vars
On Tue, Dec 28, 2004 at 10:31:37PM -0800, Ashley Winters wrote:
: On Tue, 28 Dec 2004 22:31:47 -0700, Luke Palmer [EMAIL PROTECTED] wrote:
: Ashley Winters writes:
: sub foo (Class $who) {
: my $thing := $who$var;
: my func := $whofunc; # how would I do this otherwise?
: }
:
: In current Perl 6:
:
: sub foo (Class $who) {
: my $thing := $::($who)::var;
: my func := ::($who)::func;
: }
:
: Okay, I see. S10 says ::() is the catch-all symbolic naming syntax.
: However, $who would be a reference to a class object itself. Does it
: automagically accept hard-references, or would Class objects have to
: stringify to their global ::*::ClassName?
:
: More to the point, is %::(%foo) an identity op?
We will probably make hard refs work inside ::() just to make it easier
to translate Perl 5 to Perl 6. But possibly it should require a laxity
pragma to enable it. If we end up with people simply writing $::($x)
everywhere instead of ${$x}, we haven't gained anything over Perl 5,
and we've lost strict refs. I don't want people to get in the habit
of using ::() for hard refs unless they explicitly want symbolic refs
as well. I was hoping that the mere length of $::() over ${} would
be enough to discourage that kind of thinking, but now I'm not so sure.
Larry
Re: Perl 6 Summary for 2004-12-20 through 2005-01-03
Austin~ On Tue, 04 Jan 2005 11:20:25 -0500, Austin Hastings [EMAIL PROTECTED] wrote: Matt Fowles wrote: Perl 6 Summary for 2004-12-20 through 2005-01-03 s/conses/consensus/g ? Indeed. Let this be a lesson to anyone who would claim that just running spell check is enough. Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: cvs commit: parrot/t/pmc resizablestringarray.t
Simon Glover [EMAIL PROTECTED] wrote: Sorry about that - I converted the test from an existing one for ResizableFloatArray, but forgot that in the string case there's a much higher load on the GC system due to all the string headers. Actually the problem aren't the string headers per se. The string compares were triggering 100.000 DOD runs with --gc-debug. Simon leo
Re: [PROPOSAL] VTABLE_call_method
Sam Ruby [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: What is unclear about: This just moves the burden of doing a method call down to all classes and doesn't really fix anything.? First you state The f object (the method call stub) has to shift up call arguments and place the object as the first argument. Yes. See another message I've posted WRT that. In other words, moving the burden of doing the marshalling of parameters down to the class really *does* fix something. Er, no. Because whatever you do, your (anybodies) HLL compiler will just emit a plain function call in that case. Your proposed call_method vtable doesn't cover it all. So just pushing down the problem to *all* classes that implement function or method calls doesn't help. Parrot itself has to deal with it. Then you state that moving the burden in a similar case doesn't fix anything. Yes, because it is *not* python-specific. We've to approach a common solution for all supported languages. Whatever. Again: the problem is *not* python-specific. Analogy: is classes/string.pmc Perl Specific? People including me have submitted lot of patches to get Perl* out of core PMCs. So string.pmc should end up in a usable base for many string functions. I anticipate each language will need a language specific string class. Hopefully each will inherit much of their functionallity from Parrot's string class once all the multiple inheritance and MMD issues are worked out. Exactly that's the goal. Inheritance, code reuse, interoperbility. In a similar manner, I expect many languages will need a language specific class class. Again, hopefully each will inherit much of their functionallity from a Parrot class class. Well, the class PMC aka the metaclass of the class system is much more HLL specific. Not much can be inherited here. All that's not inheritable has to be done in vtable methods. ... That's why it is nice that VTABLE_get_attr_str is a VTABLE entry and not hardwired into Parrot_getattribute_p_p_sc. This nicety is coming from my desire for abstraction. I thought, it'll be needed. I've written committed these patches (against Dan's wishes...) In a similar manner, I expect most languages to implement call_method to either simply inherit the default or to implement the same basic flow of find_method followed by invoke. I'm fully in accordance with you up to here. But argument passing and method calls isn't currently in sync - Parrot is doing different things then HLLs are doing. Before this isn't fixed (and it needs fixing) I can't and won't go any further. *If* then something isn't working for Python or whatever language, we can look for a more generic way. And argument passing and method or function calls isn't really a python-only language feature. First Parrot needs to adhere to HLL semantics. ... What is in between those two calls, however, may vary based on language - for example, what exception is to be thrown if the method is not found may vary from language to language. These are minor problems. They have to be solved, as well as creating a HLL specific destination PMC in infix methods. First we've to fix the basics. However, I can't override this behavior if it remains hardcoded in the op. We can throw a language-sepcific exception. You can translate the exception type. There are many ways to address such problems. Later. - Sam Ruby leo
[perl #32354] [PATCH] update perlhist.txt
Thanks, applied. (Note: this patch had already been partially applied.) [bernhard - Sun Nov 07 05:17:56 2004]: Hi, this patch updates 'perlhist.txt', which is used as a test case in 't/library/streams.t'. 't/library/streams.t' now also uses the new one-line '.return () ' and '.yield ()' syntax. CU, Bernhard
[perl #28383] [PATCH] Update WHOIS... er, WHOWAS, info
I find it highly amusing that Warnock's patch to update Warnock's contact information was Warnocked since April of last year. I will put him out of his misery, though. I can only hope that the new email address isn't defunct already. =-) Thanks, applied! [EMAIL PROTECTED] - Thu Apr 08 14:02:32 2004]: The email address of record has only been defunct for a year and a half or so Updating references.
