Re: Classes with several, mostly unused, attributes
On Wed, 15 Dec 2004, Abhijit Mahabal wrote: #!/usr/bin/perl -e $x = 1; Is this supposed to work? I would tend to consider it counter intuitive... #!/usr/bin/perl v6; $x = 1; Incidentally, and on a totally OT basis, I've noticed that Perl6 is supposed to have v-strings. But (current) 'perldoc perldata' warns that they won't be there after 5.8: taking all this into account I wonder wether this would be a wyse choice. I mean: maybe it hasn't been such a good thing to introduce them in the first place, but now that they're there, it may be even worse to remove them... Michele -- The amount of repetition repetition isn't that great. - Ignacy Sawicki in comp.text.tex thread Bug in FeynMF's Queues?
Re: [ANNOUNCE] Test::Simple/More/Builder 0.54 (problem with signa ture?)
In message [EMAIL PROTECTED] (on 16
December 2004 16:45:01 +1100), [EMAIL PROTECTED] (Andrew Savige) wrote:
Steve Hay wrote:
is even worse: 1 second again on 5.8.6/perl-malloc versus 56
seconds on 5.8.4/system-malloc!
I'm pretty sure realloc() is the culprit here.
A common trick used by string classes is to double the memory
allocation whenever you need to grow a string, and so avoid
O(n-squared) performance when growing a string one char at a time.
For cheap thrills, I created the following patch against 5.8.6
to hack this memory doubling trick into Perl_sv_catpvn_flags():
--- sv-orig.c 2004-11-02 03:01:54.0 +1100
+++ sv.c 2004-12-16 15:04:39.0 +1100
@@ -4394,9 +4394,14 @@
{
STRLEN dlen;
char *dstr;
+STRLEN neededlen;
dstr = SvPV_force_flags(dsv, dlen, flags);
-SvGROW(dsv, dlen + slen + 1);
+neededlen = dlen + slen + 1;
+if (SvLEN(dsv) neededlen) {
+STRLEN s2 = SvLEN(dsv) * 2;
+SvGROW(dsv, s2 neededlen ? neededlen : s2);
+}
if (sstr == dstr)
sstr = SvPVX(dsv);
Move(sstr, SvPVX(dsv) + dlen, slen, char);
Though all tests passed, I don't know Perl internals well enough to
judge whether this hacky change is sound or not. I did it only out
of curiosity to see how it affected Steve's little benchmark.
After applying this patch, the performance of Steve's test program
above dropped from 26 seconds to 1 second when run on Windows XP
(when built with default system malloc). BTW, on Linux, the
improvement was hardly noticeable: from 0.86 secs to 0.51.
I'm interested to hear opinions on whether these sort of memory
heuristics are best done in the perl core or left to realloc().
Note that usage of perl's malloc is not an option on some systems (e.g.,
IRIX) - so putting improvements in perl's malloc, if I understand you
properly, is not helpful on said systems.
-Allen
--
Allen Smith http://cesario.rutgers.edu/easmith/
February 1, 2003 Space Shuttle Columbia
Ad Astra Per Aspera To The Stars Through Asperity
Re: [ANNOUNCE] Test::Simple/More/Builder 0.54 (problem with signa ture?)
On Thu, Dec 16, 2004 at 12:03:52PM -, Orton, Yves wrote: Perhaps you've got a damaged default MANIFEST.SKIP. Check what perldoc -m ExtUtils::MANIFEST.SKIP looks like. It should look like this. http://search.cpan.org/src/MSCHWERN/ExtUtils-MakeMaker-6.24/lib/ExtUtils/MAN IFEST.SKIP Not like this. http://search.cpan.org/src/MSCHWERN/ExtUtils-MakeMaker-6.24/MANIFEST.SKIP The files you originally linked to don't contain a MANIFEST.SKIP at all so that must be the problem. Not Test::More's MANIFEST.SKIP. The system's default MANIFEST.SKIP. ExtUtils::MANIFEST.SKIP. Run perldoc -m ExtUtils::MANIFEST.SKIP and see if it looks like either of the urls above. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ You're the sickest teenager I've ever set my wallet on.
Re: cvs commit: parrot/ops pmc.ops
Leopold Toetsch wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
I don't understand this. At all. But the test case added to pyclass.t
(motivated by test 4 in pie/b3.t) only passes if this change to the
get_repr op is made.
[ ... ]
-op get_repr(out STR, in PMC) {
-$1 = $2-vtable-get_repr(interpreter, $2);
+inline op get_repr(out STR, in PMC) {
+STRING *s = $2-vtable-get_repr(interpreter, $2);
+$1 = s;
goto NEXT();
}
Strange. Stranger. Strangest. Did the test fail with JIT/i386 only?
I didn't mean to commit the inline portion of the change... that
didn't make a difference.
I've never investigated how to select another core... I've done all my
runs using the default for i386. While in gdb, I have seen mention of
slow_core and in this case, breakpoints that I set on
Parrot_get_repr_s_p were hit.
The symptoms I see are that get_repr returns the correct string, but the
appropriate REG_STR does not get updated.
- Sam Ruby
RE: [ANNOUNCE] Test::Simple/More/Builder 0.54 (problem with signa ture?)
Not Test::More's MANIFEST.SKIP. The system's default MANIFEST.SKIP. ExtUtils::MANIFEST.SKIP. Run perldoc -m ExtUtils::MANIFEST.SKIP and see if it looks like either of the urls above. Ah, sorry. I didnt understand. Im just curious if i alter this file this will affect all make dist commands? Is there any chance the default could have .bak added in future releases? Also will the fact that some of the patterns depend on *NIX style paths be an issue on Win32? Im guessing not, but i think its worth asking. And no the version on my machine doesnt look (exactly) like either one you linked to: D:\Developmentperldoc -m ExtUtils::MANIFEST.SKIP # Avoid version control files. \bRCS\b \bCVS\b ,v$ \B\.svn\b # Avoid Makemaker generated and utility files. \bMANIFEST\.bak \bMakefile$ \bblib/ \bMakeMaker-\d \bpm_to_blib$ # Avoid Module::Build generated and utility files. \bBuild$ \b_build/ # Avoid temp and backup files. ~$ \.old$ \#$ \b\.# Cheers, Yves
Re: overloaded operator calling conventions
Leopold Toetsch wrote: Sam Ruby wrote: A few observations, first from an Parrot Internal perspective... in general, the code for the opcodes tend to do things like the following: $1-vtable-get_string(interpreter, $1) Note that the object tends to be repeated as the first argument. It often the case that the first argument matches the object on which the dispatch is based, but it is not necessarily so. In particular, these two values will be different whenever the implementation of a method wants to invoke the equivalent of SUPER(args). Not quite. That'll be class_self.__super(args) so again the invocant is the first argument after interpreter. Believe it or not, I think we are agreeing. To invoke a method on an object using Parrot Calling Conventions, P2 needs to be the object used for dispatch purposes, and P5 needs to be the actual object. In many cases, they will be the same, but in some cases they will differ. This isn't obvious from PDD03, but a simple clarification would take care of that. - Sam Ruby
Re: cvs commit: parrot/ops pmc.ops
Leopold Toetsch wrote:
Sam Ruby wrote:
Leopold Toetsch wrote:
+inline op get_repr(out STR, in PMC) {
+STRING *s = $2-vtable-get_repr(interpreter, $2);
+$1 = s;
goto NEXT();
}
Strange. Stranger. Strangest. Did the test fail with JIT/i386 only?
I didn't mean to commit the inline portion of the change... that
didn't make a difference.
op or inline has no effect
I've never investigated how to select another core...
$ parrot --help
specifically -j -S -C -g
Here's the results *with* the above change:
[EMAIL PROTECTED]:~/parrot$ parrot test.pir
5 T(5)
[EMAIL PROTECTED]:~/parrot$ parrot -j test.pir
5 T(5)
[EMAIL PROTECTED]:~/parrot$ parrot -S test.pir
5 T(5)
[EMAIL PROTECTED]:~/parrot$ parrot -C test.pir
5 T(5)
[EMAIL PROTECTED]:~/parrot$ parrot -g test.pir
5 T(5)
Here's the results *without* the above change:
[EMAIL PROTECTED]:~/parrot$ parrot test.pir
5
[EMAIL PROTECTED]:~/parrot$ parrot -j test.pir
5
[EMAIL PROTECTED]:~/parrot$ parrot -S test.pir
5 T(5)
[EMAIL PROTECTED]:~/parrot$ parrot -C test.pir
5 T(5)
[EMAIL PROTECTED]:~/parrot$ parrot -g test.pir
5
The symptoms I see are that get_repr returns the correct string, but
the appropriate REG_STR does not get updated.
Then there is a problem elsewhere. You can inspect interpreter registers
too:
gdb p *interpreter-ctx.bp
In Parrot_PyClass_get_repr, line 197 is:
temp = Parrot_run_meth_fromc_args(INTERP, repr, SELF, REPR, P);
Before this line is executed,
(gdb) p interpreter-ctx.bp
$1 = (struct parrot_regs_t *) 0x40b6bd88
After the above line is executed:
(gdb) p interpreter-ctx.bp
$2 = (struct parrot_regs_t *) 0x40b6bae8
Two questions come to mind:
1) Should this call to run_meth change the context? In this case, repr
happens to be a Closure based on some assumptions I made early on in
this process that I need to revisit. Arguably, this is a bug, but in
the general case, can one always assume that the context does not change?
2) If there is the possibility that the context can change, into which
context should the results of get_repr be placed? Splitting the
statement in op get_repr as I did above guarantees that the macro will
expand using the values *after* the call.
Note: if the context is not supposed to change as a result of runops,
perhaps an internal exception should be thrown.
- Sam Ruby
Re: cvs commit: parrot vtable.tbl
Sam Ruby wrote: My need is to be able to call add_method for methods defined as @ANON. This doesn't make sense to me. The @ANON pragma avoids the add_method (or store_global) call in the first place. From the perspective of Parrot, namespaces should be viewed a perfectly reasonable mechanism for implementing classes, and there perhaps should even be special support for enabling classes to be defined that way... but: there should be no built in assumptions that all classes are defined in this way. Yes. But OTOH a different scheme should only be used if it's unavoidable. - Sam Ruby leo
Re: cvs commit: parrot/ops pmc.ops
Sam Ruby wrote: Before this line is executed, (gdb) p interpreter-ctx.bp $1 = (struct parrot_regs_t *) 0x40b6bd88 After the above line is executed: (gdb) p interpreter-ctx.bp $2 = (struct parrot_regs_t *) 0x40b6bae8 Then is obviously your implementation of get_repr broken. Two questions come to mind: 1) Should this call to run_meth change the context? Yes because a subroutine is run. But returning from it via a (return-) continuation restores the context and the register frame pointer or it ought to. ... In this case, repr happens to be a Closure based on some assumptions I made early on in this process that I need to revisit. Arguably, this is a bug, but in the general case, can one always assume that the context does not change? Only function calls / returns may change the context. A simple opcode like get_repr isn't allowed to do that. Note: if the context is not supposed to change as a result of runops, perhaps an internal exception should be thrown. We can't check that on each opcode. That just must not happen :) But before you implement more and more methods I'd rather have inheritance and method calling conventions fixed. Parrot should call the approriate method if it exists in the class namespace (if find_method did return something). - Sam Ruby leo
Re: New qa.perl.org updates
--- Andy Lester [EMAIL PROTECTED] wrote: Patches, please. s/html$/pod/ in the URL for the source. Sorry. I should have gotten these out sooner. I was sidetracked. I've attached patches to add Test::MockModule to the module list and to add the use_ok() or die wording to the testing guidelines. I will confess that I was not entirely happy with my wording on the latter. 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/ testing-guidelines.pod.diff Description: testing-guidelines.pod.diff test-modules.pod.diff Description: test-modules.pod.diff
Re: Classes with several, mostly unused, attributes
On Fri, Dec 10, 2004 at 11:05:32AM -0500, Abhijit Mahabal wrote:
: Consider a class (e.g., the hypothetical Geometry::Triangle) that can
: have several attributes (side1, side2, side3, angle1, ang_bisector1,
: side_bisector, altitude1 and so forth), most of which will not be
: needed for most instances of Geometry::Triangle.
This sounds to me more like a situation where you want to use mixins,
if you're thinking of it as different kinds of triangles.
But more likely, you just want a single private hash attribute that is
manipulated by as many publicly facing methods as you like. Method
declarations don't cost you anything on a per-object basis unless they're
autogenerated from an attribute. But a hash attribute autovivifies
just like any ordinary hash variable, and is probably clearer as well
to whoever has to read your code.
Alternately, you can still bless a hash as you typically do in Perl 5,
but then you get most of the problems of Perl 5 if you want to derive
from your class.
: I know how this can be done in P5. Using the layout Hash things are
: easy. How can P6 deal with this, without allocating too much memory to
: things that'd never get used? The layout P6Hash could come to the
: rescue, but there is still the issue of syntax:
:
: what exactly does Chas $.bisector1 do?
It does whatever the metaclass says has should do. But you really want
to have a good reason for switching metaclass behavior from the default.
: IIRC, in the P6Opaque layout,
: every instance of the class would have space the size of a PMC allocated
: for it. This behavior is not needed for P6Hash, and it should just leave
: attributes alone until they are assigned to (where defaults are also
: assigns).
I think the overhead might just be a pointer to a PMC, but I'm not
an expert on Parrot OO internals.
: In which case, maybe for that layout we can get away without declaring
: all attributes, perhaps? (Since the declaration does nothing except help
: the parser).
The layouts are mostly intended to help in detecting impedance mismatches
between different languages' objects. Doubtless you can play games with
different layouts within Perl 6, but you should recognize that you'll run
into the same issues as you get with cross-language inheritance: you'll
probably end up with inheritance being emulated by delegation, which
is likely to induce various sorts of fragilities and inefficiencies.
: I was thinking whether we could do something like this:
:
: class Triangle is layoutP6Hash does autovivify{
: method calculate_bisectors { $.bisector1 = ...;
:# $.bisector1 autovivifies
: }
: }
:
: where it is an error without the autovivify, and only P6Hash supports
: autovivification.
I'd just use a hash attribute. All other things being equal, go for
simple and standard.
Larry
Re: cvs commit: parrot vtable.tbl
Leopold Toetsch wrote: Sam Ruby wrote: My need is to be able to call add_method for methods defined as @ANON. This doesn't make sense to me. The @ANON pragma avoids the add_method (or store_global) call in the first place. I don't want the method added to a namespace, or stored as a global. I want it stored as a property of a class object. From the perspective of Parrot, namespaces should be viewed a perfectly reasonable mechanism for implementing classes, and there perhaps should even be special support for enabling classes to be defined that way... but: there should be no built in assumptions that all classes are defined in this way. Yes. But OTOH a different scheme should only be used if it's unavoidable. Python classes are not namespaces. Nor are they global. They are dictionaries. Take a look at the last test in parrot/languages/python/t/basic/oo_class.t to get an idea of what I am talking about. - Sam Ruby
Re: Classes with several, mostly unused, attributes
Larry Wall wrote:
On Fri, Dec 10, 2004 at 11:05:32AM -0500, Abhijit Mahabal wrote:
: Consider a class (e.g., the hypothetical Geometry::Triangle) that can
: have several attributes (side1, side2, side3, angle1, ang_bisector1,
: side_bisector, altitude1 and so forth), most of which will not be
: needed for most instances of Geometry::Triangle.
This sounds to me more like a situation where you want to use mixins,
if you're thinking of it as different kinds of triangles.
But more likely, you just want a single private hash attribute that is
manipulated by as many publicly facing methods as you like. Method
declarations don't cost you anything on a per-object basis unless they're
autogenerated from an attribute. But a hash attribute autovivifies
just like any ordinary hash variable, and is probably clearer as well
to whoever has to read your code.
So, apart from declaring the methods, I just need to write
.bisector1 = ...;
instead of
$.bisector1 = ...;
Yes, that looks almost as nice as with the $, though perhaps a tad less.
That leaves the issue of writing several methods that look like:
method bisector1() is rw { return %:attbisector1 };
Here is an attempt to do this using traits:
#
role hash_attributes {
has %:att;
multi sub trait_auxillary:has(hash_attributes $trait,
Class $container :
[EMAIL PROTECTED]
){
$container does hash_attributes;
for @atts - $att {
($container)::($att) := method () is rw { return %:att{$att} };
}
}
}
class Geometry::Triangle
has hash_attributes == side1 side2 side3 angle1 angle2 angle3 ...
{
method calculate_sides(){
.side1 = ...;
}
}
#=
Does that look about right?
I'd just use a hash attribute. All other things being equal, go for
simple and standard.
Does it look about standard? (especially the bit using the pipe operator)...
Thanks,
abhijit
Re: Context, wrappers, and rules
Sam Ruby wrote:
Leopold Toetsch wrote:
Only function calls / returns may change the context. A simple opcode
like get_repr isn't allowed to do that.
The question isn't about what opcodes are or are not allowed to do. The
question is what VTABLE_* functions are or are not allowed to do. Can
VTABLE_invoke change the context? How about VTABLE_get_string?
Well, I think it's all answered in the two quoted lines. Cinvoke can
change the context, but the next opcode after invoke has again the
original context, because of the function return restores the context.
All other methods aren't allowed to change the context.
If you look at the current delegate PMC, every VTABLE call is translated
to a call of a method. Are such methods allowed to change the context?
The delegate vtables or MMD wrappers call a method. That returns with
the passed in return continuation. So all the wrapped methods behave
exactly as if an opcode would have done the job. So no.
If things invoked by runops are not allowed to change the context, then
runops should throw an internal exception if the context changes.
Well, as already said, that would need a check for each opcode and we
don't do that. It's like a C compiler should check the stack pointer
after each execute hardware opcode.
On the other hand, if runops can't change the context, then why is
runops_args careful to capture the context prior to calling runops?
Crunops is a low-level function that awaits all properly setup. Around
that are more function that e.g. create a return continuation and do
argument or returnvalue passing. Just use one of these functions as
delegate.c does.
Again, what are the rules?
Simple: plain opcodes don't change the context. A function call does,
but the return has to restore the context. Ovleroading doesn't change
anything here.
But before you implement more and more methods I'd rather have
inheritance and method calling conventions fixed.
How I chose to invest my time is up to me.
Of course. You have promised a summary ;)
The reason why I am proceeding this way is that I found the previous
discussions on topics like object, classes, and metaclasses to be
frustrating. I want the next round to be based on specifics.
I was very specific. Parrot (or the runcore, the engine) does method
dispatch (when all is fixed and adjusted).
add Px, Py, Pz
is equivalent to a method call:
Px = Py.__add(Pz)
The class (of Py) is queried via VTABLE_find_method() if it can do the
add, which will eventually cause more find_method calls to find a
matching or best suited MMD method. After the method is found, it'll be
called, being it a C function or an overloaded piece of code.
That'll cost some cycles on the first execution of this one opcode. The
next one on that bytecode location is running 30%-70% faster as the
current static MMD lookup.
The signature of an overloaded function for above is
.sub myadd
.param left
.param right
...
.return(dest)
.end
myadd can be added via add_method() to the class (as __add) or
Parrot picks up an existing __add in the appropriate namespace (which
will call add_method()). A class system can provide it's own
add_method/find_method pair or use Parrot's scheme.
The same basics holds for all overloadable operations, being it
currently vtable or MMD methods.
I want to be able to point at a specific wrapper and ask the question:
how could it be done better?
You need a wrapper, if the Parrot implementation of the method for that
class isn't matching Python semantics, e.g. to adjust return results. Or
you just install your own method, e.g. for __repr. Almost all basic
methematical, logical, bitwise, ... operations should just have a
reasonable implementation in core, and all HLLs will just use that.
Parrot_PyClass_get_repr is one such wrapper. How could it be done
better? If you make a specific suggestion there, I'll either adopt it
or produce a test case as a counter example.
You'd need in pyclass.pmc:
PMC* get_repr() {
return pmc_new_string( ... class ...)
}
A method that returns the string representation of a PyClass object.
That's not a wrapper but an implementation for one specific class. No
wrapper for other classes or a dispatch through run_meth_fromc_args is
needed.
Nothing more will be needed, *when* all is fixed:
* we return PMCs normally (other types are optimizations)
* the methods create new PMCs - no LHS PMC is passed in
* all overloadable MMDs and vtables are registered as NCI methods
like the current METHOD syntax in .pmc files.
* Parrot knows common type names (Integer, Float, String, Bool, ...) of
the supported languages
* all dispatch is based on VTABLE_find_method
That's a simple scheme and should be well suited for all current target
languages - IMHO.
- Sam Ruby
leo
runops_args vs NCI
pseudo-code for runops_args:
runops_args(PMC* sub, char* sig, va_list ap) {
dest = VTABLE_invoke(interpreter, sub, NULL);
REG_*[*] = ap[*], as appropriate
if (dest) runops
}
However, VTABLE_invoke on NCI methods is where the real work is done
(including reading from and writing to registers), and a null dest is
returned.
The net effect is that if you try to invoke a NCI with a signature of
PP, the NCI method will be called with whatever happens to be in
PMC_REG(5) at the time, and what it returns will be overwritten with
your first argument.
Is there a reason why the invoke couldn't be done immediately prior to
the call to runops?
- Sam Ruby
Re: Context, wrappers, and rules
Leopold Toetsch wrote:
Parrot_PyClass_get_repr is one such wrapper. How could it be done
better? If you make a specific suggestion there, I'll either adopt it
or produce a test case as a counter example.
You'd need in pyclass.pmc:
PMC* get_repr() {
return pmc_new_string( ... class ...)
}
Just to be clarify, this is from the header comment in pyclass.pmc:
These are the vtable functions for the Python Class base class (i.e.,
methods you would expect to see on python objects).
For reference, here is the current definition of get_repr.
%%%
/*
=item CSTRING *get_repr()
Return the representation of this object.
=cut
*/
STRING* get_repr() {
PMC *repr = VTABLE_find_method(INTERP, SELF, REPR);
if (repr) {
PMC *temp = Parrot_run_meth_fromc_args(INTERP, repr, SELF,
REPR,
PP, SELF);
return VTABLE_get_string(INTERP, temp);
}
else {
STRING *res;
res = string_from_cstring(INTERP, , 0);
res = string_append(INTERP, res,
VTABLE_name(INTERP, VTABLE_get_class(INTERP, SELF)), 0);
res = string_append(INTERP, res,
const_string(INTERP, instance at ), 0);
res = string_append(INTERP, res,
Parrot_sprintf_c(INTERP, %#x, (INTVAL) SELF), 0);
res = string_append(INTERP, res,
const_string(INTERP, ), 0);
return res;
}
}
%%%
In this case, there is a Python specific default. In other cases, there
are other Python specific behaviors like mapping not found to an
exception or to None. In short, I don't see wrappers going away.
A method that returns the string representation of a PyClass object.
That's not a wrapper but an implementation for one specific class. No
wrapper for other classes or a dispatch through run_meth_fromc_args is
needed.
Nothing more will be needed, *when* all is fixed:
* we return PMCs normally (other types are optimizations)
* the methods create new PMCs - no LHS PMC is passed in
* all overloadable MMDs and vtables are registered as NCI methods
like the current METHOD syntax in .pmc files.
get_repr is overloadable. Being overloadable is the norm rather than
the exception in Python.
* Parrot knows common type names (Integer, Float, String, Bool, ...) of
the supported languages
The alternative (which is supported today) is that callers pass in a PMC
which defines a morph method which maps common type names to language
specific alternatives. Take a look at PyObject.pmc where I substitute
PyLong for BigInt.
The advantage of what exists today is that adding a new language does
not require any changes to Parrot. The caller defines the mapping.
* all dispatch is based on VTABLE_find_method
Just to be clear, in the cases where a wrapper is needed (which I would
argue is the majority of cases), this works out to be: a call to
VTABLE_find_method for the wrapper which in turn uses VTABLE_find_method
to access the real logic.
That's a simple scheme and should be well suited for all current target
languages - IMHO.
Again, just to be clear: this hinges on dual assumptions: (1) that
wrappers aren't needed in the majority of cases, and (2) every time
someone gets or sets a method, a mapping can be done from language
defined names to Parrot conventions.
Note that in Python, all attributes may potentially be a method.
- Sam Ruby
Re: Context, wrappers, and rules
Leopold Toetsch wrote: On the other hand, if runops can't change the context, then why is runops_args careful to capture the context prior to calling runops? Crunops is a low-level function that awaits all properly setup. Around that are more function that e.g. create a return continuation and do argument or returnvalue passing. Just use one of these functions as delegate.c does. I *am* using Parrot_run_meth_fromc_args, just like delegate.c does. Single stepping through the debugger, I find that interpreter-ctx.bp is changed by Parrot_Sub_invoke, line 299. The value is not changed after that point, and still retains this new value when control returns to Parrot_get_repr_s_p. - Sam Ruby
Re: Objects, classes, metaclasses, and other things that go bump in the night
Dan Sugalski [EMAIL PROTECTED] writes: At 11:13 AM +0100 12/14/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: subclass - To create a subclass of a class object Is existing and used. Right. I was listing the things we need in the protocol. Some of them we've got, some we don't, and some of the stuff we have we probably need to toss out or redo. add_parent - To add a parent to the class this is invoked on become_parent - Called on the class passed as a parameter to add_parent What is the latter used for? To give the newly added parent class a chance to do some setup in the child class, if there's a need for it. There probably won't be in most cases, but when mixing in classes of different families I think we're going to need this. The chap who's writing Ruby on Rails, a very capable framework reckons that some of these 'meta' method calls that Ruby has in abundance have really made his life a lot easier; they're not the sort of things you need to use very often, but they're fabulously useful when you do.
Re: Classes with several, mostly unused, attributes
David Storrs writes: On Dec 15, 2004, at 6:11 PM, Abhijit Mahabal wrote: S01 says: # Perl 5 code is not strict by default, while Perl 6 code is. But it should be easy to relax with -e or maybe even a bare version number: this would suck. Badly. We should not be optimizing for the compiler's convenience, but for the programmer's. I find strictness _is_ for the programmer's benefit! I've had to work on some scripts which were originally written by people new to Perl who didn't know about strict (or warnings); I found I was making various sorts of errors (some embarrassingly simple) that I don't normally make, because I'm used to them being caught for me automatically. The compiler doesn't care whether you use strict or not -- it'll happily compile what you've written, even if there are logical errors in there! Although I can't prove it, I strongly suspect that the majority of times that someone sits down to do something with Perl, it's a quick one-liner or short script. Who knows? Perl is used in so many different ways there probably isn't a 'typical' user. And note that C-e is one of the things that disables strictness, so your concern about one-liners has been addressed. Strictness just gets in the way for those. A short script tends not to use many variables, so having to type Cmy a few times isn't much of a burden; nor will it be much effort to disable strictness. I think Larry's got this one right: somebody writing a short script who's getting strictness errors can get irritated by this, and therefore looking up how to disable it; whereas the current way round, a new Perl programmer writing a large script can mistype many variable names without it ever occurring to him that something like Cstrict exists and the situation could be avoided. Smylers
Re: Classes with several, mostly unused, attributes
On Thu, Dec 16, 2004 at 10:42:35AM +0100, Michele Dondi wrote:
: On Wed, 15 Dec 2004, Abhijit Mahabal wrote:
:
: #!/usr/bin/perl -e
: $x = 1;
:
: Is this supposed to work? I would tend to consider it counter intuitive...
It occurred to me as I was dropping off to sleep last night that it
can't work on any OS that processes #! for you, since there's no way
to pass an argument to the script that wouldn't be misinterpreted as
the argument to -e. So forget that subidea. -e still sets lax mode,
of course.
: #!/usr/bin/perl
: v6; $x = 1;
:
: Incidentally, and on a totally OT basis, I've noticed that Perl6 is
: supposed to have v-strings. But (current) 'perldoc perldata' warns that
: they won't be there after 5.8: taking all this into account I wonder
: wether this would be a wyse choice. I mean: maybe it hasn't been such a
: good thing to introduce them in the first place, but now that they're
: there, it may be even worse to remove them...
The problem wasn't the syntax so much as the semantics. In Perl 6,
Cv6 creates a string, not an object, so there's no way to overload
its operators to avoid conflicts with other kinds of strings.
In Perl 6 Cv6 makes a version object, not a utf-8 string, and
they compare using numeric operators instead of string operators.
(Perl 5's v-strings had a numeric component that was an old-style
floating point number version (5.00401, for instance), and you could
compare those numerically. Perl 6 will be able to handle those via
MMD without compromising the normal comparison semantics when you
compare two version objects with numeric comparisions.)
The other places v-strings cause ambiguity problems in Perl 5 have
also been addressed, at least insofar as
v6 = mumble
always autoquotes its left side even if it's a keyword, and
%blech{v6}
never autoquotes anymore, so there's never any keyword ambiguity in either
of those places.
Larry
Re: cvs commit: parrot vtable.tbl
Sam Ruby wrote: This doesn't make sense to me. The @ANON pragma avoids the add_method (or store_global) call in the first place. I don't want the method added to a namespace, or stored as a global. I want it stored as a property of a class object. I presumed that ;) Well, due to the described problem (class exists already or not) that's for now a good alternative Python classes are not namespaces. Nor are they global. They are dictionaries. Or, the view is a dictionary-like. The dict is CPython's implementation. I can imagine that Parrot's class namespaces work as well. Take a look at the last test in parrot/languages/python/t/basic/oo_class.t to get an idea of what I am talking about. Well, that just depends on how you implement attribute access, as far as I can see. - Sam Ruby leo From jeff Thu Dec 16 20:41:58 2004 Return-Path: [EMAIL PROTECTED] Delivery-Date: Thu Dec 16 12:41:58 2004 Return-path: [EMAIL PROTECTED] Envelope-to: archive@mail-archive.com Delivery-date: Thu, 16 Dec 2004 12:41:58 -0800 Received: from exprod5mx117.postini.com ([64.18.0.89] helo=psmtp.com) by toko.jab.org with smtp (Exim 3.36 #1 (Debian)) id 1Cf2Ri-0005dv-00 for archive@mail-archive.com; Thu, 16 Dec 2004 12:41:58 -0800 Received: from source ([207.173.176.202]) by exprod5mx117.postini.com ([64.18.4.10]) with SMTP; Thu, 16 Dec 2004 12:44:42 PST Received: from localhost ([127.0.0.1] helo=list.valvesoftware.com) by list.valvesoftware.com with esmtp (Exim 3.35 #1 (Debian)) id 1Cf26f-0003TK-00; Thu, 16 Dec 2004 12:20:13 -0800 Received: from [67.92.168.235] (helo=mta.algx.net) by list.valvesoftware.com with esmtp (Exim 3.35 #1 (Debian)) id 1Cf23W-0003Go-00 for [EMAIL PROTECTED]; Thu, 16 Dec 2004 12:16:58 -0800 Received: from [192.168.100.10] (psr2524875.z47-154-67.customer.algx.net [67.154.47.6]) by chimmx05.algx.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id [EMAIL PROTECTED] for [EMAIL PROTECTED]; Thu, 16 Dec 2004 14:29:25 -0600 (CST) From: Matthew Lewis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Message-id: [EMAIL PROTECTED] MIME-version: 1.0 X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) content-transfer-encoding: 7bit content-type: text/plain; charset=ISO-8859-1; format=flowed Subject: [hlcoders] Player Animations Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: [EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: http://list.valvesoftware.com/mailman/listinfo/hlcoders, mailto:[EMAIL PROTECTED] List-Id: Discussion of Half-Life Programming hlcoders.list.valvesoftware.com List-Unsubscribe: http://list.valvesoftware.com/mailman/listinfo/hlcoders, mailto:[EMAIL PROTECTED] List-Archive: http://list.valvesoftware.com/mailman/private/hlcoders/ X-Original-Date: Thu, 16 Dec 2004 14:29:40 -0600 Date: Thu, 16 Dec 2004 14:29:40 -0600 X-pstn-levels: (S:81.57473/99.9 R:95.9108 P:95.9108 M:94.8624 C:98.9754 ) X-pstn-settings: 1 (0.1500:0.1500) gt3 gt2 gt1 r p m c X-pstn-addresses: from [EMAIL PROTECTED] [294/10] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on toko.jab.org X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=4.0 tests=BAYES_00 autolearn=ham version=2.64 Well I tried the suggestions given by the Wavelength site, but as it turns out, I had already made most of the recommended changes already, except for blocking the rendering of the viewmodel in third person mode. After fighting with the problem some more, I finally got the the upper body to render the correct animation, but despite my best efforts, the lower body still refuses to accept the ACT_WALK animation. The lower body is stuck in the ragdoll mode and just drags the legs and feet across the floor during movement. I have also tried to brute force an animation sequence onto the model by altering the void CBasePlayerAnimState::ComputeMainSequence() such that it always selects ACT_WALK as the ideal activity and selects run_all as the 'animDesired'. It still refuses to accept the lower body animation. I'm out of ideas. Any thoughts? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders From jeff Thu Dec 16 20:42:06 2004 Return-Path: [EMAIL PROTECTED] Delivery-Date: Thu Dec 16 12:42:06 2004 Return-path: [EMAIL PROTECTED] Envelope-to: archive@mail-archive.com Delivery-date: Thu, 16 Dec 2004 12:42:06 -0800 Received: from exprod5mx124.postini.com ([64.18.0.38] helo=psmtp.com) by toko.jab.org with smtp (Exim 3.36 #1 (Debian)) id 1Cf2Rq-0005e8-00 for archive@mail-archive.com; Thu, 16 Dec 2004 12:42:06 -0800 Received: from source ([209.237.227.199]) by exprod5mx124.postini.com ([64.18.4.10]) with SMTP; Thu, 16 Dec 2004 13:44:51 MST Received: (qmail 56319 invoked by uid 500); 16 Dec 2004
[CVS ci] class autoload
1) There is a new opcode new Px, Sc: new P0, PyInt 2) If the given class doesn't yet exist, Parrot_autoload_class is called which has hardcode mapping for Py = python_group, Tcl = tcl_group. A bit hackish but working ... 3) The pybuiltin.__load__() function is automatically called by the library _init loading hook now. There is one more test in t/dynclases/pybuiltins that has an example. leo
Re: overloaded operator calling conventions
Leopold Toetsch wrote: Luke Palmer [EMAIL PROTECTED] wrote: Leopold Toetsch writes: Why do we have the special notion of current_object in the first place? Why not just pass all in as P5, P6, ...? I agree that this is the way to go. Especially if we have some marker somewhere that tells us that we were called as a method. Does the Perl6 compiler know function signatures at compile time? S06 states: Passing two many or too few invocants is a fatal error. For a runtime check we'd need additionally the MMD object count. A few observations, first from an Parrot Internal perspective... in general, the code for the opcodes tend to do things like the following: $1-vtable-get_string(interpreter, $1) Note that the object tends to be repeated as the first argument. It often the case that the first argument matches the object on which the dispatch is based, but it is not necessarily so. In particular, these two values will be different whenever the implementation of a method wants to invoke the equivalent of SUPER(args). As to compile time/runtime checks Python will need complete function signature (not just the number, but the actual names of each of the paramters) at runtime. At the moment, I'm storing this as a property. - Sam Ruby
Re: overloaded operator calling conventions
Sam Ruby wrote: A few observations, first from an Parrot Internal perspective... in general, the code for the opcodes tend to do things like the following: $1-vtable-get_string(interpreter, $1) Note that the object tends to be repeated as the first argument. It often the case that the first argument matches the object on which the dispatch is based, but it is not necessarily so. In particular, these two values will be different whenever the implementation of a method wants to invoke the equivalent of SUPER(args). Not quite. That'll be class_self.__super(args) so again the invocant is the first argument after interpreter. leo
Re: cvs commit: parrot/ops pmc.ops
Sam Ruby wrote:
Leopold Toetsch wrote:
+inline op get_repr(out STR, in PMC) {
+STRING *s = $2-vtable-get_repr(interpreter, $2);
+$1 = s;
goto NEXT();
}
Strange. Stranger. Strangest. Did the test fail with JIT/i386 only?
I didn't mean to commit the inline portion of the change... that
didn't make a difference.
op or inline has no effect
I've never investigated how to select another core...
$ parrot --help
specifically -j -S -C -g
The symptoms I see are that get_repr returns the correct string, but the
appropriate REG_STR does not get updated.
Then there is a problem elsewhere. You can inspect interpreter registers
too:
gdb p *interpreter-ctx.bp
or with the hints in docs/jit.pod or docs/debug.pod (after loading the
stabs file) you can even:
gdb p *S7 # print contents of Parrot REG_STR(7)
leo
Re: [CVS ci] class autoload
Leopold Toetsch wrote: 1) There is a new opcode new Px, Sc: new P0, PyInt 2) If the given class doesn't yet exist, Parrot_autoload_class is called which has hardcode mapping for Py = python_group, Tcl = tcl_group. A bit hackish but working ... Perhaps longer term, a change to the pbc format may be in order... the idea would be for each binary to have a list of dependencies which need to be loaded previously. Developers could declare such a dependency with a IMCC macro, something like this: .lib python_group This would enable JITs to convert the above new opcode into the equivalent new Px, Ic variety in many cases. 3) The pybuiltin.__load__() function is automatically called by the library _init loading hook now. There is one more test in t/dynclases/pybuiltins that has an example. Cool, thanks! - Sam Ruby
Re: overloaded operator calling conventions
Sam Ruby wrote: Leopold Toetsch wrote: class_self.__super(args) so again the invocant is the first argument after interpreter. Believe it or not, I think we are agreeing. *g* To invoke a method on an object using Parrot Calling Conventions, P2 needs to be the object used for dispatch purposes, and P5 needs to be the actual object. In many cases, they will be the same, but in some cases they will differ. Yep. Another good reason to pass the object as P5 (too). This isn't obvious from PDD03, but a simple clarification would take care of that. I'm still waiting for Dan's decision. - Sam Ruby leo
Re: [CVS ci] class autoload
Sam Ruby wrote: Developers could declare such a dependency with a IMCC macro, something like this: .lib python_group That could be .class_mapping Py, python_group OTOH when the classes are built in dynclasses, we can as well hard-code the entries. We'll see. This would enable JITs to convert the above new opcode into the equivalent new Px, Ic variety in many cases. That code is already written ;) Well, the real JIT (Just in time) system in Parrot is predereferencing and used by the switch and CGP run cores. These cores are replacing (after an initial lookup) the opcode already. I'll check it in tomorrow. JIT will eventually call one of these cores and have the same benefit. Cool, thanks! Welcome. - Sam Ruby leo
Re: cvs commit: parrot vtable.tbl
Leopold Toetsch wrote: Sam Ruby wrote: Leopold Toetsch wrote: cvsuser 04/12/15 02:36:29 Modified:.vtable.tbl Log: stub in object vtables [snip] +void add_parent(PMC* parent) +void become_parent(PMC* class) +INTVAL class_type() +void add_method(STRING* method) +void remove_method(STRING* method) +STRING* namespace_name() +PMC* new_singleton() +PMC* get_anonymous_subclass() Cool. Are there plans for opcodes? I could make use of add_parent and add_method... add_parent has already an opcode Caddparent. add_method should probably get one, yes. But add_method is a bit more complicated. It's called automatically during bytecode loading, *if* the class is already existing. E.g. .namespace [Integer] .sub hex method but the problem is code like this: newclass cl, Foo ... .namespace [Foo] .sub foo method now the class isn't constructed, when the bytecode is loaded and the old Parrot_store_global is used. But if you load the method code with load_bytecode again add_method is called. My need is to be able to call add_method for methods defined as @ANON. From the perspective of Parrot, namespaces should be viewed a perfectly reasonable mechanism for implementing classes, and there perhaps should even be special support for enabling classes to be defined that way... but: there should be no built in assumptions that all classes are defined in this way. - Sam Ruby
Context, wrappers, and rules (was: cvs commit: parrot/ops pmc.ops)
Leopold Toetsch wrote: Sam Ruby wrote: Before this line is executed, (gdb) p interpreter-ctx.bp $1 = (struct parrot_regs_t *) 0x40b6bd88 After the above line is executed: (gdb) p interpreter-ctx.bp $2 = (struct parrot_regs_t *) 0x40b6bae8 Then is obviously your implementation of get_repr broken. Two questions come to mind: 1) Should this call to run_meth change the context? Yes because a subroutine is run. But returning from it via a (return-) continuation restores the context and the register frame pointer or it ought to. ... In this case, repr happens to be a Closure based on some assumptions I made early on in this process that I need to revisit. Arguably, this is a bug, but in the general case, can one always assume that the context does not change? Only function calls / returns may change the context. A simple opcode like get_repr isn't allowed to do that. The question isn't about what opcodes are or are not allowed to do. The question is what VTABLE_* functions are or are not allowed to do. Can VTABLE_invoke change the context? How about VTABLE_get_string? If you look at the current delegate PMC, every VTABLE call is translated to a call of a method. Are such methods allowed to change the context? What are the rules? Note: if the context is not supposed to change as a result of runops, perhaps an internal exception should be thrown. We can't check that on each opcode. That just must not happen :) I mustn't have been clear. If things invoked by runops are not allowed to change the context, then runops should throw an internal exception if the context changes. On the other hand, if runops can't change the context, then why is runops_args careful to capture the context prior to calling runops? Again, what are the rules? But before you implement more and more methods I'd rather have inheritance and method calling conventions fixed. Parrot should call the approriate method if it exists in the class namespace (if find_method did return something). How I chose to invest my time is up to me. If all that comes of it is the few minor contributions I have made to the core of Parrot... then I will be OK with that. In most cases, I think I could adapt to a change in a matter of minutes. You've seen me clone classes like BigInt and Complex wholesale, only to gut them back once I had some partial ability to inherit MMD methods. In the worst case, adapting to a major change would be a matter of days. Again, my time to burn. Also, if you note, I am only writing the minimum necessary to pass the given set of tests. That way there is less for me to change when things change. The reason why I am proceeding this way is that I found the previous discussions on topics like object, classes, and metaclasses to be frustrating. I want the next round to be based on specifics. In particular, I don't want to have to respond to statements like It doesn't buy us anything, if we force all languages to create wrappers.. I want to be able to point at a specific wrapper and ask the question: how could it be done better? Parrot_PyClass_get_repr is one such wrapper. How could it be done better? If you make a specific suggestion there, I'll either adopt it or produce a test case as a counter example. - Sam Ruby
RE: [ANNOUNCE] Test::Simple/More/Builder 0.54 (problem with signa ture?)
Perhaps you've got a damaged default MANIFEST.SKIP. Check what
perldoc -m ExtUtils::MANIFEST.SKIP looks like. It should
look like this.
http://search.cpan.org/src/MSCHWERN/ExtUtils-MakeMaker-6.24/lib/ExtUtils/MAN
IFEST.SKIP
Not like this.
http://search.cpan.org/src/MSCHWERN/ExtUtils-MakeMaker-6.24/MANIFEST.SKIP
The files you originally linked to don't contain a MANIFEST.SKIP at all so
that must be the problem.
===
Not in MANIFEST: pmfiles.dat
That's not something produced by MakeMaker or Test::Simple.
Well, it seems to be something produced by the build process. Ill do my best
to track it down. Oddly I couldnt find any evidence of this file after the
make test produced this report.
t\00signature.WARNING: This key is not certified with a
trusted signature!
Primary key fingerprint: B484 04B8 E9D5 93A2 5CA8 F1AA 4F82 E2DC 2C3F
3F34
== SKIPPED CHECKING 'Makefile'! (run Makefile.PL to ensure its
integrity) ===
Not in MANIFEST: foo
Grr. Mandatory file locking strikes again. is_fh.t didn't close a temp
file before unlinking it.
Just so you know this isnt actually the fault of mandatory locking. Its the
fault of Perl defaulting to open all files without the sharing permission
FILE_SHARE_DELETE. For the type of thing you are doing it would be better to
use Win32API::File;
$hTemp= createFile( foo, wn, ,
{ Attributes=hst, Flags=FILE_FLAG_DELETE_ON_CLOSE() } )
or die Can't create temporary file, temp.$$: $^E\n;
And the the OS would wipe the temp file as soon as the creating process
terminated regardless of cause. Of course I dont think that this module is
considered core so you cant expect it to be there. (Which IMO is a really
good example of why certain Win32 modules should be moved into core.)
Cheers,
Yves
--
Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
Please hold while reality is adjusted to match my ideal world.
r- njt
Re: [ANNOUNCE] Test::Simple/More/Builder 0.54 (problem with signa ture?)
On Thu, Dec 16, 2004 at 12:59:00PM -, Orton, Yves wrote: Ah, sorry. I didnt understand. Im just curious if i alter this file this will affect all make dist commands? Only if that module doesn't have its own MANIFEST.SKIP. Is there any chance the default could have .bak added in future releases? I've considered that many times. I'll slap it in. Also will the fact that some of the patterns depend on *NIX style paths be an issue on Win32? Im guessing not, but i think its worth asking. No, MANIFEST files are always Unixy. And no the version on my machine doesnt look (exactly) like either one you linked to: Ok, that's good enough. If you throw in pmfiles.dat$ that should solve your Module::Signature problems. The last few releases of Perl shipped with the wrong MANIFEST.SKIP file. That's what I was looking for. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Home of da bomb
