Is there any way to dynamically add a method to a class?
So, I know how to use find_method to get a method from an object; but is there any way to dynamically add a method to a class? Basically, I want to do something like this: newclass P2, Foo new P1, P2 addr I0, _Foo::somemethod setmethod P1, somemethod, I0 findmethod P0, P1, somemethod invoke So, how do I do it? :) The only way I could figure out that might work was to make my own pmc class that held an alias to the class pmc itself as a property, and then treat the class itself as hash; however that seems extremely hackish, as well as pretty slow, as it would take an extra lookup to find the method. Any tips would be greatly appreciated. - Joe
string.c suggestions
Wouldn't it be us anything if we had have replaced some functions in string.c with its macroed versions. The candidates for to be macroed are sring_length, string_compute_strlen, string_copy, string_from_cstring, string_max_bytes, string_from_num, string_cstring_free. Though I know that those are API finctions, so we might be also better off if we reserved C-compiler prototype checks.
[PATCH] File Spec
- Original Message -
From: Leopold Toetsch [EMAIL PROTECTED]
Sent: Thursday, August 07, 2003 12:51 PM
Subject: TWEAKS: Takers Wanted - Effort And Knowledge Sought
Platform code
-
We need some functions to deal with paths and files like File::Spec.
For loading include files or runtime extension some search path should
be available to locate these files (a la use lib LIST;).
For now runtime/parrot/{include,dynext} and the current working
directory would be sufficient.
I ain't 100% sure what Leo wanted there and afraid that my patch is out of
place. Though it presets rudimentary support for the Parrot File::Spec-like
functions which are as follows: curdir, catdir, catfile.
I should warn you the patch is a lack of any documentation. Examples of
usage can be found in file_spec.t. Nevetheless does it need writing some
documentation on for non-perl folks and if it does where should I put it in?
The docs directory?
Next. In the future I'll need to be able to do some find 'n' replace
actions in order to clean the trash off of paths. The perl version
uses the regexes like these:
$path =~ s|/+|/|g unless($^O eq 'cygwin'); # xxxx - xx/xx
$path =~ s|(/\.)+/|/|g; # xx/././xx -xx/xx
$path =~ s|^(\./)+||s unless $path eq ./; # ./xx - xx
$path =~ s|^/(\.\./)+|/|s; # /../../xx -xx
$path =~ s|/\Z(?!\n)|| unless $path eq /;# xx/ - xx
The bodkin is whether I should take advantage of string_str_index,
string_replace and the rest Co or there is a better solution? In any
case it never uses long paths, so we won't be violently penalized while
using any of find 'n' replace sheme.
The last. I beg to be excused I couldn't prepare unified diffs
of file.ops, file_spec.c, file_spec.h, and file_spec.t with
diff -N -u. Alas. The better I got was:
cvs server: I know nothing about file.ops
cvs server: I know nothing about file_spec.c
cvs server: I know nothing about include/parrot/file_spec.h
cvs server: I know nothing about t/op/file_spec.t
Probably -N works only with files that have already been added
or removed and I have no write access to add those files to
the repository. I won't be surprised if oops! I did something
wrong again.
Comments, requests, threats are welcome, you know.
file_spec.diff
Description: Binary data
file.ops
Description: Binary data
file_spec.c
Description: Binary data
file_spec.h
Description: Binary data
file_spec.t
Description: Binary data
Re: [RfC] constant PMCs and classes
Leopold Toetsch [EMAIL PROTECTED] wrote:
[ snip ]
* const_string_from_cstring - return cached constant string or create one
* const_key_new_cstring - return cached PMC or create a constant PMC
Some more thoughts WRT this issue:
- PerlHash isn't suitable for storing/lookup these STRINGs/Keys
- so we would need a new hash type with a Cconst char* key
(a simple implementation like the SymReg* hash inside symreg.c would
suffice IMHO)
- the keys shouldn't be copied into the hash, so they should be
declared Cstatic const s[] = xxx (allocated in rodata).
constant_key_new_cstring() is only needed because the hash interface is
missing optimized a {s,g}et_type_keyed_str() interface.
- the constant hash can be in the interpreter-iglobals array
- implementation in a new Fconstants.c source file
Comments welcome,
leo
PS: why we need it IMHO:
$ find . -name '*.c' | xargs egrep '_cstring.*\w+'
There are more, which are using string_make or multiple lines.
Re: Weak References?
Benjamin Goldberg [EMAIL PROTECTED] writes: this is only useful if a hashlookup is fast compared with string_make. Well, it might be. Hashing can be quite fast, ya know. Here's a better idea, one you'll have more difficulty arguing with -- imagine a debugger, written in parrot. We are going to have one, right? Hmm, p6tkdb :) It needs to keep references to objects it's interested in, but if they're strong references, then we would have trouble debugging objects with custom destroys (or worse, objects needing timely destruction), since the debugger's references to them would prevent them from being cleaned up. In general, I'd expect the Perl 6 debugger to use symbolic references to variables and use %MY based introspection to get at values. Watchlists could be implemented by via properties with closures that refered back to the debugger object. In general it should be possible to implement a remarkably powerful perl 6 debugger without needing weakrefs (though weakrefs wouldn't hurt).
NEWBIE Questions about bytecode emitting and JIT Compiling and an OO library
Dear fellow hackers, First of all, I would like to say that I hope that you dont take offence at my silly questions and crazy ideas! ;) I have been looking in the amazing work that you have been doing with parrot and the work that Michal Wallace has been doing with the Pirate, the following questions have came to mind : 1. Is it possible to stored in some way ASTs inside of parrot IMC byte code in such a way that they may be evaluated and compiled at runtime? We talked about this in the context of metadata and bazookas months ago, and I am ready to start making a simple prototype on top of pirate for storeing the ASTS in the metadata alongside of the bytecode. 2. Is it possible to emit new IMC routines on the fly and have them be loaded in as if they came from the load routine? like a form or reflection.emit? 3. It is possible to make the entire parrot object system as a lib that implements objects as special variables? like the old ATT CFront? 4. Is there any attempts at debugging support in parrot, for a way to mix the original source code and assembly together, a way to enable tracebility of. These features would allow portions of the features not supported to be added into a lib and for the lib to JIT implement these funky features or fail gracefully. Any ideas or am I way over board? mike PS: please feel free to ban me from this list for wasting your time and bytes with off topic posts and crazy ideas, you may have the sudden urge to ban me for no reason at all whatsoever. :) = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: NEWBIE Questions about bytecode emitting and JIT Compiling and an OO library
James Michael Dupont [EMAIL PROTECTED] wrote: Dear fellow hackers, First of all, I would like to say that I hope that you dont take offence at my silly questions and crazy ideas! ;) There are no silly questions, only silly answers and crazy ideas are the motor of development - trying to answer some: 1. Is it possible to stored in some way ASTs inside of parrot IMC byte code in such a way that they may be evaluated and compiled at runtime? Not yet. But parrot should finally be able to run from some kind of AST directly. 2. Is it possible to emit new IMC routines on the fly and have them be loaded in as if they came from the load routine? like a form or reflection.emit? Yes. Have a look at t/syn/eval.t and languages/parrot_compiler/parrot.pasm. 4. Is there any attempts at debugging support in parrot, for a way to mix the original source code and assembly together, a way to enable tracebility of. HLL source is currently being discussed. PASM source + i386 assembly[1] can be stepped through: s. docs/jit.pod and docs/debug.pod. [1] may be other processors too. mike leo
Re: [RfC] constant PMCs and classes
Juergen Boemmels wrote:
Leopold Toetsch wrotes:
We currently have constant Key and Sub PMCs both created from the
packfile at load time. They live in the constant_table pointing to a
constant PMC pool. But we need more.
We have allover the core code like this:
string_from_cstring(interpreter, pIt, 0)
key = key_new_cstring(interpreter, _message);
to create some STRINGs or entries in hashes. The keys should be
constant PMCs and they should be shared as well as the STRINGs.
We need this in objects.c (\0\0anonymous), for setting standard
property names internally and for the current hash based
implementation of Exceptions.
[...]
Some time ago I did some experiments with initialising strings at
compile time. With some preprocessor magic and a perl program scanning
the c-file I got it running.
The changes to an existing c-file are minimal: At the beginning add a
#include FILE.str and replace all these string_form_cstring with
_S(text). The _S macros are replaced by static string_structures
with static initialisers. These string structures are in the ro-data
segement of the executable and should load really fast. No calls to
any functions.
I can think of a slightly easier method, one which would not depend on
running a helper perl program.
#define PCONCAT(b,c) _Parrot_static_##b##c
#define PARROT_DECLARE_STATIC_STRING(name, cstring) \
static const char PCONCAT(name,_cstring) [] = cstring; \
static const struct parrot_string_t \
PCONCAT(name,_STRING) = { \
{ /* pobj_t */ \
{{ \
(void*)PCONCAT(name,_cstring), \
sizeof(PCONCAT(name,_cstring)) \
}}, \
PObj_constant_FLAG \
GC_DEBUG_VERSION \
}, \
sizeof(PCONCAT(name,_cstring)), \
(void*)PCONCAT(name,_cstring), \
sizeof(PCONCAT(name,_cstring)) - 1, \
NULL, \
NULL, \
0 \
}, * const name = PCONCAT(name,_STRING);
[untested]
Then, of course, one can simply declare the names and values of one's
constant strings in any place where variables may be declared, using:
PARROT_DECLARE_STATIC_STRING(mystr, some string here);
Now, there's a const STRING * const mystr variable, whose contents are the
some string here. Actually, I'm not sure that there's a need for the
PCONCAT(name,_cstring) variable -- it might be possible to use cstring
directly when initializing the struct.
--
$a=24;split//,240513;s/\B/ = /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
The Perl 6 Summary
The Perl 6 Summary for the week ending 20030824 Another week, another Perl 6 summary. I'm running late writing this and I don't care because I spent the bank holiday weekend at a folk festival and didn't get back 'til Monday evening. Predictably enough, we'll start with the shenanigans in perl6-internals. Timely Destruction: Luke Palmer's Scheme The timely destruction meme just won't go away. This week Luke Palmer suggested a possible improvement to Parrot's current scheme (Parrot keeps a counter of 'eager' objects needing timely destruction, and a language's compiler emits conditional sweep opcodes at appropriate points. In Perl's case, for instance, the conditional sweeps would be triggered on scope exit, other languages may have different requirements). Luke's scheme involves terminating the DOD (Dead Object Detection) run if every outstanding eager object is found alive at any point in the run. For added performance, there would also be a 'high priority' flag on all objects. The idea is that the high priority flag could be used to ensure that, during a sweep, the paths through the object group that are likely to lead to an eager object get checked first, hopefully ensuring that the sweep gets terminated as quickly as possible in the case where no eager objects need to be finalized. The proposal was discussed, but I don't think anyone has gone so far as to implement anything based on the scheme. This discussion led Klaas-Jan Stol to ask what the heck timely destruction was, anyway. This sparked a longish discussion, covering what timely destruction is all about, why you'd want it, and why having it could be problematic. http://xrl.us/pu7 http://xrl.us/qxf The String API Benjamin Goldberg is concerned with 'a number of shortcomings in the [string] API' and outlined the problems he sees, along with some proposed improvements. Luke Palmer generally liked the ideas, but Leo Tötsch had concerns about some of Benjamin's proposals. The discussion that ensued got fairly technical. (One of these days I'm actually going to go and get my head properly around the details of the various encodings and charactersets. And then I'll probably go insane.) Dan also thought that Benjamin was confusing language level strings with low-level strings, and that this was a Bad Thing. He outlined the difference between language level (PMC) and low-level (Parrot S register) strings, and explained what each was appropriate for. http://xrl.us/qxg Making the Perl 6 Compiler use Continuation Passing Style Allison Randal sent in a patch to switch languages/perl6 -- Parrot's (incomplete) Perl 6 Compiler -- over to using Continuation Passing Style, which is a useful step in the right direction. Leo applied it. http://xrl.us/qxh Fun with search_lex Jos Visser (who in an earlier post confided that he's working on writing a parrot compiler back end for his personal 'computer language personality disorder: Comal', and that he does this for 'therapeutical value') wants to generate some parrot code that is capable of searching the lexical pads for the existence of a lexical. His current code tries to look up a lexical and catches the exception when the lexical doesn't exist, but this is apparently very slow. So, he proposes an op, search_lex which, instead of throwing an exception, returns a null PMC if the lexical is not found. Leo Tötsch wasn't convinced by the need for the op, but he is looking into why the exception handling route is so slow (indeed, he seems to have found the reason, now he's trying to fix it). http://xrl.us/qxi Syntax Highlighting Inspired by Luke Palmer's cunning, core.ops parsing vim syntax highlighter, Andy Bussey wrote something similar for the KDE Kate editor. Now, if someone could modify pasm.el, the Emacs highlighting mode to use the autogeneration trick too... http://xrl.us/qxj RFC: Constant PMCs and Classes Leo Tötsch kicked off a discussion of the handling of constants within Parrot and proposed adding a bunch of functions for creating constant strings (symbols?) within the core. He also proposed a system for creating constant classes. In the ensuing discussion I think the proposals for strings were pretty much accepted, but it's not yet known if the proposal for constant classes is quite the Right Thing. http://xrl.us/qxk Should Tom Locke target parrot? Tom Locke is about to start on a project to create a new language and wondered if Parrot might be a good target VM for him. In short, we think so. But we would, wouldn't we? http://xrl.us/qxl More fun with set/assign The semantics of set in Parrot are, somewhat complex. Leo Tötsch showed a fragment of code which got a value from out
