Dan Sugalski wrote:
Tomorrow (tuesday) I'm heading out to Seabastapol CA for a week-long
perl 6 design get-together thingie.
When you are on it, please - again - have a look at our current string
behaviour. Keywords are: string_set, string header reusing, 50 % more
performance with life cy
Folks,
I made a bet with Guido van Rossum that Parrot'd be faster at
executing a pure python benchmark of some sort (to be determined)
with the challenge details announced at OSCON 2003 and the results
tried at OSCON 2004. If I lose, I owe Guido $10 and a round of beer
for the zope/pythonlabs
Dan Sugalski wrote:
> At 8:39 PM +0100 2/3/03, Jerome Quelin wrote:
> >Dan Sugalski wrote:
> >> *) Property: A named thing attached to an object. Properties are
> >> global to the object and public--i.e. there's no implicit hiding,
> >> namespaces, or whatnot. There can be only one foo property
On Mon, Feb 03, 2003 at 12:15:32PM -0500, Dan Sugalski wrote:
> *) Method: Some sort of action that an object can do. Methods are
> global and public--only one foo method for an object. Methods may be
> inherited from parent classes, or redefined in a particular class.
> Redefined methods hide
At 8:48 PM +0100 2/3/03, Jerome Quelin wrote:
Dan Sugalski wrote:
At 8:39 PM +0100 2/3/03, Jerome Quelin wrote:
>Dan Sugalski wrote:
>> *) Property: A named thing attached to an object. Properties are
>> global to the object and public--i.e. there's no implicit hiding,
>> namespaces, or w
Dan Sugalski wrote:
At 10:07 AM +0100 1/30/03, Leopold Toetsch wrote:
Changing the addressing scheme to opcode offsets relative to code
The big problem with this is you're increasing non-local call
performance for normal running. I don't think this is a good idea--while
you'll save maybe 50
At 8:39 PM +0100 2/3/03, Jerome Quelin wrote:
Dan Sugalski wrote:
*) Property: A named thing attached to an object. Properties are
global to the object and public--i.e. there's no implicit hiding,
namespaces, or whatnot. There can be only one foo property on an
object, for example
[...]
Th
Dan Sugalski wrote:
> *) Property: A named thing attached to an object. Properties are
> global to the object and public--i.e. there's no implicit hiding,
> namespaces, or whatnot. There can be only one foo property on an
> object, for example
[...]
> The interpreter must handle class hierarchy stu
At 6:25 PM + 2/3/03, Andy Wardley wrote:
Dan Sugalski wrote much sense, including these gems:
*) Method: Some sort of action that an object can do. Methods are
global and public--only one foo method for an object. Methods may be
inherited from parent classes, or redefined in a particular c
> -Original Message-
> From: Andy Wardley [mailto:[EMAIL PROTECTED]]On Behalf Of Andy Wardley
>
> Dan Sugalski wrote much sense, including these gems:
> > *) Method: Some sort of action that an object can do. Methods are
> > global and public--only one foo method for an object. Methods ma
Dan Sugalski wrote much sense, including these gems:
> *) Method: Some sort of action that an object can do. Methods are
> global and public--only one foo method for an object. Methods may be
> inherited from parent classes, or redefined in a particular class.
> Redefined methods hide parent cla
Okay, I figure it's time for a quick status report from me, since
I've been missing from the list of late and it's been showing. (Leo's
been doing grand things but at some point he's going to run out of
old mistakes of mine and'll need new ones to work with :)
Tomorrow (tuesday) I'm heading out
Okay, just to get some stuff defined and the problem space sorted
before I try and work on it:
Definitions:
*) Object: An opaque thingie with properties, attributes, and methods
*) Property: A named thing attached to an object. Properties are
global to the object and public--i.e.
At 10:07 AM +0100 1/30/03, Leopold Toetsch wrote:
Changing the addressing scheme to opcode offsets relative to code
start would simplify all kinds of (non local) control flow changes. As
real world programs mostly consists of such subroutine calls, these
would be simplified a lot (and would then n
The last 3 commits made native compiled PBCs (via pbc2c.pl) run a little
bit better:
Failed TestStat Wstat Total Fail Failed List of Failed
---
t/op/hacks.t 1 256 31 33.33% 1
t/op/integer.t4 10
James --
I'm open to other ideas. I've toyed with learning DAML and RDF for some
ontology stuff I'm interested in, but so far I haven't had the mental
"click"
that would make me feel comfortable working with them. I do have a good
comfort level with XML in general.
I am pondering the sorts of tr
--- [EMAIL PROTECTED] wrote:
> I just committed some changes to the Jako compiler that add a '-x'
> switch. Using jakoc -x will cause the compiler to emit the parse tree
> as XML (via SAX events sent to XML::Handler::YAWriter).
>
Sounds interesting. I have to look into this,
i have dropped xml i
I just committed some changes to the Jako compiler that add a '-x'
switch. Using jakoc -x will cause the compiler to emit the parse tree
as XML (via SAX events sent to XML::Handler::YAWriter).
It still has some worts, but it didn't die when I turned it loose on the
Jako examples.
There are a few
# New Ticket Created by Joe Yates
# Please include the string: [perl #20666]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=20666 >
Line numbers reported by Assemble.pl are array indices AFTER the removal of
macros.
This
19 matches
Mail list logo
