Re: Objects, finally (try 1)
If memory serves me right, Jonathan Sillito wrote: > x = a.f # get the method, a limited form of currying > # since the first arg (a==self) is stored > x() # output: A.f() > > setattr(A, "f", g) # replace A's f with g > > a.f()# output: g() > x() # output (still): A.f() !!! > > Which shows that the dispatch (i.e. selecting which method to call) can > happen before the invocation. This makes sense let me put it in this way x_mthdptr=a.__dict__["f"] a.__dict__["f"]=g_mthdptr x_mthdptr() The dispatch vs invocation looks childishly simple when written this way.. (and I hope I'm right about that ... :) Underneath the high level language most things are really simple ... The Python compiler should work around all these language quirks and generate appropriate Parrot code ... In bytecode it should look direct, simple and fast !. Gopal -- The difference between insanity and genius is measured by success
pretty pictures
I was playing with doxygen (www.stack.nl/~dimitri/doxygen/index.html) (think javadoc for C++) and thought I'd pass along some random pictures. Doxygen unfortunately doesn't handle perl code, and even has problems with parrot's C. (IMHO, the world needs a wrapper hack which allows you to run all these variously broken code analysis tools, and then gloms their outputs together into something browsable. Ah well. Todo list.) Attached are the interpreter.h include tree, and the PMC and Arena datastructure graphs. (Why not Interp? See previous paragraph). GraphVis (www.graphviz.org) did the actual drawing. Hmm. Maybe a picture of the complete include graph would be useful introductory material... Mitchell <><><>
Re: pretty pictures
--- Mitchell N Charity <[EMAIL PROTECTED]> wrote: > Doxygen unfortunately doesn't handle perl code, and even has problems > with parrot's C. You might be interested in autodia, it handles perl. http://droogs.org/autodia/ > (IMHO, the world needs a wrapper hack which allows > you to run all these variously broken code analysis tools, and then > gloms their outputs together into something browsable. > Ah well. Todo > list.) The goal of the introspector is to publish a RDF/XML ontology of the various systems and thier dumps. Then you can merge the ontologies on a logical level and transform them between each other. Well what exactly do you need? I will be looking in running the introspector over the parrot code. That will produce a rdf file of the entire parrot source code. I would like to also figure out how to extract the high-level infomration from perl. The next step for the introspector was B::ToXML and to get that running. But for Perl6, i wonder what that best way to get at the data? The assembler does not contain any high level information. > GraphVis (www.graphviz.org) did the actual drawing. Yes, that is on major goal of the introspector project to replace this funky non-free graphvis with the VCG. I hope to port VCG to GTK this year, and integrate it with DIA for a nice graph editor. http://rw4.cs.uni-sb.de/users/sander/html/gsvcg1.html > Hmm. Maybe a picture of the complete include graph would be useful > introductory material... the graphs you doxygen produces are great. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
[CVS ci] eval #1
So I did it. Check in the first version of eval. First of all, I changed pdd06_pasm, the compile and compreg opcodes didn't fit really well into - well - my scheme of objects. A compiler is now a Parrot class, derived from NCI, living in interpreter->Parrot_compreg_hash. This also needed a change to the NCI code. Parrot_new_nci() is gone, the way to go now is: create a new NCI/Compiler object and then call its set_string_keyed() method to set the start address and the signature. This is somewhat hackish but consistent with Sub.pmc's set_integer() call to set the address of a parrot sub. Please, have a look at the changes in core.ops and interpreter.c for the construction of these objects. A parrot interpreter class would fit in this scheme too - and it allows for early anchoring the PMC. The return value of a compile call is currently - due to the lack of byte code segments - a plain pointer to the generated code. For PDB_compile() this is a static variable space, meaning: you should invoke this code before compiling new one. For imcc the code gets appended to the code->byte_code of the interpreter, which might cause reallocation and segfaults, when returning from the evaled code. So this code is not really usable until multiple code segments are done too. Test status: make test succeeds, as well as -P, running the eval progs with JIT or with -t (trace)/-b (bounds) option fails, probably related to messing with the byte code. Imcc notes: As the evaled code runs in its own runloop it must be terminated with an 'end' opcode. Imcc could provide one if needed. Missing and left for an exercise for Joe Other Parrothacker: build_nativecall.pl lacks to handle an 'I' signature type, the interpreter should be pushed on the stack. Also the signature "pIt" is missing. So eval runs only on jit/i386 now. Finally: please do a "make realclean" after checkout. Have fun leo PS diffstat: MANIFEST |2 classes/csub.pmc |2 classes/default.pmc| 19 - classes/nci.pmc| 30 -- classes/sub.pmc|5 core.ops | 35 ++ debug.c| 22 + docs/pdds/pdd06_pasm.pod | 18 + dod.c |2 include/parrot/debug.h |1 include/parrot/interpreter.h |2 include/parrot/method_util.h |1 interpreter.c | 40 +++ jit/i386/jit_emit.h|3 languages/imcc/imcc.l |7 languages/imcc/imclexer.c | 421 - languages/imcc/main.c |2 languages/imcc/parser.h|3 languages/imcc/parser_util.c | 75 + languages/imcc/pbc.c | 17 - method_util.c | 18 - parrot-leo/languages/imcc/t/syn/eval.t | 39 +++ parrot-leo/t/pmc/eval.t| 42 +++ 23 files changed, 521 insertions(+), 285 deletions(-)
RE: pretty pictures
I have a Perl program that processes Perl source and generates fake C++ headers that doxygen will process. Doxygen doesn't have a hook for adding a new parser, so this is the only way to hack it. The doxygen way of doing things depends pretty heavily on special comments. My doxygen hack pulls a lot of stuff automatically _without_ special comments, but is highly dependent on my coding style. I can only recommend it as an example, it's not like supported or anything. Having said all that, I am in fact a fan of doxygen. I find it in use all the time on various open source projects. mma > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 15, 2003 5:30 PM > To: [EMAIL PROTECTED] > Subject: pretty pictures > > > I was playing with doxygen (www.stack.nl/~dimitri/doxygen/index.html) > (think javadoc for C++) and thought I'd pass along some random pictures. > > Doxygen unfortunately doesn't handle perl code, and even has problems > with parrot's C. (IMHO, the world needs a wrapper hack which allows > you to run all these variously broken code analysis tools, and then gloms > their outputs together into something browsable. Ah well. Todo list.) > > Attached are the interpreter.h include tree, and the PMC and Arena > datastructure graphs. (Why not Interp? See previous paragraph). > > GraphVis (www.graphviz.org) did the actual drawing. > > Hmm. Maybe a picture of the complete include graph would be useful > introductory material... > > Mitchell >
is, has, and does (more object stuff)
I still have most of yesterday's p6i mail to dig through (and probably won't until this evening), but one thing that's struck me (courtesy of an ill-timed grumble about objects) is that there are really three ways to do inheritance, and most languages sort of do them, with varying amounts of dancing around. The three, as I see it, are: *)is - The standard parent/child thing, where the derived class is a more specialized version of the parent class. This seems to be a fallback mechanism when others might be more appropriate. This is done with straight inheritance. *)has - This is the container/delegation thing, where a class isn't really a more specialized version of another class, but instead a container of sorts. This is done via delegation. *)does - This is the interface/guaranteed behaviour thing, where a class just promises that it has a certain set of methods Everyone does them all in half-hearted ways, but I'm thinking we need to formally support all three, since it'll make doing things properly easier. (And if a language has built-in hacks to do one of them another way, that's fine--we don't have to fix that, they just won't get the engine advantages) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: pretty pictures
The ability to download autodia off of the primary site and the mirror is unfortunately broken. -Tupshin James Michael DuPont wrote: --- Mitchell N Charity <[EMAIL PROTECTED]> wrote: Doxygen unfortunately doesn't handle perl code, and even has problems with parrot's C. You might be interested in autodia, it handles perl. http://droogs.org/autodia/ (IMHO, the world needs a wrapper hack which allows you to run all these variously broken code analysis tools, and then gloms their outputs together into something browsable. Ah well. Todo list.) The goal of the introspector is to publish a RDF/XML ontology of the various systems and thier dumps. Then you can merge the ontologies on a logical level and transform them between each other. Well what exactly do you need? I will be looking in running the introspector over the parrot code. That will produce a rdf file of the entire parrot source code. I would like to also figure out how to extract the high-level infomration from perl. The next step for the introspector was B::ToXML and to get that running. But for Perl6, i wonder what that best way to get at the data? The assembler does not contain any high level information. GraphVis (www.graphviz.org) did the actual drawing. Yes, that is on major goal of the introspector project to replace this funky non-free graphvis with the VCG. I hope to port VCG to GTK this year, and integrate it with DIA for a nice graph editor. http://rw4.cs.uni-sb.de/users/sander/html/gsvcg1.html Hmm. Maybe a picture of the complete include graph would be useful introductory material... the graphs you doxygen produces are great. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
[perl #20355] [PATCH] Incorrect ifdef nesting in cpu_dep.c
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #20355]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=20355 >
I don't think the ifdef logic is quite right in cpu_dep.c. Specifically,
if either __sparc or __ia64__ is defined, then *both* the cpu-dependent
register flushing *and* the setjmp-using register flushing tricks are
used.
This actually shows up as a syntax error on the "frivolous" tinderbox.
The enclosed patch changes the logic to what I suspect was actually
intended.
--- parrot-current/cpu_dep.cSat Jan 4 03:00:09 2003
+++ parrot-andy/cpu_dep.c Thu Jan 16 13:49:32 2003
@@ -26,7 +26,7 @@
trace_system_areas(struct Parrot_Interp *interpreter)
{
-#ifdef __sparc /* Flush register windows */
+#if defined(__sparc) /* Flush register windows */
static union {
int insns[4];
double align_hack[2];
@@ -42,10 +42,8 @@
static void (*fn_ptr)(void) = (void (*)(void))&u.align_hack[0];
fn_ptr();
-#endif
-
-#ifdef __ia64__
+#elif defined(__ia64__)
struct ucontext ucp;
void *current_regstore_top;
--
Andy Dougherty [EMAIL PROTECTED]
Re: [perl #20355] [PATCH] Incorrect ifdef nesting in cpu_dep.c
At 7:29 PM + 1/16/03, Andy Dougherty (via RT) wrote: The enclosed patch changes the logic to what I suspect was actually intended. Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: optimising, and per file flags
On Mon, Jan 13, 2003 at 09:22:07AM -0800, Steve Fink wrote:
> On Jan-12, Nicholas Clark wrote:
> > IIRC Leo added an option to Configure.pl to turn on optimising.
> >
> > Prior to this, on IRC Dan said to me that we need to avoid the hack that perl5
> > found itself in, when it had to retro-fit the ability to change the compiler
> > flags per file.
> Would it be better to do it the other way around? We could put a
> marker at the end of each source file (mixed in with the emacs/vi flag
> section?) that specifies a set of compiler flags (or nothing at all if
> the default is ok.)
>
> If so, then I'd probably also use named sets ("big-jumptable-flags")
> or maybe even named modifiers ("default but violates-aliasing and
> trips-gcc2.95-O3-bug"). This would allow better descriptions of why
> the flags were being modified, and allow each compiler to deal with
> the situation differently (for "violates-aliasing", gcc would add
> -fno-strict-aliasing, lcc wouldn't do anything.)
I don't think that this will fly. The sort of flags we need to change are
things like this (Unicos):
if /etc/cpu -i | grep -q cfp
then
ccflags="$ccflags -h rounddiv"
fi
# Avoid an optimizer bug where a volatile variables
# isn't correctly saved and restored --Mark P. Lutz
pp_ctl_cflags='ccflags="$ccflags -h scalar0 -h vector0"'
# Otherwise the unpack %65c checksums will fail.
pp_pack_cflags='optimize="$ccflags -h scalar0 -h vector0"'
or this (Irix 6, based on a test of compiler version)
# workaround for an optimizer bug
# Made to work via UU/config.sh thing (or, rather, config.sh, since we're in
# a callback) from README.hints, plus further stuff; doesn't handle -g still,
# unfortunately - Allen
case "`$cc -version 2>&1`" in
*7.2.*)
test -z "$op_cflags" && echo "op_cflags=\"optimize=\\\"\$optimize -O1\\\"\"" >>
config.sh
test -z "$op_cflags" && op_cflags="optimize=\"\$optimize -O1\""
test -z "$opmini_cflags" && echo "opmini_cflags=\"optimize=\\\"\$optimize
-O1\\\"\"" >> config.sh
test -z "$opmini_cflags" && opmini_cflags="optimize=\"\$optimize -O1\""
;;
*7.3.1.*)
test -z "$op_cflags" && echo "op_cflags=\"optimize=\\\"\$optimize -O2\\\"\"" >>
config.sh
test -z "$op_cflags" && op_cflags="$op_cflags optimize=\"\$optimize -O2\""
test -z "$opmini_cflags" && echo "opmini_cflags=\"optimize=\\\"\$optimize
-O2\\\"\"" >> config.sh
test -z "$opmini_cflags" && opmini_cflags="optimize=\"\$optimize -O2\""
;;
esac
and other evil to work round compiler bugs found mainly by sweating blood.
(I don't know about the Irix bugs, but I do remember that working out
what the cause of Unicos bugs were wasn't fun. And I was mostly following
along at home by e-mail, not being able to offer Mark much more than
moral support. When unpack is going into an infinite loop on a Cray 6000 miles
away that you don't have any access to, there isn't much more you can do)
> I'm assuming the Configure system extracts the information from the
> source files and generates a makefile entry per source file with the
> appropriate compiler flags.
I'm also assuming a makefile entry for all source files with non-default
compiler flags, and a .c$(OBJ_EXT): rule for the default
So I'm thinking that we'll have a lot of per platform compiler specific
cruft that will need to be generalised programatically.
But more importantly we need a way for anyone to manually configure parrot
with wacky flags for a single file. Otherwise responses to perl6bug are going
to be along the lines of "edit the section in the source file, and add a new
(complex) rule that will trigger on your platform. Then reconfigure. Then
check the Makefile to see if that rule really did trigger".
Nicholas Clark
Re: [CVS ci] eval #1
Leopold Toetsch wrote: So I did it. Check in the first version of eval. Test status: make test succeeds, as well as -P, running the eval progs with JIT or with -t (trace)/-b (bounds) option fails, probably related to messing with the byte code. Fixed. bug in -j was triggered by garbage memory in the opcode lookup hash bug with -b/-t was due to wrong/missing bounds of the eval "code segment" leo
[perl #20358] [BUG] disassemble still
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #20358]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=20358 >
disassemble sometimes takes huge amounts of mem and dies.
I'm using disassemble to get a test coverage of ops with this shell script:
#!/bin/sh
# op-stat
DIS=disassemble
[ -e .op-list1 ] && rm .op-list1
[ -e op-list-all ] && rm op-list-all
[ -e op-list-s ] && rm op-list-s
find . -name '*.pbc' -fprint /dev/stderr -exec $DIS {} \; |
sed -e's/^[[:blank:]]*L[0-9]*://' | \
sed -e's/^[[:blank:]]+//' | cut -d\ -f1 >> .op-list1
sort < .op-list1 | uniq -c | sort -rg > op-list-all
sort < .op-list1 | sed -e's/_.*//' | uniq -c | sort -rg > op-list-s
echo
T=`grep NAME lib/Parrot/OpLib/core.pm | wc -l`
S=`grep NAME lib/Parrot/OpLib/core.pm | sort | uniq | wc -l`
echo total ops $T
echo ops types $S
echo op usage stat
wc -l op-list* | head -2
