Re: [perl #15340] [PATCH] Boolean PMC
At 07:45 PM 7/22/2002 -0400, Melvin Smith wrote: >At 05:47 PM 7/22/2002 +0100, Nicholas Clark wrote: >I think boolean is a language dependant thing and probably shouldn't >be implemented as a PMC. For some languages, boolean can be optimized >all the way down to the JIT level, and I'm not sure which languages would >actually want to use it as a PMC. Err let me rephrase that: Language "Foo" may need a Boolean PMC, and if it does, implementing it is fine. I just don't feel it belongs as a "core" PMC. -Melvin
Re: an aside on compiling speed (was Re: PARROT QUESTIONS: Keyed access)
At 09:58 PM 7/22/2002 +0100, Nicholas Clark wrote: >On Sun, Jul 21, 2002 at 11:46:34AM -0700, Scott Walters wrote: > > Perl 5 runs *awesome* on a 486/25. Java (Kaffe) is completely unusable. > > AWT windows come up in a matter of *days*, whereas a Tk window comes up > > in about 45 seconds. On a fast computer, these things are blurred. The > point > > is, you can thrash your system on a faster computer, but register > renaming, a > > large L2 cache, lots of disc bandwidth to thrash with etc obscured the > fact > > that you are wasting resources horribly. > >perl builds damn fine on a K5/133 with 16M of RAM. >parrot now takes 4 hours in swap hell to compile the computed goto ops. > >But that's a different story, and wondering how gcc works isn't the purpose of >this list. (No, I'm not going to *buy* a faster machine. The whole point is >that this machine was free, and is upgraded with other people's cast-offs. >But if anyone can suggest where to prod the code to make it compile faster >with no loss of functionality I'll have a prod. I prodded Encode's compiler >on 5.7.3, and in addition to going faster on my box, it also went >significantly >faster on everyone else's sensibly sized machines. But that was optimising >perl, whereas computed goto is C.) Feeling your pain, I already did some surgery on the whole core.ops and its spawn, but it appears we are still far from perfect. Originally find_op() used a gigantic (read 500k) unrolled switch statement which was the fastest on the planet, but took quite a lot of resources to compile. I suspect we may end up releasing binary builds for common platforms, but even this won't satisfy everyone. Dan has already said he doesn't care as much about compile time resources as he does about runtime resources, and I'm inclined to side with him, but I also have a gut feeling that there are things we can do better. -Melvin
Re: [perl #15340] [PATCH] Boolean PMC
At 05:47 PM 7/22/2002 +0100, Nicholas Clark wrote: > > Opefully, this can be accepted ;) > >Do pmc files get turned pretty directly into C code? Yep. >And if pmc files get turned pretty directly into C code, do the C++ style >comments stay in there? If yes and yes, then the patch won't be acceptable >as is. We need to use /* */ comments only, as // isn't valid in C89. Right, as usual. >(apart from that I don't know enough about anything perl6 to know whether >this is a good idea, and if so whether this is the best way to implement the >idea. Someone else knowledgeable will have to comment) I think boolean is a language dependant thing and probably shouldn't be implemented as a PMC. For some languages, boolean can be optimized all the way down to the JIT level, and I'm not sure which languages would actually want to use it as a PMC. But keep those patches coming! :) -Melvin
Re: [perl #15340] [PATCH] Boolean PMC
On Mon, 22 Jul 2002, Nicholas Clark wrote: > I will now demonstrate my ignorance of the parrot build system: > > > Do pmc files get turned pretty directly into C code? > Yes, via classes/pmc2c.pl. I don't see any code in there to replace the // style comments, but I didn't read too carefully. I'm only responding in case a more knowledgeable soul doesn't. -scott
Re: [perl #15340] [PATCH] Boolean PMC
On Mon, 22 Jul 2002, Nicholas Clark wrote:
> Do pmc files get turned pretty directly into C code?
Yes.
> > void set_bignum (PMC* value) {
> > /* XXX not sure if this can be optimized further safely */
> > // SELF->cache.struct_val = (DPOINTER*)value->vtable->get_bignum(INTERP,
>value);
> > /* SELF->vtable = &(Parrot_base_vtables[enum_class_PerlBigNum]); */
> > }
>
> And if pmc files get turned pretty directly into C code, do the C++ style
> comments stay in there? If yes and yes, then the patch won't be acceptable
Yes. It needs to be changed to a C-style comment.
Simon
Friendly RE engine warning
I'm currently working on my Shishi parser/RE engine project, which shares some similarities with what you'll need from the Perl 6 RE engine. One thing that troubles me about it is that it's a recursive-descent traversal across a state machine, and if you implement this in C without a great deal of cleverness, you'll end up with something which makes it *very* easy for the end-user to blow the call stack and segfault. I'm driving myself nuts trying to turn an inherently recursive algorithm into an iterative one. :) (Maybe you could get better results by converting a Perl RE 6 from NFA to a DFA and use a superposition of states. But that messes with my head.) -- TorgoX: you're rapidly learning, I see, that XML is a fucking piece of festering shit which has no more justification for walking God's clean earth than a dung beetle with diarrhoea.
Re: [perl #15340] [PATCH] Boolean PMC
I will now demonstrate my ignorance of the parrot build system:
On Mon, Jul 22, 2002 at 04:23:08PM +, Alberto Manuel Brandão Simões wrote:
> Opefully, this can be accepted ;)
Do pmc files get turned pretty directly into C code?
Content-Description: boolean.pmc
> /* boolean.pmc
> * Copyright: (When this is determined...it will go here)
> * CVS Info
> * $Id$
> * Overview:
> * These are the vtable functions for the Boolean base class
> * Data Structure and Algorithms:
> * History:
> * Notes:
> * References:
> */
> void set_bignum (PMC* value) {
> /* XXX not sure if this can be optimized further safely */
> // SELF->cache.struct_val = (DPOINTER*)value->vtable->get_bignum(INTERP,
>value);
> /* SELF->vtable = &(Parrot_base_vtables[enum_class_PerlBigNum]); */
> }
And if pmc files get turned pretty directly into C code, do the C++ style
comments stay in there? If yes and yes, then the patch won't be acceptable
as is. We need to use /* */ comments only, as // isn't valid in C89.
(apart from that I don't know enough about anything perl6 to know whether
this is a good idea, and if so whether this is the best way to implement the
idea. Someone else knowledgeable will have to comment)
Nicholas Clark
tutorial on submitting patches
this is a little tutorial about submitting patches (should be added to a FAQ, or somewhere where it's handy for people like me that tends to forget everything :-). if there's something missing or incorrect, feel free to let me know: 1. do a diff -u of the file(s) you want to patch (note: Win32 users will probably need -ub) 2. redirect the output to a file (any name will do, .patch extension is conventional) 3. create a new email message 4. set the recipient to: [EMAIL PROTECTED] (note there's no need to CC the mailing list, it will find its way through it) 5. prepend [PATCH] to the subject 6. be very, very informative about what you're doing, both in the subject line and the message body 7. attach the patch file you generated in step 2 (DON'T paste the content in the body, attach the file!) 8. send and wait patiently. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
RE: an aside on compiling speed (was Re: PARROT QUESTIONS: Keyed access)
Nicholas Clark:
# On Sun, Jul 21, 2002 at 11:46:34AM -0700, Scott Walters wrote:
# > Perl 5 runs *awesome* on a 486/25. Java (Kaffe) is completely
# > unusable.
# > AWT windows come up in a matter of *days*, whereas a Tk
# window comes up
# > in about 45 seconds. On a fast computer, these things are
# blurred. The point
# > is, you can thrash your system on a faster computer, but
# register renaming, a
# > large L2 cache, lots of disc bandwidth to thrash with etc
# obscured the fact
# > that you are wasting resources horribly.
#
# perl builds damn fine on a K5/133 with 16M of RAM.
# parrot now takes 4 hours in swap hell to compile the computed
# goto ops.
You can pass Configure a flag to disable computed goto (--cgoto=0), but
that won't help if you still want the functionality.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
an aside on compiling speed (was Re: PARROT QUESTIONS: Keyed access)
On Sun, Jul 21, 2002 at 11:46:34AM -0700, Scott Walters wrote: > Perl 5 runs *awesome* on a 486/25. Java (Kaffe) is completely unusable. > AWT windows come up in a matter of *days*, whereas a Tk window comes up > in about 45 seconds. On a fast computer, these things are blurred. The point > is, you can thrash your system on a faster computer, but register renaming, a > large L2 cache, lots of disc bandwidth to thrash with etc obscured the fact > that you are wasting resources horribly. perl builds damn fine on a K5/133 with 16M of RAM. parrot now takes 4 hours in swap hell to compile the computed goto ops. But that's a different story, and wondering how gcc works isn't the purpose of this list. (No, I'm not going to *buy* a faster machine. The whole point is that this machine was free, and is upgraded with other people's cast-offs. But if anyone can suggest where to prod the code to make it compile faster with no loss of functionality I'll have a prod. I prodded Encode's compiler on 5.7.3, and in addition to going faster on my box, it also went significantly faster on everyone else's sensibly sized machines. But that was optimising perl, whereas computed goto is C.) Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
[perl #15358] [PATCH] Make the Regex engine GC-safe
# New Ticket Created by Angel Faus
# Please include the string: [perl #15358]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=15358 >
This patch apparently makes the rx engine behave well with the GC:
It creates a new pmc class PerlReInfo, that is exactly like
PerlPointer, but with the "mark" method implemented, so the string in
rxinfo gets doesn't get collected.
-àngel
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/31020/25999/42a3c8/safe_rx.diff
diff -urN parrot/classes/perlreinfo.pmc parrot_rx/classes/perlreinfo.pmc
--- parrot/classes/perlreinfo.pmc Thu Jan 1 01:00:00 1970
+++ parrot_rx/classes/perlreinfo.pmc Tue Jul 23 07:18:03 2002
@@ -0,0 +1,137 @@
+/* PerlReInfo.pmc
+ * Copyright: (When this is determined...it will go here)
+ * CVS Info
+ * $Id: perlreinfo.pmc,v 1.1 2002/07/04 18:30:00 mrjoltcola Exp $
+ * Overview:
+ * These are the vtable functions for the PerlReInfo class
+ * It's just a Pointer class, with a mark method added.
+ * Data Structure and Algorithms:
+ * History:
+ * Notes: The actual pointer is in ->data
+ * References:
+ */
+
+#include "parrot/parrot.h"
+#include "parrot/rx.h"
+
+#define POINTER_ERROR internal_exception(PARROT_POINTER_ERROR, "An illegal operation was performed on a Pointer (vtable function at %s line %d).\n", __FILE__, __LINE__);
+
+pmclass PerlReInfo {
+
+void init () {
+SELF->data=NULL;
+SELF->flags=PMC_private_GC_FLAG;
+}
+
+PMC* mark (PMC* tail) {
+ rxinfo *rx = SELF->data;
+ if (rx != NULL) {
+ rx->string->flags |= BUFFER_live_FLAG;
+ }
+ return tail;
+}
+
+void morph (INTVAL type) {
+}
+
+void destroy () {
+}
+
+INTVAL type () {
+return enum_class_Pointer;
+}
+
+STRING* name () {
+return whoami;
+}
+
+PMC* clone () {
+PMC *dest;
+dest = pmc_new(INTERP, enum_class_Pointer);
+dest->data=SELF->data;
+return dest;
+}
+
+INTVAL get_integer () {
+return (INTVAL)SELF->data;
+}
+
+FLOATVAL get_number () {
+return (FLOATVAL)(INTVAL)SELF->data;
+}
+
+STRING* get_string () {
+STRING* ret;
+char *target=mem_sys_allocate(64);
+
+/* XXX Dangerous if you have a 196-bit system or above
+(and if you do, you have too comfortable a life and
+deserve to be tormented by coredumps). */
+sprintf(target, "Pointer=0x%p", SELF->data);
+ret=string_make(interpreter, target, strlen(target), 0, 0, 0);
+
+mem_sys_free(target);
+return ret;
+}
+
+INTVAL get_bool () {
+return (INTVAL)(SELF->data != NULL);
+}
+
+INTVAL is_same (PMC* pmc2) {
+return (INTVAL)(SELF->vtable == pmc2->vtable && SELF->data == pmc2->data);
+}
+
+void set_integer (PMC* value) {
+POINTER_ERROR;
+}
+
+void set_integer_native (INTVAL value) {
+POINTER_ERROR;
+}
+
+void set_integer_bignum (BIGNUM* value) {
+POINTER_ERROR;
+}
+
+void set_integer_same (PMC* value) {
+POINTER_ERROR;
+}
+
+void set_number (PMC* value) {
+POINTER_ERROR;
+}
+
+void set_number_native (FLOATVAL value) {
+POINTER_ERROR;
+}
+
+void set_number_bignum (BIGNUM* value) {
+POINTER_ERROR;
+}
+
+void set_number_same (PMC* value) {
+POINTER_ERROR;
+}
+
+void set_string (PMC* value) {
+POINTER_ERROR;
+}
+
+void set_string_native (STRING* value) {
+POINTER_ERROR;
+}
+
+void set_string_unicode (STRING* value) {
+POINTER_ERROR;
+}
+
+void set_string_other (STRING* value) {
+POINTER_ERROR;
+}
+
+void set_string_same (PMC* value) {
+POINTER_ERROR;
+}
+}
diff -urN parrot/global_setup.c parrot_rx/global_setup.c
--- parrot/global_setup.c Thu Jul 4 20:32:38 2002
+++ parrot_rx/global_setup.c Tue Jul 23 07:17:45 2002
@@ -32,6 +32,7 @@
Parrot_IntQueue_class_init(enum_class_IntQueue);
Parrot_Sub_class_init(enum_class_Sub);
Parrot_Coroutine_class_init(enum_class_Coroutine);
+Parrot_PerlReInfo_class_init(enum_class_PerlReInfo);
/* Now register the names of the PMCs */
diff -urN parrot/include/parrot/pmc.h parrot_rx/include/parrot/pmc.h
--- parrot/include/parrot/pmc.h Thu Jul 18 06:30:42 2002
+++ parrot_rx/include/parrot/pmc.h Tue Jul 23 07:18:39 2002
@@ -1,7 +1,7 @@
/* pmc.h
* Copyright: (When this is determined...it will go here)
* CVS Info
- * $Id: pmc.h,v 1.32 2002/07/18 04:30:42 mongo Exp $
+ * $Id: pmc.h,v 1.31 2002/07/04 18:31:20 mrjoltcola Exp $
* Overview:
* This is the api header for the pmc subsystem
* Data Structure and Algorithms:
@@ -27,6 +27,7 @@
enum_class_Coroutine,
enum_class_Closure,
enum_class_Continuation,
+enum_class_PerlReInfo,
enum_class_max
[perl #15357] Read & write ops in core.ops are broken
# New Ticket Created by Simon Glover # Please include the string: [perl #15357] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=15357 > The file descriptors produced by the open op aren't compatible with the ones required by the read & write ops (the versions in core.ops) so this: open I0, "tempfile" write I0, 1 end simply fails quietly - the open succeeds (provided that tempfile exists), but nothing gets written to the file. Simon
RE: RFC - Hashing PMC's
Dan Sugalski:
# At 5:52 PM +0100 7/22/02, Alberto Manuel Brandão Simões wrote:
# >Dan, can we create this new vtable method? returning an
# integer (long
# >integer)... with name hashValue, or asHash.. or something else.
#
# Yep. Call it id and have it return an INTVAL.
Can we have it return a string instead, and then hash the string?
Strings tend to be able to carry more data--how do you come up with an
integer ID for this?
new Math::BigFloat('3.1415926535897932384626433832795');
While it may not make much of a difference for things like aggregates:
ARRAY=0xDECAF
It'll be quite useful for value types:
Math::BigFloat=3.1415926535897932384626433832795
which often can't be adequately expressed as an integer while still
having different instances of the same value be equivalent.
Beyond that, I would like to specifically request that PMCs *not* hash
themselves. They should return a value that the aggregate hashes. That
makes it much easier to change the hashing algorithm later.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
Re: RFC - Hashing PMC's
On Mon, 22 Jul 2002, Dan Sugalski wrote: > At 5:52 PM +0100 7/22/02, Alberto Manuel Brandão Simões wrote: > >Dan, can we create this new vtable method? returning an integer (long > >integer)... with name hashValue, or asHash.. or something else. > > Yep. Call it id and have it return an INTVAL. Do we want keyed and unkeyed variations? - D <[EMAIL PROTECTED]>
Re: RFC - Hashing PMC's
On Mon, Jul 22, 2002 at 01:12:57PM -0400, Dan Sugalski wrote: > At 5:52 PM +0100 7/22/02, Alberto Manuel Brandão Simões wrote: > >Dan, can we create this new vtable method? returning an integer (long > >integer)... with name hashValue, or asHash.. or something else. > > Yep. Call it id and have it return an INTVAL. INTVALs are signed. Wouldn't it be better to return an unsigned value? Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [PRE-RELEASE] Release of 0.0.7 tomorrow evening
At 12:00 PM 7/22/2002 +0100, Nicholas Clark wrote: >On Mon, Jul 22, 2002 at 11:21:09AM +0100, Graham Barr wrote: > > On Mon, Jul 22, 2002 at 11:14:15AM +0100, Sam Vilain wrote: > > > "Sean O'Rourke" <[EMAIL PROTECTED]> wrote: > > > > > > > languages/perl6/README sort of hides it, but it does say that "If > you have > > > > Perl <= 5.005_03, "$a += 3" may fail to parse." I guess we can upgrade > > > > that to "if you have < 5.6, you lose". > > > > > > I notice that DBI no longer supports Perl releases <5.6. Seems enough > > > people are happy that 5.005 is obsolete. > > > > I am not sure I agree with that. I have been met with a lot of resistance > > from users todo the same with my modules. Some even still want 5.004, > > but thats asking too much IMO. > >In October 2000 I believed that 5.005 maintenance *is* important for the >acceptance of perl6, and I still do now: I agree with this, and until there is a formal discussion and announcement I'm still assuming the minimum for Parrot is 5.005 (_03). At some point we will have bootstrapped Parrot and its languages enough that we can start writing _with_ Parrot, so then all you will need to "build" is the Parrot VM. That'll be fun. :) -Melvin
Perl 6 summary for week ending 2002-07-21
=head1 TITLE
Perl 6 summary for week ending 2002-07-21
=head1 AUTHOR
Leon Brocard <[EMAIL PROTECTED]>
=head1 DETAILS
Another week, another Perl 6 summary. Cunningly this week I have taken
over the summary from Piers in order to make it easier for me to
namecheck myself. It's been a good week too, with more happening in
perl6-internals than perl6-language. So that's where I'll start...
=head2 Parrot 0.0.7
The big news for this week is that DrForr has released Parrot 0.0.7 to
the world (strange that lots of open source projects are releasing
code just before the O'Reilly Open Source conference...). This release
contains a Perl 6 grammar (with small, partial compiler!), functional
subroutine, coroutine and continuation PMCs, global variables, an
intermediate code compiler (imcc), a pure-Perl assembler and working
garbage collection. "The name is Parrot. Percy Parrot."
http:[EMAIL PROTECTED]/msg11090.html
http://www.cpan.org/modules/by-authors/id/J/JG/JGOFF/parrot_0.0.7.tgz
Note that the really cool Perl 6 compiler needs at least Perl 5.6. Oh,
and check out imcc if you haven't looked at it yet.
=head2 Retro Perl
Nicholas Clark stated that "In October 2000 I believed that 5.005
maintenance *is* important for the acceptance of perl6, and I still do
now". A first patch to the preliminary Perl 6 compiler was sent by
Leopold Toetsch to make it work on 5.005_03 and seeing as Chip
Salzenberg has restarted work on a new maintenance release of Perl
5.005 it's probably good for various parts of Parrot to run on retro
perls. Shouldn't be a major problem.
=head2 Parrot docs
One of the big pushes last week was for more documentation inside
Parrot. Writing documentation is always a problem for an open source
project and it hit the wall last week. The good news is that lots of
new documentation has been added to Parrot.
There was some discussion on the nature of documentation. The result
is that inline C documention should write up API details and that
longer discussions (say, the choice of algorithms, how to avoid
overflows in unsigned arithmetic, the pros and cons of differing
hash algorithms) would end up as .dev files inside the docs/dev/
directory, much as PDD07 "Conventions and Guidelines for Perl Source
Code" says. A few more documentation patches followed.
Recently the mailing list and IRC channel have been quite busy and it
seems like the new push for more documentation has attracted new
people. Bonus!
http:[EMAIL PROTECTED]/msg11080.html
=head2 MANIFESTations
The Parrot MANIFEST file tends not to be kept up-to-date with recent
additions. Andy Dougherty produced a patch to do this. Nicholas Clark
asked: "Is CVS flexible enough to let us run a manifest check on each
commit and generate warnings that get sent somewhere useful if it
fails?". Robert Spier answered that it could and with any luck he'll
get it in soon...
=head2 RECALL
Tanton Gibbs posted a patch to clean up a problem with our Copy on
Write strategy. He kindly explained it for me: "The basic problem is
that in perlint.pmc we have something like:
void set_string( PMC* value ) {
CHANGE_TYPE( SELF, PerlString );
SELF->data = value->data
}
In other words implement a COW strategy after being changed into a
PerlString. However, in perlstring.pmc the following is performed:
void set_string( PMC* value ) {
SELF->data = string_copy( INTERP, value->data );
}
The RECALL command automates that so that set_string now looks like:
void set_string( PMC* value ) {
CHANGE_TYPE( pmc, PerlString );
RECALL;
}
Thanks to Tanton for explaining.
=head2 Internals misc
There were also lots of other small patches and discussions. It looks
like the push for this week is to make it easier to add new PMCs to
Parrot.
=head2 Meanwhile, in perl6-language
It was a quiet week in the perl6-language list, which is probably a
good thing as thinking too much about hyper operators makes my head
hurt.
=head2 Hyper operators
There was some discussion on hyper operators this week. It didn't go
anywhere in particular, but discussed lots of syntax. Objections such
as "this code looks ugly!" came up regularly when talking about code
such as:
@solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a);
Luke Palmer pointed out that it might be better expressed as:
for @a; @b; @c; @s is rw ->
$a; $b; $c; $s {
$s = (-$b + sqrt($b**2 - 4*$a*$c)) / (2*$a)
}
Karl Glazebrook explained that PDL keeps everything as objects and
does hyper operator magic without additional syntax. So Perl 6 "@y =
$a ^* @x ^+ @b" happens in PDL with the clearer "$y = $a * $x + $b".
Isn't PDL shiny?
=head1 Whitespace?
Brent Dax noticed that there might be a problem with the regular
expression modifier ":w". The words modifier, according to Apocalypse
5 , "causes an implicit match of whitespace wherever there's literal
whitespace in a pattern". He asked what the following expand to:
m:w/foo [~|bar]/
m:w/[~|bar] foo/
m:w/[~|bar] [^|baz]/
m:
Re: minitutorial on submitting patches
On Mon, Jul 22, 2002 at 06:35:47PM +0100, Leon Brocard wrote: > This is really handy. While writing up the Perl 6 summary I've noticed > that there were a couple of patches which appear to have slipped > though the gapes. Patch authors - if you follow the Parrot patch > procedure we won't forget your patches! My mailbox has squillions (well, probably several dozen) of patches that people sent to the list, but never seemed to conclude with a "thanks applied" or a reason for rejection. I keep meaning to allocate the tuits to check how many of them seem to have been applied, and hence which appear to be lost, forgotten and in need of conclusion. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: pmc RECALL command for preprocessor
Sure,
the basic problem is that in perlint.pmc we have something like:
void set_string( PMC* value ) {
CHANGE_TYPE( SELF, PerlString );
SELF->data = value->data
}
In other words implement a COW strategy after being changed into a
PerlString. However, in perlstring.pmc
the following is performed:
void set_string( PMC* value ) {
SELF->data = string_copy( INTERP, value->data );
}
In other words implement an immediate copy strategy.
So, the problem is that PerlInt is changed into a PerlString, but DOESN"T do
what PerlString does
on the SAME function. Instead, PerlInt should read:
void set_string( PMC* value ) {
CHANGE_TYPE(pmc, PerlString);
SELF->vtable->set_string( value );
}
Thereby just recalling the function after changing the type.
In fact, the PerlUndef class did exactly that.
The RECALL command automates that so that set_string now looks like:
void set_string( PMC* value ) {
CHANGE_TYPE( pmc, PerlString );
RECALL;
}
will be turned into the correct code shown above. By
using the RECALL command we get correct semantics
and no copy and paste bugs.
Does that make sense?
Tanton
[perl #15347] [PATCH] add invoke vtable method
# New Ticket Created by Jonathan Sillito
# Please include the string: [perl #15347]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=15347 >
(apology: I read the nice tutorial on sending patches after I had
already sent this directly to the list so sorry about the duplication).
The attached patch makes the following changes:
- adds invoke op to core.ops (patch does not remove call and callco)
- adds vtable method 'invoke' to vtable.tbl
- adds simple description (stolen from Dan's email) of the method to
docs/pdd/pdd02_vtables.pod
- adds default invoke to classes/default.pmc
- adds an invoke method to classes/sub.pmc
- adds an invoke method to classes/coroutine.pmc
If either the op or the vtable method (or both) should be be named
'call' instead of 'invoke' then let me know and I will rework my stuff
and resubmit the patch.
Next on my list is (next 24 hours or so):
1) remove old call and callco ops (invoke takes care of both) from
core.ops
2) change examples/assembly/sub.pasm and coroutine.pasm to use invoke
instead of call and callco
3) add some tests
After that I will look into adding a Continuation PMC.
--
Jonathan Sillito
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/31006/25983/f9ba73/invoke.patch
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.185
diff -u -r1.185 core.ops
--- core.ops 18 Jul 2002 04:29:39 - 1.185
+++ core.ops 22 Jul 2002 16:52:05 -
@@ -4179,6 +4179,34 @@
goto NEXT();
}
+inline op invoke() {
+ opcode_t *dest;
+ PMC * p = interpreter->ctx.pmc_reg.registers[0];
+
+ /*
+ * FIXME: the stack manipulation code (this push and the pop below) should
+ * be moved to the vtable method. (I think ?)
+ */
+ stack_push(interpreter, &interpreter->ctx.control_stack, expr NEXT(), STACK_ENTRY_DESTINATION, STACK_CLEANUP_NULL);
+
+ dest = (opcode_t *)p->vtable->invoke(interpreter, p);
+ if(dest == 0) {
+/*
+ * invoke returned 0 (means nothing more needs to be done), so just
+ * move on to the next instruction
+ */
+stack_pop(interpreter, &interpreter->ctx.control_stack, NULL, STACK_ENTRY_DESTINATION);
+goto NEXT();
+ }
+ else {
+/*
+ * invoke returned non 0, so it should have returned a and address
+ * so that's our next
+ */
+goto ADDRESS(dest);
+ }
+}
+
inline op call() {
/* This op will be a vtable entry */
struct Parrot_Sub * sub = (struct Parrot_Sub*)interpreter->ctx.pmc_reg..registers[0]->data;
Index: vtable.tbl
===
RCS file: /cvs/public/parrot/vtable.tbl,v
retrieving revision 1.25
diff -u -r1.25 vtable.tbl
--- vtable.tbl 21 Jun 2002 17:22:01 - 1.25
+++ vtable.tbl 22 Jul 2002 16:52:05 -
@@ -325,3 +325,5 @@
STRING* substr_str(INTVAL offset, INTVAL length)
STRING* substr_str_keyed(KEY* key, INTVAL offset, INTVAL length)
STRING* substr_str_keyed_int(INTVAL* key, INTVAL offset, INTVAL length)
+
+INTVAL invoke()
Index: docs/pdds/pdd02_vtables.pod
===
RCS file: /cvs/public/parrot/docs/pdds/pdd02_vtables.pod,v
retrieving revision 1.19
diff -u -r1.19 pdd02_vtables.pod
--- docs/pdds/pdd02_vtables.pod 21 Jun 2002 17:23:37 - 1.19
+++ docs/pdds/pdd02_vtables.pod 22 Jul 2002 16:52:05 -
@@ -1194,6 +1194,18 @@
The key is guaranteed to be not NULL.
+=item INTVAL invoke(INTERP, PMC* self)
+
+For invoking Invoke the given PMC.
+
+It should set up the environment for the sub and return the absolute
+address that the interpreter should jump to. If it returns 0, then
+the interpreter should just take up with the next instruction. (If the
+sub just goes and does its thing and returns, which most C subs will
+do at the moment)
+
+See pdd03_calling_conventions.pod for more details.
+
=back
=cut
Index: classes/default.pmc
===
RCS file: /cvs/public/parrot/classes/default.pmc,v
retrieving revision 1.24
diff -u -r1.24 default.pmc
--- classes/default.pmc 18 Jul 2002 02:19:16 - 1.24
+++ classes/default.pmc 22 Jul 2002 16:52:06 -
@@ -2478,4 +2478,15 @@
INT_TO_KEY(&r_key, *key);
return SELF->vtable->substr_str_keyed(INTERP, SELF, &r_key, offset, length);
}
+
+INTVAL invoke() {
+ /*
+ * FIXME: should be an exception instead:
+ * "Invoking something that can not be invoked" ??
+ */
+
+/* returning 0 should mean the interpretor will move on to the next op */
+return 0;
+
+}
}
Index: classes/sub.pmc
===
RCS file: /cvs/public/parrot/classes/sub.pmc,v
retrieving revision 1.2
diff -u -r1.2 sub.pmc
--- classes/sub.pmc 18 Jul 2002 03:48:33 - 1.2
+++ cl
Re: minitutorial on submitting patches
Aldo Calpini sent the following bits through the ether: > this is a little tutorial about submitting patches > (should be added to a FAQ, or somewhere where it's handy > for people like me that tend to forget everything :-). This is really handy. While writing up the Perl 6 summary I've noticed that there were a couple of patches which appear to have slipped though the gapes. Patch authors - if you follow the Parrot patch procedure we won't forget your patches! Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ There's someone in my head, but its not me
Re: RFC - Hashing PMC's
At 5:52 PM +0100 7/22/02, Alberto Manuel Brandão Simões wrote: >Dan, can we create this new vtable method? returning an integer (long >integer)... with name hashValue, or asHash.. or something else. Yep. Call it id and have it return an INTVAL. >On Mon, 2002-07-22 at 17:07, Leon Brocard wrote: >> Alberto Manuel Brandão Simões sent the following bits through the ether: >> >> > This means one more function to the vtable! >> >> FWIW every object in Java must implement a hashCode method: > > http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#hashCode() -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] add invoke vtable method
On 22 Jul 2002, Jonathan Sillito wrote: > I had a small patch ready for docs/core_ops.pod, but I see that the file > has been removed, so now I am not sure where to put the description of > the invoke op. Oh, no it hasn't... core_ops.pod is autogenerated from core.ops during the build process, so any documentation should just go in the core.ops file. Simon
[PATCH] add invoke vtable method
On Fri, 2002-07-19 at 16:36, Melvin Smith wrote:
> Send me a complete patch and I'll put it in. I might rename the
> op to 'call'.
The attached patch makes the following changes:
- adds invoke op to core.ops (patch does not remove call and callco)
- adds vtable method 'invoke' to vtable.tbl
- adds simple description (stolen from Dan's email) of the method to
docs/pdd/pdd02_vtables.pod
- adds default invoke to classes/default.pmc
- adds an invoke method to classes/sub.pmc
- adds an invoke method to classes/coroutine.pmc
If either the op or the vtable method (or both) should be be named
'call' instead of 'invoke' then let me know and I will rework my stuff
and resubmit the patch.
I had a small patch ready for docs/core_ops.pod, but I see that the file
has been removed, so now I am not sure where to put the description of
the invoke op.
Next on my list is (next 24 hours or so):
1) remove old call and callco ops (invoke takes care of both) from
core.ops
2) change examples/assembly/sub.pasm and coroutine.pasm to use invoke
instead of call and callco
3) add some tests
After that I will look into adding a Continuation PMC.
--
Jonathan Sillito
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.185
diff -u -r1.185 core.ops
--- core.ops 18 Jul 2002 04:29:39 - 1.185
+++ core.ops 22 Jul 2002 16:52:05 -
@@ -4179,6 +4179,34 @@
goto NEXT();
}
+inline op invoke() {
+ opcode_t *dest;
+ PMC * p = interpreter->ctx.pmc_reg.registers[0];
+
+ /*
+ * FIXME: the stack manipulation code (this push and the pop below) should
+ * be moved to the vtable method. (I think ?)
+ */
+ stack_push(interpreter, &interpreter->ctx.control_stack, expr NEXT(), STACK_ENTRY_DESTINATION, STACK_CLEANUP_NULL);
+
+ dest = (opcode_t *)p->vtable->invoke(interpreter, p);
+ if(dest == 0) {
+/*
+ * invoke returned 0 (means nothing more needs to be done), so just
+ * move on to the next instruction
+ */
+stack_pop(interpreter, &interpreter->ctx.control_stack, NULL, STACK_ENTRY_DESTINATION);
+goto NEXT();
+ }
+ else {
+/*
+ * invoke returned non 0, so it should have returned a and address
+ * so that's our next
+ */
+goto ADDRESS(dest);
+ }
+}
+
inline op call() {
/* This op will be a vtable entry */
struct Parrot_Sub * sub = (struct Parrot_Sub*)interpreter->ctx.pmc_reg..registers[0]->data;
Index: vtable.tbl
===
RCS file: /cvs/public/parrot/vtable.tbl,v
retrieving revision 1.25
diff -u -r1.25 vtable.tbl
--- vtable.tbl 21 Jun 2002 17:22:01 - 1.25
+++ vtable.tbl 22 Jul 2002 16:52:05 -
@@ -325,3 +325,5 @@
STRING* substr_str(INTVAL offset, INTVAL length)
STRING* substr_str_keyed(KEY* key, INTVAL offset, INTVAL length)
STRING* substr_str_keyed_int(INTVAL* key, INTVAL offset, INTVAL length)
+
+INTVAL invoke()
Index: docs/pdds/pdd02_vtables.pod
===
RCS file: /cvs/public/parrot/docs/pdds/pdd02_vtables.pod,v
retrieving revision 1.19
diff -u -r1.19 pdd02_vtables.pod
--- docs/pdds/pdd02_vtables.pod 21 Jun 2002 17:23:37 - 1.19
+++ docs/pdds/pdd02_vtables.pod 22 Jul 2002 16:52:05 -
@@ -1194,6 +1194,18 @@
The key is guaranteed to be not NULL.
+=item INTVAL invoke(INTERP, PMC* self)
+
+For invoking Invoke the given PMC.
+
+It should set up the environment for the sub and return the absolute
+address that the interpreter should jump to. If it returns 0, then
+the interpreter should just take up with the next instruction. (If the
+sub just goes and does its thing and returns, which most C subs will
+do at the moment)
+
+See pdd03_calling_conventions.pod for more details.
+
=back
=cut
Index: classes/default.pmc
===
RCS file: /cvs/public/parrot/classes/default.pmc,v
retrieving revision 1.24
diff -u -r1.24 default.pmc
--- classes/default.pmc 18 Jul 2002 02:19:16 - 1.24
+++ classes/default.pmc 22 Jul 2002 16:52:06 -
@@ -2478,4 +2478,15 @@
INT_TO_KEY(&r_key, *key);
return SELF->vtable->substr_str_keyed(INTERP, SELF, &r_key, offset, length);
}
+
+INTVAL invoke() {
+ /*
+ * FIXME: should be an exception instead:
+ * "Invoking something that can not be invoked" ??
+ */
+
+/* returning 0 should mean the interpretor will move on to the next op */
+return 0;
+
+}
}
Index: classes/sub.pmc
===
RCS file: /cvs/public/parrot/classes/sub.pmc,v
retrieving revision 1.2
diff -u -r1.2 sub.pmc
--- classes/sub.pmc 18 Jul 2002 03:48:33 - 1.2
+++ classes/sub.pmc 22 Jul 2002 16:52:06 -
@@ -325,4 +325,9 @@
void repeat_same (PMC * value, PMC* dest) {
}
*/
+
+ INTVAL invoke () {
+ /* return address that the interpreter should jump t
Re: RFC - Hashing PMC's
Dan, can we create this new vtable method? returning an integer (long integer)... with name hashValue, or asHash.. or something else. Alberto On Mon, 2002-07-22 at 17:07, Leon Brocard wrote: > Alberto Manuel Brandão Simões sent the following bits through the ether: > > > This means one more function to the vtable! > > FWIW every object in Java must implement a hashCode method: > http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#hashCode() > > Leon > -- > Leon Brocard.http://www.astray.com/ > scribot.http://www.scribot.com/ > > If I were you, who'd be me? -- Alberto Manuel B. Simoes Departamento de Informática - Universidade do Minho http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net
[perl #15345] [PATCH] Generating assemble.pl
# New Ticket Created by Alberto Manuel Brandão Simões
# Please include the string: [perl #15345]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=15345 >
A simple way to generate assemble.pl constants initializaiton using
include/parrot/pmc.h
In attach, diff file and config/gen/enum.pl.
If accepted, it is needed to call enum.pl from somewhere (at the root
parrot distribution).
Regards,
Alberto
--
Alberto Manuel B. Simoes
Departamento de Informática - Universidade do Minho
http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/30988/25974/8eaf7c/diff_file2
-- attachment 2 --
url: http://rt.perl.org/rt2/attach/30988/25975/877c67/enum.pl
Index: assemble.pl
===
RCS file: /cvs/public/parrot/assemble.pl,v
retrieving revision 1.82
diff -u -r1.82 assemble.pl
--- assemble.pl 18 Jul 2002 02:13:27 - 1.82
+++ assemble.pl 22 Jul 2002 16:44:34 -
@@ -127,6 +127,7 @@
# XXX Must be generated from the enum in include/parrot/pmc.h
#
bless $self,$class;
+ # Constants initilization
$self->{constants}{Array} = 0;
$self->{constants}{PerlUndef} = 1;
$self->{constants}{PerlInt} = 2;
#! perl
# read that enum from 'include/parrot/pmc.h'
open F, ") {
chomp;
push @list, $1 if (m!enum_class_(\w+),!);
}
close F;
# Generate the string...
my $string = "";
my $i = 0;
for (@list) {
$string.= " \$self->{constants}{$_} = $i;\n";
$i ++;
}
# open and read 'assemble.pl'
open I, "assemble.pl_" or die "Cannot open file 'assemble.pl_' for writting";
while() {
print O;
if (m!# Constants initilization!) {
while() {
last if m!\$self;!;
}
print O $string;
print O " \$self;\n";
}
}
close O;
close I;
# Move assemble.pl_ to assemble.pl
# if anybody knows a simple way, go ahead
open I, "assemble.pl" or die "Cannot open file 'assemble.pl' for writting";
while() { print O }
close O;
close I;
unlink "assemble.pl_";
Re: pmc RECALL command for preprocessor
Tanton Gibbs sent the following bits through the ether: > I implemented a RECALL preprocessor directive for the pmc classes. > ... > Thus ensuring that the correct semantics always occur. I'm afraid I don't quite understand what RECALL is supposed to do. Can you explain it in a little more detail? Cheers, Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ This sentence no verb
[perl #15340] [PATCH] Boolean PMC
# New Ticket Created by Alberto Manuel Brandão Simões
# Please include the string: [perl #15340]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=15340 >
While it can be thought as too simple and stupid PMC, it can be very
usefull. (At least for my project it would be).
Still a simple implementation based on PerlInt. Stores 0 for false, 1
for true. Assignment of other values is available in the same way as
Perl trueness.
Still only one test.
In Attach, boolean.t (test file), boolean.pmc (PMC File) and diff for
other files.
Opefully, this can be accepted ;)
Alberto
--
Alberto Manuel B. Simoes
Departamento de Informática - Universidade do Minho
http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/30983/25965/ac3f25/diff_file
-- attachment 2 --
url: http://rt.perl.org/rt2/attach/30983/25966/8bc81e/boolean.t
-- attachment 3 --
url: http://rt.perl.org/rt2/attach/30983/25967/dcaea8/boolean.pmc
Index: assemble.pl
===
RCS file: /cvs/public/parrot/assemble.pl,v
retrieving revision 1.82
diff -u -r1.82 assemble.pl
--- assemble.pl 18 Jul 2002 02:13:27 - 1.82
+++ assemble.pl 22 Jul 2002 16:16:51 -
@@ -138,6 +138,7 @@
$self->{constants}{IntQueue} = 8;
$self->{constants}{Sub} = 9;
$self->{constants}{Coroutine} = 10;
+ $self->{constants}{Boolean} = 11;
$self;
}
Index: global_setup.c
===
RCS file: /cvs/public/parrot/global_setup.c,v
retrieving revision 1.28
diff -u -r1.28 global_setup.c
--- global_setup.c 4 Jul 2002 18:32:38 - 1.28
+++ global_setup.c 22 Jul 2002 16:16:51 -
@@ -33,6 +33,8 @@
Parrot_Sub_class_init(enum_class_Sub);
Parrot_Coroutine_class_init(enum_class_Coroutine);
+Parrot_Boolean_class_init(enum_class_Boolean);
+
/* Now register the names of the PMCs */
/* We need a key to work with */
@@ -112,6 +114,12 @@
key->atom.type = enum_key_string;
Parrot_base_classname_hash->vtable->set_integer_keyed(NULL,
Parrot_base_classname_hash,
key, enum_class_Coroutine);
+
+key->atom.val.string_val = (STRING*)
+Parrot_base_vtables[enum_class_Boolean].name(NULL, NULL);
+key->atom.type = enum_key_string;
+Parrot_base_classname_hash->vtable->set_integer_keyed(NULL,
+ Parrot_base_classname_hash,
+key, enum_class_Boolean);
}
Index: include/parrot/pmc.h
===
RCS file: /cvs/public/parrot/include/parrot/pmc.h,v
retrieving revision 1.32
diff -u -r1.32 pmc.h
--- include/parrot/pmc.h18 Jul 2002 04:30:42 - 1.32
+++ include/parrot/pmc.h22 Jul 2002 16:16:51 -
@@ -25,8 +25,12 @@
enum_class_IntQueue,
enum_class_Sub,
enum_class_Coroutine,
+
+enum_class_Boolean,
+
enum_class_Closure,
enum_class_Continuation,
+
enum_class_max = 100
};
VAR_SCOPE VTABLE Parrot_base_vtables[enum_class_max];
#! perl -w
use Parrot::Test tests => 1;
use Test::More;
output_is(<<'CODE', <<'OUTPUT', "Initialization");
new P0,.Boolean
set I0, P0
eq I0,0,OK_1
print "not "
OK_1: print "ok 1\n"
end
CODE
ok 1
OUTPUT
1;
__END__
output_is(<<'CODE', <<'OUTPUT', "Setting first element");
new P0, .Array
set P0, 1
set P0[0],-7
set I0,P0[0]
eq I0,-7,OK_1
print "not "
OK_1: print "ok 1\n"
set P0[0],3.7
set N0,P0[0]
eq N0,3.7,OK_2
print "not "
OK_2: print "ok 2\n"
set P0[0],"Buckaroo"
set S0,P0[0]
eq S0,"Buckaroo",OK_3
print "not "
OK_3: print "ok 3\n"
end
CODE
ok 1
ok 2
ok 3
OUTPUT
output_is(<<'CODE', <<'OUTPUT', "Setting second element");
new P0, .Array
set P0, 2
set P0[1], -7
set I0, P0[1]
eq I0,-7,OK_1
print "not "
OK_1: print "ok 1\n"
set P0[1], 3.7
set N0, P0[1]
eq N0,3.7,OK_2
print "not "
OK_2: print "ok 2\n"
set P0[1],"Buckaroo"
set S0, P0[1]
eq S0,"Buckaroo",OK_3
print "not "
OK_3: print "ok 3\n"
end
CODE
ok 1
ok 2
ok 3
OUTPUT
# TODO: Rewrite these properly when we have exceptions
output_is(<<'CODE', <<'OUTPUT', "Setting out-of-bounds elements");
new P0, .Array
set P0, 1
set P0[1], -7
end
CODE
Array element out of bounds!
OUTPUT
output_is(<<'CODE', <<'OUTPUT', "Getting out-of-bounds elements");
new P0, .Array
set P0, 1
set I0, P0[1]
end
CODE
Array element out of bounds!
OUTPUT
1;
/* boolean.pmc
* Copyright: (When this is determined...it will go here)
* CVS Info
* $Id$
* Overview:
* These are the vtable functions for the Boolean base class
* Data
Re: RFC - Hashing PMC's
Alberto Manuel Brandão Simões sent the following bits through the ether: > This means one more function to the vtable! FWIW every object in Java must implement a hashCode method: http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#hashCode() Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ If I were you, who'd be me?
minitutorial on submitting patches
this is a little tutorial about submitting patches (should be added to a FAQ, or somewhere where it's handy for people like me that tend to forget everything :-). if there's something missing or incorrect, feel free to let me know: 1. do a diff -u of the file(s) you want to patch (note: Win32 users will probably need -ub) 2. redirect the output to a file (any name will do, .patch extension is conventional) 3. create a new email message 4. set the recipient to: [EMAIL PROTECTED] (note there's no need to CC the mailing list, it will find its way through it) 5. prepend [PATCH] to the subject 6. be very, very informative about what you're doing, both in the subject line and the message body 7. attach the patch file you generated in step 2 (DON'T paste the content in the body, attach the file!) 8. send and wait patiently. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: PARROT QUESTIONS: Keyed access
--- Leon Brocard <[EMAIL PROTECTED]> wrote: > Ashley Winters sent the following bits through the > ether: > > > Err, is this a bad time to ask where ParrotTuple > is? :) > > I think ParrotTuple would make a great first project > for anyone who wants to learn more about PMCs. >Any takers? ;-) Sure, I'm up for it! I'm currently working on a Hyper Array PMC (and it took me quite a while to get it working, even with all the docs :), but I'd be glad to work on something useful to the community for a change. I may have some questions about the proper behaviour for a few things once I start working out the details, but if it's fine with everyone else I'll be glad to do this! Stephen __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: RFC - Hashing PMC's
On Mon, 2002-07-22 at 14:05, Simon Cozens wrote: > Alberto writes: > > Finally, we need to hash PMC's. While I don't know what hash function > > we should use > > Nor can you know, in the general case. Let PMCs hash themselves. This means one more function to the vtable! The value returned by the object hash method should be modified accordingly with it's type, I think Alberto -- Alberto Manuel B. Simoes Departamento de Informática - Universidade do Minho http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net
Re: RFC - Hashing PMC's
Alberto writes: > Finally, we need to hash PMC's. While I don't know what hash function > we should use Nor can you know, in the general case. Let PMCs hash themselves. -- 4.2BSD may not be a complete disaster, but it does a good job of emulating one.
Re: [PRE-RELEASE] Release of 0.0.7 tomorrow evening
On Mon, Jul 22, 2002 at 11:21:09AM +0100, Graham Barr wrote: > On Mon, Jul 22, 2002 at 11:14:15AM +0100, Sam Vilain wrote: > > "Sean O'Rourke" <[EMAIL PROTECTED]> wrote: > > > > > languages/perl6/README sort of hides it, but it does say that "If you have > > > Perl <= 5.005_03, "$a += 3" may fail to parse." I guess we can upgrade > > > that to "if you have < 5.6, you lose". > > > > I notice that DBI no longer supports Perl releases <5.6. Seems enough > > people are happy that 5.005 is obsolete. > > I am not sure I agree with that. I have been met with a lot of resistance > from users todo the same with my modules. Some even still want 5.004, > but thats asking too much IMO. Chip Salzenberg has (re)started work on a new maintenance release of 5.005 (ie 5.005_04). I think Tim Bunce said that the problem with DBI still supporting 5.005 was that 5.005_03 refuses to build on some current versions of OSes (such as the current stable FreeBSD). I think he implied (on p5p - check the archives) that if 5.005 maintenance made 5.005 work better, then he'd reconsider. In October 2000 I believed that 5.005 maintenance *is* important for the acceptance of perl6, and I still do now: http:[EMAIL PROTECTED]/msg00977.html Nicholas Clark
Re: [PRE-RELEASE] Release of 0.0.7 tomorrow evening
"Sean O'Rourke" <[EMAIL PROTECTED]> wrote: > languages/perl6/README sort of hides it, but it does say that "If you have > Perl <= 5.005_03, "$a += 3" may fail to parse." I guess we can upgrade > that to "if you have < 5.6, you lose". I notice that DBI no longer supports Perl releases <5.6. Seems enough people are happy that 5.005 is obsolete. -- Sam Vilain, [EMAIL PROTECTED] WWW: http://sam.vilain.net/ 7D74 2A09 B2D3 C30F F78E GPG: http://sam.vilain.net/sam.asc 278A A425 30A9 05B5 2F13 I regret to say that we of the FBI are powerless to act in cases of oral-genital intimacy, unless it has in some way obstructed interstate commerce. J EDGAR HOOVER
Re: PARROT QUESTIONS: Keyed access
Leon Brocard wrote: > I think ParrotTuple would make a great first project for anyone > who wants to learn more about PMCs. It will also be fairly simple > and small, so if lots of docs were also included it would make > an ideal PMC to learn from in future. Any takers? ;-) me, time permitting :-) should it be ParrotTuple.pmc or just tuple.pmc? and if this is going to be ParrotTuple.pmc, are we going to rename array.pmc in ParrotArray.pmc etc. etc.? I prefer just tuple.pmc. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: [perl #15335] [PATCH] little change to debug.c (print)
Applied, thanks. Daniel Grunblatt. On Mon, 22 Jul 2002, Aldo Calpini wrote: > # New Ticket Created by Aldo Calpini > # Please include the string: [perl #15335] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=15335 > > > > > this little patch changes the 'print' debugger > command on PMC registers, so that it prints > the PMC class next to the register number. > > eg. before the patch: > > (pdb) print p 0 > PMC Registers: >0 = > > after the patch: > > (pdb) print p 0 > PMC Registers: >0 = [PerlArray] > > > cheers, > Aldo > > __END__ > $_=q,just perl,,s, , another ,,s,$, hacker,,print; > > -- attachment 1 -- > url: http://rt.perl.org/rt2/attach/30967/25957/89edff/debug_print_pmc.patch > >
[perl #15335] [PATCH] little change to debug.c (print)
# New Ticket Created by Aldo Calpini # Please include the string: [perl #15335] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=15335 > this little patch changes the 'print' debugger command on PMC registers, so that it prints the PMC class next to the register number. eg. before the patch: (pdb) print p 0 PMC Registers: 0 = after the patch: (pdb) print p 0 PMC Registers: 0 = [PerlArray] cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print; -- attachment 1 -- url: http://rt.perl.org/rt2/attach/30967/25957/89edff/debug_print_pmc.patch debug_print_pmc.patch Description: debug_print_pmc.patch
Re: [PRE-RELEASE] Release of 0.0.7 tomorrow evening
Nicholas Clark wrote: > In October 2000 I believed that 5.005 maintenance *is* important for the > acceptance of perl6, and I still do now: Some minutes ago I sent a first patch to Sean, to make it work on 5.005_03. One reason of failure is shown by the following snippet: $ cat t1 #!/usr/bin/perl -wl use strict; my $r = qr( [-+] )ox; my $t = '+1'; print $t =~ / \A(?-imxs:$r) /ox ? "yes" : "no"; print $t =~ / \A(?-ims:$r) /ox ? "yes" : "no"; $ perl t1 no yes The output is yes/yes on 5.6.1. (Code similar to the above matching is generated in Perlgrammar.pm, but there should be a workaround by giving up some readability) leo
Re: PARROT QUESTIONS: Keyed access
Ashley Winters sent the following bits through the ether: > Err, is this a bad time to ask where ParrotTuple is? :) I think ParrotTuple would make a great first project for anyone who wants to learn more about PMCs. It will also be fairly simple and small, so if lots of docs were also included it would make an ideal PMC to learn from in future. Any takers? ;-) Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ If this were an actual tagline, it would be funny
[PATCH] [perl #15267] Re: [perl fix rot in pxs and Qt example broken
On Sun, Jul 21, 2002 at 02:05:42PM +, s. payrard @ wanadoo. fr wrote:
> # New Ticket Created by [EMAIL PROTECTED]
> # Please include the string: [perl #15267]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=15267 >
>
>
> This seems a symptom of a bigger problem.
> include/parrot/interpreter.h has the following typedef:
>
> typedef struct Parrot_Interp *Parrot_Interp;
>
> It works in C but breaks in C++ (using g++-3.1) as demonstrated
> by the breakage of example/pxs:
>
>
> /../include/parrot/interpreter.h:32: conflicting types for `typedef struct
>Parrot_Interp*Parrot_Interp'
> /../include/parrot/interpreter.h:30: previous declaration as `struct
>Parrot_Interp'
> In file included from ../../include/parrot/interpreter.h:44,
> from ../../include/parrot/parrot.h:114,
> from ../../include/parrot/pxs.h:14,
> from PQt.C:15:
>
> Also, the modifs of pxs.h form CVS 1.2 to 1.3 (replacing
> Parrot_Interp_t by parrot_interp_t) also does not fix anything
> but confuses a little more the problem.
>
> in my opinion "typedef struct Parrot_Interp *Parrot_Interp;" is not
> only too cute, it is wrong in the light of C++
I want to play with Qt from parrot and started from the example in ./example/pxs.
It had not followed the flux of parrot. Problems were going beyond those
I described.
So I fixed it.
Tested with perl 5.008 on linux.
>
> --
> stef
>
--
stef
# This is a patch for parrot.old to update it to parrot
#
# To apply this patch:
# STEP 1: Chdir to the source directory.
# STEP 2: Run the 'applypatch' program with this patch file as input.
#
# If you do not have 'applypatch', it is part of the 'makepatch' package
# that you can fetch from the Comprehensive Perl Archive Network:
# http://www.perl.com/CPAN/authors/Johan_Vromans/makepatch-x.y.tar.gz
# In the above URL, 'x' should be 2 or higher.
#
# To apply this patch without the use of 'applypatch':
# STEP 1: Chdir to the source directory.
# If you have a decent Bourne-type shell:
# STEP 2: Run the shell with this file as input.
# If you don't have such a shell, you may need to manually create
# the files as shown below.
# STEP 3: Run the 'patch' program with this file as input.
#
# These are the commands needed to create/delete files/directories:
#
touch 'examples/pxs/makefile'
chmod 0644 'examples/pxs/makefile'
#
# This command terminates the shell and need not be executed manually.
exit
#
End of Preamble
Patch data follows
diff -c 'parrot.old/MANIFEST' 'parrot/MANIFEST'
Index: ./MANIFEST
*** ./MANIFEST Fri Jul 19 03:16:40 2002
--- ./MANIFEST Mon Jul 22 14:38:33 2002
***
*** 170,175
--- 170,176
examples/mops/mops.py
examples/mops/mops.rb
examples/mops/mops.scheme
+ examples/pxs/makefile
examples/pxs/PQt.C
examples/pxs/QtHelloWorld.pasm
exceptions.c
diff -c 'parrot.old/config/gen/makefiles/root.in' 'parrot/config/gen/makefiles/root.in'
Index: ./config/gen/makefiles/root.in
*** ./config/gen/makefiles/root.in Mon Jul 22 09:13:17 2002
--- ./config/gen/makefiles/root.in Mon Jul 22 14:30:48 2002
***
*** 68,74
$(INC)/pmc.h $(INC)/key.h $(INC)/hash.h $(INC)/resources.h $(INC)/platform.h ${cg_h}
\
$(INC)/interp_guts.h ${jit_h} $(INC)/rx.h $(INC)/rxstacks.h \
$(INC)/embed.h $(INC)/warnings.h $(INC)/misc.h $(INC)/debug.h $(INC)/pmc.h \
! $(INC)/key.h $(INC)/hash.h $(INC)/smallobject.h $(INC)/headers.h $(INC)/dod.h
ALL_H_FILES = $(GENERAL_H_FILES)
--- 68,74
$(INC)/pmc.h $(INC)/key.h $(INC)/hash.h $(INC)/resources.h $(INC)/platform.h ${cg_h}
\
$(INC)/interp_guts.h ${jit_h} $(INC)/rx.h $(INC)/rxstacks.h \
$(INC)/embed.h $(INC)/warnings.h $(INC)/misc.h $(INC)/debug.h $(INC)/pmc.h \
! $(INC)/key.h $(INC)/hash.h $(INC)/smallobject.h $(INC)/headers.h $(INC)/dod.h
$(INC)/pxs.h
ALL_H_FILES = $(GENERAL_H_FILES)
***
*** 92,98
platform$(O) ${jit_o} resources$(O) rx$(O)
rxstacks$(O) \
embed$(O) warnings$(O) misc$(O) ${cg_o} \
packout$(O) byteorder$(O) debug$(O) smallobject$(O) \
!headers$(O) dod$(O)
O_FILES = $(INTERP_O_FILES) \
$(IO_O_FILES) \
--- 92,98
platform$(O) ${jit_o} resources$(O) rx$(O)
rxstacks$(O) \
embed$(O) warnings$(O) misc$(O) ${cg_o} \
packout$(O) byteorder$(O) debug$(O) smallobject$(O) \
!headers$(O) dod$(O) pxs$(O)
O_FILES = $(INTERP_O_FILES) \
$(IO_O_FILES) \
diff -c 'parrot.old/examples/pxs/PQt.C' 'parrot/examples/pxs/PQt.C'
Index: ./examples/pxs/PQt.C
*** ./examples/pxs/PQt.CSun Jun 2 04:50:49 2002
--- ./examples/pxs/PQt.CMon Jul 22 10:20:53 2002
***
[perl #15334] PATCH: Little imcc patch
# New Ticket Created by Leon Brocard
# Please include the string: [perl #15334]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=15334 >
The following patch makes imcc use the saveall and restoreall
ops (now that they're implemented).
Leon, at oscon
--
Leon Brocard.http://www.astray.com/
scribot.http://www.scribot.com/
.. #include
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/30965/25951/866b55/imcc.y.patch
Index: imcc.y
===
RCS file: /cvs/public/parrot/languages/imcc/imcc.y,v
retrieving revision 1.8
diff -u -r1.8 imcc.y
--- imcc.y 11 Jul 2002 21:09:12 - 1.8
+++ imcc.y 22 Jul 2002 14:29:11 -
@@ -168,12 +168,12 @@
}
SymReg * iSAVEALL() {
-emitb(mk_instruction("pushs\npushi\npushn\npushp", NULL, NULL, NULL, NULL, 0));
+emitb(mk_instruction("saveall", NULL, NULL, NULL, NULL, 0));
return 0;
}
SymReg * iRESTOREALL() {
-emitb(mk_instruction("popp\npopn\npopi\npops", NULL, NULL, NULL, NULL, 0));
+emitb(mk_instruction("restoreall", NULL, NULL, NULL, NULL, 0));
return 0;
}
Some documentation updates
Hi On http://natura.di.uminho.pt/~albie/parrot/ I have some documents I've been working in about PMC's: * Array PMC * Perl Array PMC * Perl Hash PMC * Perl String PMC * Writing a PMC Regarding the first four, I would appreciate PMC programmers to read them and give ideas/suggestions. In relation of the last one, check if I'm not writting stupid things :) Hugs Alberto -- Alberto Manuel B. Simoes Departamento de Informática - Universidade do Minho http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net
RFC - Hashing PMC's
My last mail didn't have many answers, maybe this one makes people think and give ideas... RFC: Hashing PMC's Current PerlHash implementation accepts PMC's as keys, as long as they can be transformed into Strings. While this can be enough for many cases, having a very complex PMC as key will lead to a recursive String generation. A hash table implementation can be easily done from any type to any other type as long as we can compare that type, and we can generate some hash from it. For strings, there are a very wide range of hash functions (from simple ones to more complicated ones, like MD5). So, if we want a hash to accept PMC as keys, we have to compare and hash them. Comparing is already possible as long as PMC classes implement the correspondent vtable method. Finally, we need to hash PMC's. While I don't know what hash function we should use, I can write some goals for it: 1) Different PMC types should lead to different hash values; 2) Hash values should be calculated recursively, within the PMC nested datatypes; 3) Be quick; Please, send ideas replying to this e-mail (directly to me or to the list). Thanks, Alberto -- Alberto Manuel B. Simoes Departamento de Informática - Universidade do Minho http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net
Re: [PRE-RELEASE] Release of 0.0.7 tomorrow evening
On Mon, Jul 22, 2002 at 11:14:15AM +0100, Sam Vilain wrote: > "Sean O'Rourke" <[EMAIL PROTECTED]> wrote: > > > languages/perl6/README sort of hides it, but it does say that "If you have > > Perl <= 5.005_03, "$a += 3" may fail to parse." I guess we can upgrade > > that to "if you have < 5.6, you lose". > > I notice that DBI no longer supports Perl releases <5.6. Seems enough > people are happy that 5.005 is obsolete. I am not sure I agree with that. I have been met with a lot of resistance from users todo the same with my modules. Some even still want 5.004, but thats asking too much IMO. Graham.
Re: PARROT QUESTIONS: Keyed access: PROPOSAL
On Mon, 22 Jul 2002, Angel Faus wrote:
> In my opinion, there are actually two different things to dicuss:
>
> - keyed opcodes
> - keyed methods on the PMC vtable
>
...
>
> Keyed opcodes can stay in the interest of code density.
>
> >
> > No. Keyed access for all methods stays. You're forgetting one very
> > important case, the one where the contents of an aggregate isn't a
> > PMC. This scheme would then require the aggregate PMC to construct
> > fake PMCs to do operations on. Bad, definitely bad.
>
> Is really so bad? As long that what is ultimately stored in the
> aggregate is one of our base types (pmc, int, string, float), the
> opcode shouldn't need to build the fake PMC.
>
> Or, ¿are you talking about multi-dimensional PMCs? I don't see why
> these should need to build fake PMCs: you just call the get_keyed
> method, and it will do the Right Thing (probably getting the value
> directly, maybe propagating a portion of the key to a inner PMC).
By the time you told Parrot what you've actually returned, you might
as well have just returned it in the form of a PMC.
With fetching PMCs its easy. Atomic values are harder. A few things
spring to mind [for keyed access to atomic data items]:
1. Returning a reference. This would work, since the atomic types
have no active behavior. This would require all PMCs that store
things to work in terms of references in addition to values, and
would create another varient of ops [I could be wrong].
2. Load/Store. This would require a fetch, the operation performed,
then a store. Twice as many traversals would be required in the
case of:
%ref->{$x;$y;$z}++;
However,
print %ref->{$x;$y;$z}, "\n";
%ref->{$x;$y;$z} = 100;
...would both be unaffected, since only a fetch or store would be required.
3. Very light wrapper PMCs. A special int, num, string wrapper could
be created on startup for each operand position, and persist throughout
the life of the interpreter, being reused each time a keyed atomic value
is addressed. Keeping a finate dedicated pool eliminates overhead of
calculating which to use, adding and removing to free lists, etc.
This would require a mere 3*3=9 dedicated wrappers.
This would seriously damage the value of the primitive register pools
and place undo strain on the PMC registers. I'm just being thorough ;)
4. Establish an interpreter-global register ("Foo") that contains information
(an enum) about which operation is to be performed, and a UnionVal
describing the other operand.
This would require Parrot to look up one operand - either from the
register file directly or via get_pmc_*, populate the single, fixed
UnionVal with its information, then invoke do_operation_keyed on
the other operand. When the 2nd operand was able to eventually track
down the value in question, it could look to "Foo" to discover
which operation to perform, and with which other value, and implement
an internal switch() on the operation to be performed.
This would allow for 4 get_* methods, 4 set_* methods, and one do_
method.
The overhead that this would create is merely the switch() at the
end of the second resolution, which is negligable compared to the
handfull of method calls already being performed.
1 seems to be the fastest while being elegant and flexible. 4 follows
closely, having the benefit of not generating additional op permutations
but being a bit more contrived. 2 certainly has elegance on its side
but would actually cost significantly more in a frequent case. 3
is not elegant or fast but makes a case for "everything is an object"
not being quite so bad.
>
> As I said, there should no be any speed cost at all, and a significant
> improvement on code size. But this is only an opinion. I am willing
> to submit a benchmarking patch if it has some interest.
The reason I replied to this was not to rant [ranters anonymous?] but
to express interest in this comparison. I'd like to see that. With my
8k instruction cache, any refactoring is welcome =)
>
> Best,
>
> -àngel
>
Cheers,
-scott
[perl #15317] [PATCH] Recursive keyed lookups for array.pmc
# New Ticket Created by Scott Walters
# Please include the string: [perl #15317]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=15317 >
When a KEY * key datastructure is passed to a keyed method in array.pmc,
and key->next is true...:
array.pmc will recurse into the keyed lookup method of the PMC that it
contains, passing it key->next.
This implements the recursive indexing behavior as described in PDD08.
-scott
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/30940/25927/407316/array.pmc.diff
Index: parrot/classes/array.pmc
===
RCS file: /cvs/public/parrot/classes/array.pmc,v
retrieving revision 1.27
diff -u -r1.27 array.pmc
--- parrot/classes/array.pmc13 Jul 2002 17:07:25 - 1.27
+++ parrot/classes/array.pmc22 Jul 2002 08:22:39 -
@@ -162,7 +162,13 @@
}
value = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-return value->vtable->get_integer(INTERP, value);
+
+if(key->next != NULL) {
+return value->vtable->get_integer_keyed(INTERP, value, key->next);
+}
+else {
+return value->vtable->get_integer(INTERP, value);
+}
}
INTVAL get_integer_keyed_int (INTVAL* key) {
@@ -204,7 +210,13 @@
}
value = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-return value->vtable->get_number(INTERP, value);
+
+if(key->next != NULL) {
+return value->vtable->get_number_keyed(INTERP, value, key->next);
+}
+else {
+return value->vtable->get_number(INTERP, value);
+}
}
FLOATVAL get_number_keyed_int (INTVAL* key) {
@@ -247,7 +259,13 @@
}
value = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-return value->vtable->get_bignum(INTERP, value);
+
+if(key->next != NULL) {
+return value->vtable->get_bignum_keyed(INTERP, value, key->next);
+}
+else {
+return value->vtable->get_bignum(INTERP, value);
+}
}
BIGNUM* get_bignum_keyed_int (INTVAL* key) {
@@ -289,7 +307,13 @@
}
value = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-return value->vtable->get_string(INTERP, value);
+
+if(key->next != NULL) {
+return value->vtable->get_string_keyed(INTERP, value, key->next);
+}
+else {
+return value->vtable->get_string(INTERP, value);
+}
}
STRING* get_string_keyed_int (INTVAL * key) {
@@ -331,7 +355,13 @@
}
value = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-return value->vtable->get_bool(INTERP, value);
+
+if(key->next != NULL) {
+return value->vtable->get_bool_keyed(INTERP, value, key->next);
+}
+else {
+return value->vtable->get_bool(INTERP, value);
+}
}
INTVAL get_bool_keyed_int (INTVAL* key) {
@@ -374,7 +404,13 @@
}
value = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-return value->vtable->elements(INTERP, value);
+
+if(key->next != NULL) {
+return value->vtable->elements_keyed(INTERP, value, key->next);
+}
+else {
+return value->vtable->elements(INTERP, value);
+}
}
INTVAL elements_keyed_int (INTVAL* key) {
@@ -412,8 +448,14 @@
}
value = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-/* XXX - should this be value->get_pmc? */
-return value;
+
+if(key->next != NULL) {
+return value->vtable->get_pmc_keyed(INTERP, value, key->next);
+}
+else {
+/* XXX - should this be value->get_pmc? */
+return value;
+}
}
PMC* get_pmc_keyed_int (INTVAL* key) {
@@ -488,7 +530,13 @@
}
mypmc = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-mypmc->vtable->set_integer_native(INTERP, mypmc, value);
+
+if(key->next != NULL) {
+mypmc->vtable->set_integer_keyed(INTERP, mypmc, key->next, value);
+}
+else {
+mypmc->vtable->set_integer_native(INTERP, mypmc, value);
+}
}
void set_integer_keyed_int (INTVAL* key, INTVAL value) {
@@ -544,7 +592,12 @@
}
mypmc = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-mypmc->vtable->set_number_native(INTERP, mypmc, value);
+if(key->next != NULL) {
+mypmc->vtable->set_number_keyed(INTERP, mypmc, key->next, value);
+}
+else {
+mypmc->vtable->set_number_native(INTERP, mypmc, value);
+}
}
[PATCH] Recursive keyed lookups for array.pmc
When a KEY * key datastructure is passed to a keyed method in array.pmc,
and key->next is true...:
array.pmc will recurse into the keyed lookup method of the PMC that it
contains, passing it key->next.
This implements the recursive indexing behavior as described in PDD08.
-scott
Index: parrot/classes/array.pmc
===
RCS file: /cvs/public/parrot/classes/array.pmc,v
retrieving revision 1.27
diff -u -r1.27 array.pmc
--- parrot/classes/array.pmc13 Jul 2002 17:07:25 - 1.27
+++ parrot/classes/array.pmc22 Jul 2002 08:22:39 -
@@ -162,7 +162,13 @@
}
value = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-return value->vtable->get_integer(INTERP, value);
+
+if(key->next != NULL) {
+return value->vtable->get_integer_keyed(INTERP, value, key->next);
+}
+else {
+return value->vtable->get_integer(INTERP, value);
+}
}
INTVAL get_integer_keyed_int (INTVAL* key) {
@@ -204,7 +210,13 @@
}
value = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-return value->vtable->get_number(INTERP, value);
+
+if(key->next != NULL) {
+return value->vtable->get_number_keyed(INTERP, value, key->next);
+}
+else {
+return value->vtable->get_number(INTERP, value);
+}
}
FLOATVAL get_number_keyed_int (INTVAL* key) {
@@ -247,7 +259,13 @@
}
value = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-return value->vtable->get_bignum(INTERP, value);
+
+if(key->next != NULL) {
+return value->vtable->get_bignum_keyed(INTERP, value, key->next);
+}
+else {
+return value->vtable->get_bignum(INTERP, value);
+}
}
BIGNUM* get_bignum_keyed_int (INTVAL* key) {
@@ -289,7 +307,13 @@
}
value = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-return value->vtable->get_string(INTERP, value);
+
+if(key->next != NULL) {
+return value->vtable->get_string_keyed(INTERP, value, key->next);
+}
+else {
+return value->vtable->get_string(INTERP, value);
+}
}
STRING* get_string_keyed_int (INTVAL * key) {
@@ -331,7 +355,13 @@
}
value = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-return value->vtable->get_bool(INTERP, value);
+
+if(key->next != NULL) {
+return value->vtable->get_bool_keyed(INTERP, value, key->next);
+}
+else {
+return value->vtable->get_bool(INTERP, value);
+}
}
INTVAL get_bool_keyed_int (INTVAL* key) {
@@ -374,7 +404,13 @@
}
value = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-return value->vtable->elements(INTERP, value);
+
+if(key->next != NULL) {
+return value->vtable->elements_keyed(INTERP, value, key->next);
+}
+else {
+return value->vtable->elements(INTERP, value);
+}
}
INTVAL elements_keyed_int (INTVAL* key) {
@@ -412,8 +448,14 @@
}
value = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-/* XXX - should this be value->get_pmc? */
-return value;
+
+if(key->next != NULL) {
+return value->vtable->get_pmc_keyed(INTERP, value, key->next);
+}
+else {
+/* XXX - should this be value->get_pmc? */
+return value;
+}
}
PMC* get_pmc_keyed_int (INTVAL* key) {
@@ -488,7 +530,13 @@
}
mypmc = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-mypmc->vtable->set_integer_native(INTERP, mypmc, value);
+
+if(key->next != NULL) {
+mypmc->vtable->set_integer_keyed(INTERP, mypmc, key->next, value);
+}
+else {
+mypmc->vtable->set_integer_native(INTERP, mypmc, value);
+}
}
void set_integer_keyed_int (INTVAL* key, INTVAL value) {
@@ -544,7 +592,12 @@
}
mypmc = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-mypmc->vtable->set_number_native(INTERP, mypmc, value);
+if(key->next != NULL) {
+mypmc->vtable->set_number_keyed(INTERP, mypmc, key->next, value);
+}
+else {
+mypmc->vtable->set_number_native(INTERP, mypmc, value);
+}
}
void set_number_keyed_int (INTVAL * key, FLOATVAL value) {
@@ -582,7 +635,12 @@
}
mypmc = ((PMC**)(((Buffer *)SELF->data)->bufstart))[ix];
-mypmc->vtable->set_string_native(INTERP, mypmc, value);
+if(key->next != NULL) {
+mypmc->vtable->set_string_keyed(INTERP, mypmc, key->next, value);
+
Re: PARROT QUESTIONS: Keyed access: PROPOSAL
Sunday 21 July 2002 21:34, Dan Sugalski wrote: > > No. They are not. You're missing the important case where the data > structure is inherently and intrinsically multidimensional. > >my int Array @foo : dimensions(3); >@foo[1;2;3] = 12; > > Or whatever the syntax is in perl to declare a 3D array and access > the element at (1,2,3). > In my opinion, there are actually two different things to dicuss: - keyed opcodes - keyed methods on the PMC vtable You can keep keyed opcodes, without actually implementing the keyed methods. Actually, ALL our keyed methods look like: ... stuff to get the value of SELF[key] into VALUE.. VALUE->vtable->method(..) Puting this code into the opcode, and removing the vtable methods (except get_keyed_*), shouldn't make it slower at all IMHO (same job being done, in the same way. The same number (two) of vtable calls). Keyed opcodes can stay in the interest of code density. > > No. Keyed access for all methods stays. You're forgetting one very > important case, the one where the contents of an aggregate isn't a > PMC. This scheme would then require the aggregate PMC to construct > fake PMCs to do operations on. Bad, definitely bad. Is really so bad? As long that what is ultimately stored in the aggregate is one of our base types (pmc, int, string, float), the opcode shouldn't need to build the fake PMC. Or, ¿are you talking about multi-dimensional PMCs? I don't see why these should need to build fake PMCs: you just call the get_keyed method, and it will do the Right Thing (probably getting the value directly, maybe propagating a portion of the key to a inner PMC). As I said, there should no be any speed cost at all, and a significant improvement on code size. But this is only an opinion. I am willing to submit a benchmarking patch if it has some interest. Best, -àngel
