Re: cvs commit: parrot vtable.tbl

2004-12-17 Thread Leopold Toetsch 
Sam Ruby wrote:
Are namespaces subject to garbage collection?  Classes may be created on 
the fly in Python, and disapear just as quickly.
In Python as well as in Perl. We have to deal with that anyway. Perl6 
has the notion of lexically scoped multimethods. Operator overloading 
only for one specific scope.

In the example, two objects with the same class have different 
implementations of a given method.
Fine. The find_method call has to consult the properties of the object too.
Furthermore, every assignment to any property of any instance has the 
potential of invalidating whatever caches you may have.
The assignment of a Sub PMC, yes. But if your implementation of 
find_method is able to locate a method now, you know already where and 
in which order you are searching. And if the implementation can overload 
e.g. a add method, you know where you have to call add_method to 
achieve that effect.

I don't see a problem here. Worst case is an uncached find_method call 
as you are doing now anyway in e.g. PyClass.

- Sam Ruby
leo

Re: cvs commit: parrot vtable.tbl

2004-12-16 Thread Leopold Toetsch 
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 vtable.tbl

2004-12-16 Thread Sam Ruby 
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: cvs commit: parrot vtable.tbl

2004-12-16 Thread Leopold Toetsch 
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

Re: cvs commit: parrot vtable.tbl

2004-12-16 Thread Sam Ruby 
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