Re: benchmarking - it's now all(-1,0,1,5,6)% faster
On 01/12/2003 4:41 AM, Leopold Toetsch wrote: There might be additional problems with glibc, but the deviations in JIT code timings are only caused by moving the loop by on byte (crossing a 8 byte boundary). Do we have enough metadata at JIT-time to pad locations that get jmp'd to to an 8-byte boundry in memory? BTW, I legitimatly don't know. I have a sinking suspicition that the only way to know if somthing is a jump target is to scan through the entire bytecode and check if it gets used as one. (For that matter, you can jump to the value of an Ix reg, which makes even that infesable, no?) (BTW, I removed p5p from the CC list, since I don't think this makes sense for non-JIT targets... and since p5 doesn't JIT...) -=- James Mastros
Re: Array Questions
Michael Lazzaro [EMAIL PROTECTED] writes:
On Thursday, January 9, 2003, at 03:24 AM, Damian Conway wrote:
Michael Lazzaro asked:
class FileBasedHash is Hash { ...stuff... };
my %data is FileBasedHash('/tmp/foo.txt');
Yes.
my $path = '/tmp/foo.txt';
my %data is FileBasedHash($path);
Indeed
Great -- then I have only one more question, I think. In the words of
a certain cartoon character, what's *this* button do?
my $b is $a;
Compile time error. 'is' is a compile time property, scalar values
aren't.
Re: Array Questions
Damian Conway [EMAIL PROTECTED] writes: Michael Lazzaro wrote: Which, in turn, implies that the lines: my Foo $a; # (1) my $a is Foo; # (2) my Foo $a is Foo; # (3) are all subtly different. (2) and (3) (auto)instantiate a Foo, but (1) does not. Correct. Though the instantiated Foo is the implementation object and not directly accessible (just as the implementation object in a Perl 5 tie isn't). BTW, Cmy Foo $a is Foo is just sick! (i.e. I'll *definitely* be using it ;-) Surely anyone who does C my Array @foo , or C my Scalar $foo will be using it, albeit indirectly.
Re: Disappearing code
Damian Conway [EMAIL PROTECTED] writes:
John Siracusa asked:
Has there been any discussion of how to create code in Perl 6 that's there
under some conditions, but not there under others? I'm thinking of the
spiritual equivalent of #ifdef, only Perlish.
In Perl 5, there were many attempts to use such a feature for
debugging and
assertions. What everyone wanted to do was write code like this:
debug(Doing foo with $bar and $baz);
foo($bar, $baz);
And then have the entire call to debug() just plain disappear when
the
program was run with a certain flag, or when a particular constant was set,
or whatever. The closest we got in Perl 5, AFAIK, was stuff this:
use constant DEBUG = 0;
...
debug(Doing foo with $bar and $baz) if DEBUG;
foo($bar, $baz);
But all those if DEBUGs or DEBUG s were a pain. So I'm
wondering what
the solution will be in Perl 6.
Something like this:
module Debug;
my $debugging = 1;
method import ($debug) { $debguuging = $debug }
sub debug is immediate is exported (@message) {
return $debugging ?? { print $*STDERR: @message; } :: {;}
}
then:
use Debug;
debug(Doing foo with $bar and $baz);
and to deactivate the debug statements:
use Debug 0;
debug(Doing foo with $bar and $baz);
Immediate subroutines are executed as soon as they are parsed (i.e. they're
like named BEGIN blocks).
Returning a closure/block from an immediate sub called in a void context
(as Cdebug is in the example above) causes the immediate sub call to be
replaced -- during compilation! -- by the returned closure/block.
So, one could implement 'assert' in the same package with something
like:
sub assert is immediate is exported
( rx/expr/ expr ; $message = Assertion failed )
{
return $debugging ?? { expr() || die $message } :: { ; }
}
For bonus points one could have the assertion die if it's called in a
non void context, but I'll leave that as an exercise for the
interested reader.
[CVS ci] imcc 0.0.9.9
With this version of imcc, some typo fixes in tests and the assemble.pl
below all parrot tests except t/op/interp_1 succeed, when assembled by imcc.
The failing test is probably due to the global interpreter var, that
imcc has.
Nice to would have:
- some more environment vars in Test.pm: like PARROT_ASSEMBLER or
ASSEMBLER_IS_IMCC, which immediately could run the pasm file.
- still: a preprocesoor for imcc ;-)
leo
(the original assemble.pl was renamed to oassemble.pl and get used as
preprocessor only - This is almost the same as new_assemble.pl by
Juergen Boemmels s. #18747)
#!/usr/bin/perl -w
use FindBin;
use strict;
my $files = [];
my $args = {};
while (my $arg = shift @ARGV) {
if($arg =~ /^-(c|-checksyntax)$/) { $args-{-c} = 1; }
elsif($arg =~ /^-E$/) { $args-{-E} = 1; }
elsif($arg =~ /^-(o|-output)$/) { $args-{-o} = shift @ARGV; }
elsif($arg =~ /^-(h|-help)$/) { Usage(); exit 0; }
elsif($arg =~ /^-./) { Fail(Invalid option '$arg'\n); }
else { push @$files,$arg; }
}
Fail(No files to process.\n) unless(@$files);
Fail(File '$_' does not exist.\n) for grep { not (-e or /^-$/) } @$files;
my $output = '-o -';
$output = -o $args-{-o} if exists $args-{-o};
exec perl oassemble.pl -E @$files | $FindBin::Bin/languages/imcc/imcc
-c $output -a -
Re: Problems making the recent cvs snapshot under cygwin.
At 12:39 AM -0500 1/14/03, Joseph F. Ryan wrote: I'm having problems making off of the recent cvs snapshot. When running Configure, I get the errors/output below. Could anyone suggest a fix that I could try? I am running windows 2kpro, with gcc under cygwin as my compiler. Are you using ActiveState's perl, or the cygwin perl? I think we may be mis-identifying as MSWindows rather than cygwin, and so using the wrong hint set. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Objects, finally (try 1)
Dan,
Below are some questions about this ...
-Original Message-
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
[snip]
Objects, as far as I see it, have the following properties:
1) They have runtime-assignable properties
Terminology question: what is the difference between a property and an
attribute? Perhaps the answer could go in the glossary.
[snip]
#3 Since each class has a PMC type, we just need to associate the PMC
type with the data a class needs. Also pretty much no big deal, and
something we already have facilities for.
So, while there may be exceptions, generally all classes will be instances
of the Class PMC, true?
[snip]
The call/jmpmeth opcodes either make a returnable or non-returnable
method call. They fetch the function pointer from the object PMC and
either dispatch to it or save the current state and jsr to it. Note
that you can't jmpmeth into a C-implemented method, so no tail
calling into those without some wrapper opcodes. The registers still
need to be set up appropriately, just like with a regular sub call.
So the call opcode takes a method name or offset and calls a vtable method
to find the method and then invokes it?
The find_method vtable entry should die, and be replaced with a plain
method entry. This should return either the address of the start of
the method's bytecode, or NULL. The NULL return is for those cases
where the method actually executed via native code, and thus doesn't
have to go anywhere. If an address is returned it's expected that the
engine will immediately dispatch to that spot, obeying parrot's
calling conventions.
Not sure what this means, does it mean that there is a method named
find_method accessed something like
call Px, Py, find_method
which I can then call to find the method or am I off?
[snip]
The structures:
*) Attr PMCs have an array off their data pointer.
*) Classes are variants of Attr PMCs. They have the following
guaranteed attributes in slots:
0) Hash with class name to attribute offset
I am not sure what this means, Don't we already have the class and it's
attributes if we are accessing these slots?
1) Hash with attribute name to attribute offset (relative to the
offset found from the hash in slot 0, generally known at
compile time, but introspection is nice)
2) Integer number of attributes this class has
3) Notification array
Do we store ptrs to parent classes in one of these slots? Also Can I access
slots like:
set Px, Py[1]# store the name to offset hash in Px
[snip]
So to sum up we need the following pmc's:
pmclass Ref {
data is a pointer to an object
}
pmclass Attr {
data is an array of attributes
}
pmclass Class extends Attr {
}
pmclass Object {
this was not explained, but I guess it at least
has a reference to a Class and field data ???
}
Does that cover it?
--
Jonathan Sillito
Re: Problems making the recent cvs snapshot under cygwin.
--- Joseph F. Ryan [EMAIL PROTECTED] wrote: I'm having problems making off of the recent cvs snapshot. When running Configure, I get the errors/output below. Could anyone suggest a fix that I could try? I am running windows 2kpro, with gcc under cygwin as my compiler. Thanks, Joseph F. Ryan [EMAIL PROTECTED] Output of : Checking MANIFEST...done. Setting up Configure's data structures...done. Checking for --miniparrot...done. Loading platform and local hints files...done. Enabling debugging...(none requested) done. Determining what C compiler and linker to use...done. Determining what types Parrot should use...done. Determining what opcode files should be compiled in...done. Setting up experimental systems...done. Determining what pmc files should be compiled in...done. Tweaking ccflags...done. Determining your minimum pointer alignment... C compiler failed (see test.cco) at lib/Parrot/Configure/Step.pm line 145. Contents of test.cco: 'cl' is not recognized as an internal or external command, operable program or batch file. Line 145 (newline added): system($cc $ccflags -I./include -c test.c test.cco $redir_err) and die C compiler failed (see test.cco); The value of $cc $ccflags -I./include -c test.c test.cco $redir_err at the moment of failure: cl -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -I./include -c test.c test.cco 21 Your perl5 was compiled with VC++. Configure swipes the options from perl5 so if you want to fix this, you'll have to edit Config.pm. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Array Questions
On Tuesday, January 14, 2003, at 02:24 AM, Piers Cawley wrote: Michael Lazzaro [EMAIL PROTECTED] writes: Great -- then I have only one more question, I think. In the words of a certain cartoon character, what's *this* button do? my $b is $a; Compile time error. 'is' is a compile time property, scalar values aren't. That's what I first thought, but... why is that a compiletime error, if the previous example my %data is FileBasedHash($path); is not? Or, to rephrase the question, I would assume that the above allows $path to be resolved runtime, not just compiletime, or its utility seems sadly limited. So if implementor classes can be instantiated at runtime, are they really Cis compile-time properties, or are they 'is' meaning 'isa', and is that runtime-settable? [*1] (Thinking aloud) Perhaps this is an example of why having both is and isa as keywords might be a good idea. Because 'is' implies compiletime, but implementor classes aren't really properties, they're a form of (pseudo?)inheritance. So maybe my %data isa FileBasedHash($path); -or- my $b isa $a; Might be clearer(???) than reusing Cis for this purpose. Dunno. [*2] MikeL [*1] It almost seems like my %data but FileBasedHash($path); would be more appropriate, but I think we can agree that's *horrid*. [*2] This ties strongly into the whole issue of allowing some form of prototype-based (classless) inheritance. I try to avoid it, but damn it, *it keeps pulling me back in*! Right now I just need to know what 'is' is, for the sake of arrays and hashes. :-/
Re: Array Questions
At 9:23 AM -0800 1/14/03, Michael Lazzaro wrote: On Tuesday, January 14, 2003, at 02:24 AM, Piers Cawley wrote: Michael Lazzaro [EMAIL PROTECTED] writes: Great -- then I have only one more question, I think. In the words of a certain cartoon character, what's *this* button do? my $b is $a; Compile time error. 'is' is a compile time property, scalar values aren't. That's what I first thought, but... why is that a compiletime error, if the previous example my %data is FileBasedHash($path); is not? I'm not sure either of them *has* to be an error, as the compile-time properties that is imparts need to be evalutated and applied at runtime. The my $foo is $bar would mean that we couldn't do any compile-time type checking, but that's not a huge deal as presumably you wouldn't *want* any type checing in that case. Whether it is a good idea or not from a maintenance/programmer-brain standpoint is a separate issue. I think I'd rather dislike having to maintain code that did it, but I can see a few good reasons to do it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: This week's Perl Summary
--- [EMAIL PROTECTED] wrote:
L2R/R2L syntax
Argh! No! It's back and this time it means business. The dreaded
left-right versus right-left thing came back, and this time it was
Damian applying the electrodes to the corpse. Of course, it being
Damian
he was instantly forgiven as he came up with the very cool, very low
precedence ~ and ~ operators, allowing you to write
@out = @a ~ grep {...} ~ map {...} ~ sort;
Which is, to these eyes at least, lovely. See Damian's post for the
full
details. The general response to this was definitely on the 'lovely'
side of the balance, though one detractor did induce a sense of humour
failure on Damian's part.
If you and Damian think you'll get me to leave p6l this easily, forget it.
I've seen far worse flames than that.
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: This week's Perl Summary
Mr. Nobody wrote: If you and Damian think you'll get me to leave p6l this easily, forget it. I've seen far worse flames than that. While you were the person that Damian lost his sense of humor at, Piers didn't identify you in this part of the summary. So I don't think Piers was trying to get you to leave.
Re: This week's Perl Summary
Buddha Buck [EMAIL PROTECTED] writes: Mr. Nobody wrote: If you and Damian think you'll get me to leave p6l this easily, forget it. I've seen far worse flames than that. While you were the person that Damian lost his sense of humor at, Piers didn't identify you in this part of the summary. So I don't think Piers was trying to get you to leave. Exactly. -- Piers
RE: Objects, finally (try 1)
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 9:51 AM -0800 1/14/03, Jonathan Sillito wrote:
Dan,
Below are some questions about this ...
And now some answers. :)
-Original Message-
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
[snip]
Objects, as far as I see it, have the following properties:
1) They have runtime-assignable properties
Terminology question: what is the difference between a property and an
attribute? Perhaps the answer could go in the glossary.
A property is a runtime assignable name/value pair that you stick on
a variable or value. An attribute is a named variable that all
objects of a particular class have.
Properties can come and go at runtime, but attributes are fixed. (I
think you could also consider attributes instance variables, but
I'm a bit OO fuzzy so I'm not sure that's entirely right)
#3 Since each class has a PMC type, we just need to associate the PMC
type with the data a class needs. Also pretty much no big deal, and
something we already have facilities for.
So, while there may be exceptions, generally all classes will be instances
of the Class PMC, true?
Generally, yes.
The call/jmpmeth opcodes either make a returnable or non-returnable
method call. They fetch the function pointer from the object PMC and
either dispatch to it or save the current state and jsr to it. Note
that you can't jmpmeth into a C-implemented method, so no tail
calling into those without some wrapper opcodes. The registers still
need to be set up appropriately, just like with a regular sub call.
So the call opcode takes a method name or offset and calls a vtable method
to find the method and then invokes it?
Yep.
The find_method vtable entry should die, and be replaced with a plain
method entry. This should return either the address of the start of
the method's bytecode, or NULL. The NULL return is for those cases
where the method actually executed via native code, and thus doesn't
have to go anywhere. If an address is returned it's expected that the
engine will immediately dispatch to that spot, obeying parrot's
calling conventions.
Not sure what this means, does it mean that there is a method named
find_method accessed something like
call Px, Py, find_method
which I can then call to find the method or am I off?
You're off. It'll be something like:
callmethod Px, method_name
or
jmpmethod Px, method_name
The structures:
*) Attr PMCs have an array off their data pointer.
*) Classes are variants of Attr PMCs. They have the following
guaranteed attributes in slots:
0) Hash with class name to attribute offset
I am not sure what this means, Don't we already have the class and it's
attributes if we are accessing these slots?
Well...
The problem is finding which slot to access, a problem that's
compounded by multiple inheritance.
Let's say, for example, that you have a class A, which inherits from
B and C. Let's also say that each class has 10 attributes, and you
have a fixed-width mail reading font. The inheritance diagram then
looks like:
C B
\ /
|
A
Since the attributes are an array, it looks like:
CCBBAA
012345678901234567890123456789
We make a method call and it gets resolved to be one we inherited
from B. Now, how does B know which slots in the object holds its
attributes? In a single-inheritance case, it could assume that since
it has no parents it can start at slot 0, but that doesn't work
here--C is first. So what B needs to do is query the object to find
out where the attributes for class B start in the attribute array,
and to do that it looks in the hash stored in the object's class
attributes that maps class names to starting offsets. From there B
can figure out what slot to look in, since class attributes are
contiguous, and thus there only needs to be a single lookup.
Single inheritance makes all this resolvable at compile time, which
would be so much nicer. Alas, no joy for us there.
1) Hash with attribute name to attribute offset (relative to the
offset found from the hash in slot 0, generally known at
compile time, but introspection is nice)
2) Integer number of attributes this class has
3) Notification array
Do we store ptrs to parent classes in one of these slots? Also Can I
access
slots like:
set Px, Py[1]# store the name to offset hash in Px
No the parent's gotten to via the vtable, and yes you can.
So to sum up we need the following pmc's:
pmclass Ref {
data is a pointer to an object
}
pmclass Attr {
data is an array of attributes
}
pmclass Class extends Attr {
}
pmclass Object {
this was not explained, but I guess it at least
has a reference to a Class and
RE: Objects, finally (try 1)
At 11:44 AM -0800 1/14/03, Mr. Nobody wrote: Seems pretty reasonable, but don't you mean PerlRef, PerlAttr, PerlClass, PerlObject? Nope. There's nothing particularly perlish about them, and if we're going to have a common base set of object functionality, they'll probably be named ParrotRef/Attr/Class/Object. They should suffice for perl, python, and ruby (at the very least) unless I've missed something. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #20315] [PATCH] eval
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #20315]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=20315
Attached is a first try towards eval.
- interpreter has a new data member Parrot_compreg_hash
- parrot registers the PASM1 type i.e. what PDB_eval can parse
- the new Bcompile opcode (ab)uses nci to build a function for calling
PDB_eval
- nci is extended (jit/i386 only), to understand an 'I' param as interpreter
- the string is evaled immediately, we don't have multiple byte code
segments yet
No registers, which nci uses, are preserved, no error checking and so
on, but works ;-)
Some questions arise here:
- Should the Bcompreg opcode also have a form with a label to build
PASM compilers, ook?
- is using the NCI interface ok for evals purpose?
- how should a byte code segment (PMC) look like?
Comment welcome
leo
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/48556/37739/ade5a5/eval.patch
--- parrot/classes/csub.pmc Fri Jan 10 18:05:02 2003
+++ parrot-leo/classes/csub.pmc Tue Jan 14 19:06:24 2003
@@ -49,7 +49,7 @@
return SELF-cache.struct_val != NULL;
}
-void * invoke (void * next) {
+void* invoke (void * next) {
Parrot_csub_t func = (Parrot_csub_t)SELF-cache.struct_val;
func(INTERP, SELF);
return next;
--- parrot/core.ops Tue Jan 14 09:09:55 2003
+++ parrot-leo/core.ops Tue Jan 14 19:25:19 2003
@@ -4485,6 +4485,10 @@
Call the subroutine in P0, as described in PDD03.
+=item Bcompile(out PMC, in STR, in STR)
+
+Compile source code $2 of a registered source type $3 into PMC $1.
+
=cut
inline op loadext(in STR, in STR) {
@@ -4547,6 +4551,19 @@
goto ADDRESS(dest);
}
+
+inline op compile(OUT PMC, in STR, in STR) {
+ opcode_t *dest;
+ PMC *key = key_new_string(interpreter, $3);
+ PMC *func = interpreter-Parrot_compreg_hash-vtable-get_pmc_keyed(
+interpreter, interpreter-Parrot_compreg_hash, key);
+ /* XXX undef */
+ interpreter-ctx.string_reg.registers[5] = $2; /* XXX */
+ dest = (opcode_t *)func-vtable-invoke(interpreter, func, expr NEXT());
+ /* XXX retval */
+ goto ADDRESS(dest);
+}
+
=item Bfind_method(out PMC, in PMC, in STR)
--- parrot/dod.cTue Jan 14 09:09:55 2003
+++ parrot-leo/dod.cTue Jan 14 18:51:15 2003
@@ -104,6 +104,8 @@
/* mark it as used */
pobject_lives(interpreter, (PObj *)current);
+if (interpreter-Parrot_compreg_hash)
+pobject_lives(interpreter, (PObj *)interpreter-Parrot_compreg_hash);
/* Now, go run through the PMC registers and mark them as live */
/* First mark the current set. */
for (i = 0; i NUM_REGISTERS; i++) {
--- parrot/include/parrot/interpreter.h Sat Jan 4 12:35:22 2003
+++ parrot-leo/include/parrot/interpreter.h Tue Jan 14 18:13:08 2003
@@ -169,6 +169,7 @@
INTVAL world_inited;/* Parrot_init is done */
PMC *mark_ptr; /* last PMC marked used in DOD runs */
PMC *Parrot_base_classname_hash;/* hash containing name-base_type */
+PMC *Parrot_compreg_hash; /* hash containing assembler/compilers */
} Interp;
#define PCONST(i) PF_CONST(interpreter-code, (i))
@@ -189,6 +190,7 @@
VAR_SCOPE opcode_t *(*run_native)(struct Parrot_Interp * interpreter,
opcode_t * cur_opcode,
opcode_t * start_code);
+void Parrot_compreg(Parrot_Interp interpreter, STRING *type, PMC *func);
#endif /* Parrot core */
--- parrot/interpreter.cSat Jan 11 09:39:08 2003
+++ parrot-leo/interpreter.cTue Jan 14 19:21:00 2003
@@ -21,11 +21,13 @@
#ifdef HAVE_COMPUTED_GOTO
# include parrot/oplib/core_ops_cg.h
#endif
+#include parrot/method_util.h
#define ATEXIT_DESTROY
extern op_lib_t *PARROT_CORE_PREDEREF_OPLIB_INIT(void);
+static void setup_default_compreg(Parrot_Interp interpreter);
/*=for api interpreter runops_generic
* TODO: Not really part of the API, but here's the docs.
@@ -512,6 +514,10 @@
SET_NULL_P(interpreter-prederef_code, void **);
SET_NULL(interpreter-jit_info);
+SET_NULL_P(interpreter-Parrot_compreg_hash, PMC *);
+/* register assembler/compilers */
+setup_default_compreg(interpreter);
+
/* Done. Return and be done with it */
/* Okay, we've finished doing anything that might trigger GC.
@@ -686,6 +692,42 @@
}
return ret;
}
+
+/*=for api interpreter Parrot_compreg
+ * register a parser/compiler function
+ */
+
+void Parrot_compreg(Parrot_Interp interpreter, STRING *type, PMC *func)
+{
+PMC* key, *hash;
+if (!interpreter-Parrot_compreg_hash) {
+hash = interpreter-Parrot_compreg_hash =
+pmc_new_noinit(interpreter, enum_class_PerlHash);
+hash-vtable-init(interpreter, hash);
+}
+key = key_new_string(interpreter, type);
+
This week's Perl Summary
The Perl 6 Summary for the week ending 20030112
... and we're back. Yup, it's summary time again. We'll dive straight in
with perl6-internals (as if you expected anything else).
More thoughts on DOD
Leopold Tötsch posted a test program showing the effects of PMC size and
timing of garbage collection and allocation and suggested ways of
improving the GC system based on the conclusions he drew from its
results. Leo, Dan and Mitchell N Charity discussed this further and
tried a few different approaches to try and improve performance (though
Mitchell did worry about premature optimization). Work in this area is
ongoing.
http://makeashorterlink.com/?Y3EB16513
The Perl 6 Parser
Dan asked about the current state of the Perl 6 parser, wanting to know
what was and wasn't implemented and wondered about adding the Perl 6
tests into the standard parrot test suite. Sean O'Rourke and Joseph F.
Ryan both gave a summaries of where things stood. Joseph also suggested
a few refactorings of the parser to deal with the fluidity of the
current spec (almost all the operators have changed symbols since the
parser was first written for instance).
http://makeashorterlink.com/?I6FB35513
LXR - Source code indexing
Last week I said that Robert Spier had 'started work on getting a
browseable, cross referenced version of the Parrot source up on
perl.org'. What actually happened was that Robert asked Zach Lipton to
do the work. This week Zach delivered the goods which, I must say, look
fabulous.
I'm sure that if someone were to extend LXR so it had a better
understanding of .pasm, .pmc, .ops and other special Parrot source types
then the community would be very grateful indeed. I know I would.
http://makeashorterlink.com/?K10C23513 -- Announcement
http://tinderbox.perl.org/lxr/parrot/source
Thoughts on infant mortality
Piers Cawley offered what he thought might be a new approach to dealing
with the infant mortality problem which got efficiently shot down by Leo
Tötsch. Which led to further discussion of possible answers, and it
looks like Leo's proposed solution involving a small amount of code
reordering and early anchoring will be the one that's tried next. All
being well it won't require walking the C stack and hardware register
set, which can only be a good thing.
Later on, Leo asked if it'd be okay to check in his work so far on
redoing the GC because he was up to 15 affected files and was starting
to worry about integration hell. Steve Fink wasn't sure about one of his
changes, so Leo checked everything else in.
http://makeashorterlink.com/?K41C21513
http://makeashorterlink.com/?S62C23513
Objects, finally (try 1)
Last week I mentioned that Leon Brocard's wishlist for the next Parrot
iteration included Objects. This week Dan posted his first draft of what
Parrot Objects would and wouldn't be able to do. The eleventh entry on
Dan's list (Objects are all orange) seemed to be custom made to please
Leon. There was a fair amount of discussion (of course), but the
consensus was positive.
http://makeashorterlink.com/?S13C31513
The benchmarking problem
Nicholas Clark crossposted to p5p and perl6-internals to discuss the
problems of benchmarking parrot against perl 5. One of parrot's aims is,
of course, to go faster than perl 5. The problem is, how do you measure
'faster'? Nicholas has been working on making perl 5 go faster and was
distressed to find out that using 'perlbench' a patch of his went 5%
faster, 1% slower, 0% and 1% faster, depending on what machine/compiler
combination he ran the benchmark on. Leo Tötsch commented that he'd
found performance varying by over 50% in a JIT test, depending on the
position of a loop in memory. Andreas Koenig commented that he'd come to
the conclusion that bugs in glibc meant that there was little point in
benchmarking Perl at all if it was built with a glibc older than version
2.3 (apparently malloc/free proved to be gloriously erratic...) I'm
afraid not much was actually resolved though.
http://makeashorterlink.com/?L64C22513
Meanwhile, in perl6-language
The discussion of Variable types vs Value types continued from the
previous week. Dan opined that Arrays weren't necessarily objects, which
brought forth squawks from Piers Cawley who pointed out that being able
to do:
class PersistentList is Array {
method FETCH ($index) {
...
}
...
}
would be much nicer than tying a value in the Perl 5ish fashion. Dan
reckoned that delegation would probably be enough which, IMHO seemed to
miss the point. Various other people chimed in to, essentially, tell Dan
that he was wrong, but I'm not sure Dan agreed with them.
Meanwhile, in a
Re: This week's Perl Summary
[EMAIL PROTECTED] wrote: Rafael Garcia-Suarez earned at least one giggle when he suggested that we just needed v~ ^~ and we had our own flavour of Befunge. I promise: Lyon.pm does _not_ earn anything from Chris Pressey [0] in order to support Befunge! :-) Jerome [0] Chris Pressey is Befunge's creator -- [EMAIL PROTECTED]
RE: Objects, finally (try 1)
-Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED]] A property is a runtime assignable name/value pair that you stick on a variable or value. An attribute is a named variable that all objects of a particular class have. Properties can come and go at runtime, but attributes are fixed. (I think you could also consider attributes instance variables, but I'm a bit OO fuzzy so I'm not sure that's entirely right) Ok, in the case of python or ruby, instance variables are not fixed and they are not declared as part of the class. I suppose this can be handled by giving such classes one hash attribute for storing these instance variables. You're off. It'll be something like: callmethod Px, method_name or jmpmethod Px, method_name Is there going to be any way to (in PASM) find a method with out invoking it? I am not sure, but it may be useful for currying and some efficiency stuff (like moving dispatch outside of a loop that repeatedly invokes a method). Do we store ptrs to parent classes in one of these slots? Also Can I access slots like: set Px, Py[1]# store the name to offset hash in Px No the parent's gotten to via the vtable, and yes you can. Sorry if this is obvious, but which vtable method is used to get the parents? Thanks! -- Jonathan Sillito
RE: Objects, finally (try 1)
From: Dan Sugalski [mailto:[EMAIL PROTECTED]] At 9:51 AM -0800 1/14/03, Jonathan Sillito wrote: Below are some questions about this ... And now some answers. :) From: Dan Sugalski [mailto:[EMAIL PROTECTED]] [snip] Objects, as far as I see it, have the following properties: 1) They have runtime-assignable properties Terminology question: what is the difference between a property and an attribute? Perhaps the answer could go in the glossary. A property is a runtime assignable name/value pair that you stick on a variable or value. An attribute is a named variable that all objects of a particular class have. For a while perl6-language was using both terms for the runtime variable/value name/value tag. This stems from Perl 5.6's attributes and Attribute::Handlers modules. But in Perl6 s/attributes/properties/ because properties have nothing to do with OO, whereas 'attribute' has the object/class data-member meaning in OO. Properties can come and go at runtime, but attributes are fixed. (I think you could also consider attributes instance variables, but I'm a bit OO fuzzy so I'm not sure that's entirely right) Both classes and objects can have attributes. No runtime modification of class and/or object attributes... :( -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
RE: Objects, finally (try 1)
--- Garrett Goebel [EMAIL PROTECTED] wrote: From: Dan Sugalski [mailto:[EMAIL PROTECTED]] At 9:51 AM -0800 1/14/03, Jonathan Sillito wrote: Below are some questions about this ... And now some answers. :) From: Dan Sugalski [mailto:[EMAIL PROTECTED]] [snip] Objects, as far as I see it, have the following properties: 1) They have runtime-assignable properties Terminology question: what is the difference between a property and an attribute? Perhaps the answer could go in the glossary. A property is a runtime assignable name/value pair that you stick on a variable or value. An attribute is a named variable that all objects of a particular class have. For a while perl6-language was using both terms for the runtime variable/value name/value tag. This stems from Perl 5.6's attributes and Attribute::Handlers modules. But in Perl6 s/attributes/properties/ because properties have nothing to do with OO, whereas 'attribute' has the object/class data-member meaning in OO. Properties can come and go at runtime, but attributes are fixed. (I think you could also consider attributes instance variables, but I'm a bit OO fuzzy so I'm not sure that's entirely right) Both classes and objects can have attributes. No runtime modification of class and/or object attributes... :( So a property is just an element in a hash attribute? __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
[perl #20320] [PATCH] bring pdd06_pasm.pod up to date
# New Ticket Created by Jonathan Sillito # Please include the string: [perl #20320] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=20320 The documentation for the lexical ops in pdd06_pasm.pod has gotten out of date. I do not like maintaining documentation in more than one place, so in pdd06_pasm.pod I put a terse (but correct) description along with a reference to the generated documentation in docs/core_ops.pod. Is that suitable? In addition to changes to pdd06, the attached patch also adds documentation for the push_pad op to core.ops, which I somehow missed. -- Jonathan Sillito -- attachment 1 -- url: http://rt.perl.org/rt2/attach/48635/37746/ca96a3/documentation.patch documentation.patch Description: documentation.patch
RE: Objects, finally (try 1)
At 12:38 PM -0800 1/14/03, Jonathan Sillito wrote: -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED]] A property is a runtime assignable name/value pair that you stick on a variable or value. An attribute is a named variable that all objects of a particular class have. Properties can come and go at runtime, but attributes are fixed. (I think you could also consider attributes instance variables, but I'm a bit OO fuzzy so I'm not sure that's entirely right) Ok, in the case of python or ruby, instance variables are not fixed and they are not declared as part of the class. I suppose this can be handled by giving such classes one hash attribute for storing these instance variables. Less work than that even. While the attributes aren't declared formally, the compiler definitely knows what they are, and can allocate space as needed. The only place you'll run into issues is either runtime introduction of attributes (after the class has been compiled) or writing to attributes by name. Though the need to add attributes after the fact is an important one--we don't want to have to go rejigging every object that derives from some wacky parent class every time that class adds or removes an attribute. You're off. It'll be something like: callmethod Px, method_name or jmpmethod Px, method_name Is there going to be any way to (in PASM) find a method with out invoking it? I am not sure, but it may be useful for currying and some efficiency stuff (like moving dispatch outside of a loop that repeatedly invokes a method). Yep. There should be a can operator, though I'm not sure how often one wants to check for the existence of a method in an object without calling it. But no reason not to. More for rev 2. Do we store ptrs to parent classes in one of these slots? Also Can I access slots like: set Px, Py[1]# store the name to offset hash in Px No the parent's gotten to via the vtable, and yes you can. Sorry if this is obvious, but which vtable method is used to get the parents? It should be hanging off the vtable as one of the fixed slots. I think it isn't, though, so that needs fixing too. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Objects, finally (try 1)
At 1:24 PM -0800 1/14/03, Mr. Nobody wrote: So a property is just an element in a hash attribute? No. Properties are separate from anything OO. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Objects, finally (try 1)
At 3:05 PM -0600 1/14/03, Garrett Goebel wrote: From: Dan Sugalski [mailto:[EMAIL PROTECTED]] Properties can come and go at runtime, but attributes are fixed. (I think you could also consider attributes instance variables, but I'm a bit OO fuzzy so I'm not sure that's entirely right) Both classes and objects can have attributes. No runtime modification of class and/or object attributes... :( Larry's decision, and a common one with OO languages. Not universal, though, so time to go fix... :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: benchmarking - it's now all(-1,0,1,5,6)% faster
At 7:43 AM +0100 1/14/03, Leopold Toetsch wrote: BTW, I legitimatly don't know. I have a sinking suspicition that the only way to know if somthing is a jump target is to scan through the entire bytecode and check if it gets used as one. I'm all for having an optional jump/branch target section in the bytecode that can be filled in, and have performance suffer if something decides to jump/branch to an un-noted location. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Objects, finally (try 1)
On Tue, 14 Jan 2003 17:18:22 -0500, Dan Sugalski [EMAIL PROTECTED] wrote: Dan: You're off. It'll be something like: callmethod Px, method_name or jmpmethod Px, method_name Jonathan: Is there going to be any way to (in PASM) find a method with out invoking it? I am not sure, but it may be useful for currying and some efficiency stuff (like moving dispatch outside of a loop that repeatedly invokes a method). Dan: Yep. There should be a can operator, though I'm not sure how often one wants to check for the existence of a method in an object without calling it. But no reason not to. More for rev 2. I think what Jonathan asked for was an operator for returning a method (as an object) which can be invoked later with some arguments (or even applied with a partial list of arguments for currying). This would be a lot more useful than a yes-or-no answer about the existence of a method. -- Adriano
Re: Objects, finally (try 1)
Dan: Yep. There should be a can operator, though I'm not sure how often one wants to check for the existence of a method in an object without calling it. But no reason not to. More for rev 2. Adriano: I think what Jonathan asked for was an operator for returning a method (as an object) which can be invoked later with some arguments (or even applied with a partial list of arguments for currying). This would be a lot more useful than a yes-or-no answer about the existence of a method. I think just knowing it exists would be useful (ala java's reflection) since you might want to know if it exists in order to do some set of calculations before calling it, since if it doesn't exist there's a better/different set of calcs you need to do that have no use for the first set. I also like currying functions, which I can see kindof wanting the funcall pointer (although ... would it also need some way of garnering what the parameterlist (quantity or types) is?) ... Luckily the former (yes/no) can be easily inferred from the latter (funcall ptr) simply by if the pointer is null, that'd be a no :) although, with the parameter info that may be encapsulated and returned in some way with the fptr (if any is returned, that is), it might also be beneficial to have a seperate opcode for just tell me if it exists, depending on how much overhead the fptr param-info incurs ... Short version: I think both are good. Yes/No is inferrable from a pointer, but if the pointer has to include other information (and thus be a full PMC or however, precisely) seperate might be good. --attriel
Re: Objects, finally (try 1)
On Tue, Jan 14, 2003 at 12:38:35PM -0800, Jonathan Sillito wrote: -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED]] A property is a runtime assignable name/value pair that you stick on a variable or value. An attribute is a named variable that all objects of a particular class have. Properties can come and go at runtime, but attributes are fixed. (I think you could also consider attributes instance variables, but I'm a bit OO fuzzy so I'm not sure that's entirely right) Ok, in the case of python or ruby, instance variables are not fixed and they are not declared as part of the class. I suppose this can be handled by giving such classes one hash attribute for storing these instance variables. Yeah, that would be similar to how Python works now anyway; all instance attributes are stored in a dict which is itself accessible as an attribute on an instance: '__dict__'. Oh, except for the new __slots__ feature, which might actually find a use with the fixed-attribute-system that Dan has proposed. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project -+ http://twistedmatrix.com/users/radix.twistd/
Re: Objects, finally (try 1)
On Tue, Jan 14, 2003 at 03:00:17PM -0500, Dan Sugalski wrote: At 11:44 AM -0800 1/14/03, Mr. Nobody wrote: Seems pretty reasonable, but don't you mean PerlRef, PerlAttr, PerlClass, PerlObject? Nope. There's nothing particularly perlish about them, and if we're going to have a common base set of object functionality, they'll probably be named ParrotRef/Attr/Class/Object. They should suffice for perl, python, and ruby (at the very least) unless I've missed something. Hmm, well. Are you really trying to make it so Python won't have to make a specialized subclass (err, subPMC?) of this system? If so, then it'll probably need drastic changes.. I'm a Python hacker who's pretty familiar with its object system. If you want, I can offer up some explanations/advice for making this system usable directly by Python. As it stands, an implementation of the Python object system could definitely be implemented _in terms of_ what you have now, but, for example, the method system that you have worked out now would be totally unusable (afaics), as instance methods have some pretty whacky, dynamic semantics. It'd probably have to be implemented in terms of properties. The problem, of course, is that either you go more static and make the very dynamic, reflective languages like Python harder to implement (or prevent them from making use of your existing abstractions like methods, as explained above), or you go more dynamic and make the more static languages (like Haskell?) slower because they'd have to implement their features in terms of dynamic ones, when a lot of the information could be available at compile-time. But who knows, maybe it could be made modular enough (i.e., more interface-oriented?) to allow the best of both worlds -- I'm far too novice wrt Parrot to figure out what it'd look like, unfortunately. I've been lurking this thread for a while, very interested, and unsure if I should offer my suggestions for making the object system more compatible with Python, and this looks like a great chance for me to jump in. :-) -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project -+ http://twistedmatrix.com/users/radix.twistd/
Re: Objects, finally (try 1)
At 6:16 PM -0500 1/14/03, attriel wrote: Short version: I think both are good. Yes/No is inferrable from a pointer, but if the pointer has to include other information (and thus be a full PMC or however, precisely) seperate might be good. I think we're going to have to go with can and method calls leave it at that. Much as I'd like to have automatically fetchable method PMCs, I don't think it's feasable at this point. I may well change my mind later--certainly wouldn't be the first time. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Objects, finally (try 1)
At 8:53 PM -0800 1/14/03, Adriano wrote: On Tue, 14 Jan 2003 17:18:22 -0500, Dan Sugalski [EMAIL PROTECTED] wrote: Dan: You're off. It'll be something like: callmethod Px, method_name or jmpmethod Px, method_name Jonathan: Is there going to be any way to (in PASM) find a method with out invoking it? I am not sure, but it may be useful for currying and some efficiency stuff (like moving dispatch outside of a loop that repeatedly invokes a method). Dan: Yep. There should be a can operator, though I'm not sure how often one wants to check for the existence of a method in an object without calling it. But no reason not to. More for rev 2. I think what Jonathan asked for was an operator for returning a method (as an object) which can be invoked later with some arguments (or even applied with a partial list of arguments for currying). This would be a lot more useful than a yes-or-no answer about the existence of a method. I thought about this--it's what the find_method vtable method was for in the first place. Unfortunately, as was pointed out to me, there's no good way to cache the result, since it could potentially be wrong by the time the method is actually called. We could potentially get around this if we put in place a notification framework to invalidate these method handles, but that means we have to have a fair amount of infrastructure in place to do that. (Though, honestly, I do really like the idea, as it means we can be faster by default and just pay the price when things change, but there's that pesky code that needs writing and systems that need designing to support it...) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Objects, finally (try 1)
At 9:18 PM -0500 1/14/03, Christopher Armstrong wrote: On Tue, Jan 14, 2003 at 12:38:35PM -0800, Jonathan Sillito wrote: -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED]] A property is a runtime assignable name/value pair that you stick on a variable or value. An attribute is a named variable that all objects of a particular class have. Properties can come and go at runtime, but attributes are fixed. (I think you could also consider attributes instance variables, but I'm a bit OO fuzzy so I'm not sure that's entirely right) Ok, in the case of python or ruby, instance variables are not fixed and they are not declared as part of the class. I suppose this can be handled by giving such classes one hash attribute for storing these instance variables. Yeah, that would be similar to how Python works now anyway; all instance attributes are stored in a dict which is itself accessible as an attribute on an instance: '__dict__'. Oh, except for the new __slots__ feature, which might actually find a use with the fixed-attribute-system that Dan has proposed. I'm pretty sure (though not 100% sure) that the non-slot attribute stuff in python would actually correspond to variable properties, rather than attributes, but I may be incorrect here. Are the current python instance attributes both: *) defined per object rather than per class *) Essentially global, that is not hidden from parent classes or anything. (Basically one big pool 'o things attached to the object) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Objects, finally (try 1)
At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote: On Tue, Jan 14, 2003 at 03:00:17PM -0500, Dan Sugalski wrote: At 11:44 AM -0800 1/14/03, Mr. Nobody wrote: Seems pretty reasonable, but don't you mean PerlRef, PerlAttr, PerlClass, PerlObject? Nope. There's nothing particularly perlish about them, and if we're going to have a common base set of object functionality, they'll probably be named ParrotRef/Attr/Class/Object. They should suffice for perl, python, and ruby (at the very least) unless I've missed something. Hmm, well. Are you really trying to make it so Python won't have to make a specialized subclass (err, subPMC?) of this system? If so, then it'll probably need drastic changes.. I'm a Python hacker who's pretty familiar with its object system. If you want, I can offer up some explanations/advice for making this system usable directly by Python. Thanks--I *really* appreciate that. As it stands, an implementation of the Python object system could definitely be implemented _in terms of_ what you have now, but, for example, the method system that you have worked out now would be totally unusable (afaics), as instance methods have some pretty whacky, dynamic semantics. It'd probably have to be implemented in terms of properties. Methods I'm not actually worried about, though we've not much discussed them. (I think you'll find that Python's got nothing on Ruby or Perl for method wackiness... :) Though you've definitely pointed out an area that I need to get more detailed. Method dispatch is the one place I know that we may have custom behaviour, but I don't think it'll actually be necessary. Python method dispatch, from the references I have, isn't unusual, which is a good thing. (Plus I'll be layering multimethod dispatch on top, but that'll be transparent) The problem, of course, is that either you go more static and make the very dynamic, reflective languages like Python harder to implement (or prevent them from making use of your existing abstractions like methods, as explained above), or you go more dynamic and make the more static languages (like Haskell?) slower because they'd have to implement their features in terms of dynamic ones, when a lot of the information could be available at compile-time. At the moment the only really proposed static stuff is the attribute list, and only because I'm trying hard to stick with the more efficient array structure. (We could just bite the bullet and drop to using a tree, but I think we can avoid that in the common case if we have a fallback--I just need to define the fallback now) But who knows, maybe it could be made modular enough (i.e., more interface-oriented?) to allow the best of both worlds -- I'm far too novice wrt Parrot to figure out what it'd look like, unfortunately. It'll actually look like what we have now. If you can come up with something more abstract than: callmethod P1, foo that delegates the calling of the foo method to the method dispatch vtable entry for the object in P1, well... gimme, I want it. :) I'll add define method dispatch more to the list o' stuff for the next edit of the proposal. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
