I No Longer Hate find_vtable_meth_ns() As Much (But I'm Still Going to Delete It Very Soon)
With a hint from Jonathan about storing vtable methods separately in
namespaces and a reminder from Kevin that named lookups were still important,
I wrestled my earlier patch into shape.
All tests pass.
I hate to brag too much about microbenchmarks, but before:
$ prove t/compilers/pge/p5regex/p5rx.t
t/compilers/pge/p5regex/p5rxok
355/960 skipped: various reasons
All tests successful, 355 subtests skipped.
Files=1, Tests=960, 7 wallclock secs ( 6.30 cusr + 0.20 csys = 6.50 CPU)
... after:
$ prove t/compilers/pge/p5regex/p5rx.t
t/compilers/pge/p5regex/p5rxok
355/960 skipped: various reasons
All tests successful, 355 subtests skipped.
Files=1, Tests=960, 2 wallclock secs ( 2.28 cusr + 0.10 csys = 2.38 CPU)
Speeding up PGE doesn't hurt my feelings.
Oh, how's Perl 6? I'm glad you asked. Before:
Files=27, Tests=198, 47 wallclock secs (44.69 cusr + 0.50 csys = 45.19 CPU)
... after:
Files=27, Tests=198, 11 wallclock secs ( 9.30 cusr + 0.32 csys = 9.62 CPU)
Callgrind is happier too. Before:
2,859,808,451 452 591 PROGRAM TOTALS
370,031,493. . hash.c:parrot_hash_get_idx
296,162,666. . ascii.c:ascii_compare
216,535,642. . hash.c:parrot_hash_get_bucket
205,389,756. . string.c:string_compare
188,198,076. . objects.c:find_vtable_meth_ns
132,994,291. . dod.c:Parrot_dod_sweep
116,631,596. . namespace.pmc:Parrot_NameSpace_get_pmc_keyed_str
... after:
880,046,504 495 22,527 PROGRAM TOTALS
98,680,680. . dod.c:Parrot_dod_sweep
78,138,108. . resources.c:compact_pool
70,556,241. . ascii.c:ascii_compute_hash
49,233,260. . string.c:string_make_direct
41,103,096. . headers.c:get_free_buffer
30,652,923. . resources.c:Parrot_allocate_string
I do think there are still some cleanups in this area, but getting a three to
five time speedup *without breaking any tests* as well as simplifying some a
grotty code seems like a good thing to me.
-- c
=== compilers/imcc/pbc.c
==
--- compilers/imcc/pbc.c (revision 4018)
+++ compilers/imcc/pbc.c (local)
@@ -782,8 +782,6 @@
else
sub-multi_signature = NULL;
-Parrot_store_sub_in_namespace(interp, sub_pmc);
-
if (unit-is_vtable_method == 1) {
/* Work out the name of the vtable method. */
if (unit-vtable_name != NULL)
@@ -808,6 +806,8 @@
sub-vtable_index = vtable_index;
}
+Parrot_store_sub_in_namespace(interp, sub_pmc);
+
pfc-type = PFC_PMC;
pfc-u.key= sub_pmc;
unit-sub_pmc = sub_pmc;
=== src/objects.c
==
--- src/objects.c (revision 4018)
+++ src/objects.c (local)
@@ -81,28 +81,7 @@
static PMC*
find_vtable_meth_ns(Interp *interp, PMC *ns, INTVAL vtable_index)
{
-const INTVAL k = VTABLE_elements(interp, ns);
-PMC * const key = VTABLE_nextkey_keyed(interp, key_new(interp), ns,
-ITERATE_FROM_START);
-
-const char * const meth = Parrot_vtable_slot_names[vtable_index];
-STRING * const meth_str = string_from_cstring(interp, meth, strlen(meth));
-
-int j;
-
-for (j = 0; j k; ++j) {
-STRING * const ns_key = (STRING *)parrot_hash_get_idx(interp,
-(Hash *)PMC_struct_val(ns), key);
-PMC * const res= VTABLE_get_pmc_keyed_str(interp, ns, ns_key);
-
-/* success if matching vtable index or double-underscored name */
-if (res-vtable-base_type == enum_class_Sub
- (PMC_sub(res)-vtable_index == vtable_index ||
-string_compare(interp, meth_str, ns_key) == 0))
-return res;
-}
-
-return PMCNULL;
+return VTABLE_get_pmc_keyed_int(interp, ns, vtable_index);
}
/*
=== src/pmc/namespace.pmc
==
--- src/pmc/namespace.pmc (revision 4018)
+++ src/pmc/namespace.pmc (local)
@@ -1,5 +1,5 @@
/*
-Copyright (C) 2005, The Perl Foundation.
+Copyright (C) 2005-2007, The Perl Foundation.
$Id$
=head1 NAME
@@ -12,8 +12,8 @@
=head2 Data
- PMC_struct_val ... the hash, bucket-value is either a
- var/sub or a namespace, of a FixedPMCarray
+ PMC_struct_val ... the hash, bucket-value is a
+ var/sub, a namespace, or a FixedPMCarray
of 2 PMCs (namespace, sub/var) slots
PMC_pmc_val ... parent namespace
PMC_data ... Namespace information struct (name, class/role)
@@ -30,14 +30,14 @@
#include assert.h
/*
- * Typically a named slot either contains another namespace or a
+ * Typically a named slot contains either
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
* Damian Conway ([EMAIL PROTECTED]) [070613 22:46]:
My underlying model is that documentation and the source it's documenting
should be entirely orthogonal. So, to me, it would be very surprising if a
programming construct (block comments) interacted with documentation. Or
vice versa.
* At the Perl 6 level, all Pod is syntactically and semantically
invisible and therefore already equivalent to a comment.
* At the Pod 6 level, all Perl code is merely meaningless ambient
background noise and therefore already equivalent to whitespace.
We had a private discussion about this already three years ago: I
fully disagree! If the code and the documentation are not entangled,
why do you want to put them in the same file? Why do you put them in
the same distribution even?
No, the documentation is all about the code. The docs present everything
what the user should know about the code. The docs are the user's view
of the implementation, and the code is the computer's view on the same.
Realizing that, there are a few problems:
- is everything in the code documented?
- is everything documented correctly?
- during development, the interfaces change. Do we update the docs?
Getting people to document (and maintain the documentation) is not easy.
For some people, it's just not in their system. So, if you can make it
easier to do, if you can avoid the need for duplication (write it in
code, write the same again in the docs), if you can save some typing,
you probably end-up with better code.
Last week, I restructured the code of MailTools... published in 1995,
one of the oldest modules around. Also one of the most used modules
and described in many books. Changing the manual-page organization from
at-end-of-file to interleaved put the docs close to the respective
code. I found many mistakes in the docs, during this process: methods
which were not documented, methods which were not implemented, parameters
which were not or wrongly described...
As some people know, I wrote OODoc which extends the syntax of POD(5)
with logical markup and some simple avoidance of replication. For the
MailBox distribution (which is quite large), that saved me typing of
700.000 characters (35%)! Do you know how long it takes to type those?
So how much time did I gain to spend on code quality?
I had suggested syntax like this, in Perl6:
class Mail::Message {
`base class for message types
.has $msgid;
`The (internet wide) unique string which identifies this
`message object. May be undef as long as the message is
`begin composed.
.has $content_type = 'text/plain';
}
You see that there is little room for errors in the documentation.
Before people start flame-wars: the syntax is just to start a
discussion, to show how simple it could be. I am not stuck on that.
This can be automatically translated into (traditional POD like this)
(leaving out some blank lines for shortness sake)
=head1 NAME
Mail::Mesage - base class for message types
=head1 INHERITANCE
Mail::Message
isa Object
Mail::Message
is extended by Mail::Box::Message
=head1 METHODS
=head2 Attributes
=over 4
=item C$msgid
The (internet wide) unique string which identifies this
message object. May be undef as long as the message is
begin composed.
=item C$content_type (default 'text/plain')
=back
Damian, can you show how you would document the same code in POD6
syntax to get a comparible short man-page?
IMO: code and docs are two representations on one thinking processes,
named programming. They are the opposit not orthogonal: parallel
developments with a little shifted focus.
The separation between State and Church is only about power: that the
Pope can't tell the President how to rule a country. But the people
need to merge their religious believes with their social duties.
Are you designing for The Power or The People?
--
Regards,
MarkOv
Mark Overmeer MScMARKOV Solutions
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://Mark.Overmeer.net http://solutions.overmeer.net
POD - Code entanglement (was: Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn)
Mark Overmeer wrote:
We had a private discussion about this already three years ago: I
fully disagree! If the code and the documentation are not entangled,
why do you want to put them in the same file? Why do you put them in
the same distribution even?
No, the documentation is all about the code. The docs present everything
what the user should know about the code. The docs are the user's view
of the implementation, and the code is the computer's view on the same.
I agree.
And while writing a class in Perl 6 the other day I noticed that copied
pasted the signature of method to the pod:
=begin pod
=head3 Cmethod from_string(Str $s);
initialize the Sudoku from a string C$s, with a 0 denoting an empty cell
and a number between 1 and 9 a clue.
Note that there is currently no way to use this function for sizes bigger
than 9x9 overall length.
=end pod
method from_string(Str $s){
# implementation of that method here
}
Since method signatures are very expressive in Perl 6, there should be a
way of accessing them in the POD without copy paste. If you don't
think that's necessary: try it out for yourself. Write a class and
document it properly. I'm sure you'll end up doing the same as I did.
ATM I don't know that should be implemented, but perhaps somebody else
can think of a good way.
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
I'm going to stay away from the POD referencing Perl debate for the time being. Instead, a couple of thoughts: 1. It has always been my understanding that comments intimately relate to documentation, despite being part of Perl's syntax. As such, they are a technical violation of this separation of Church and State, being State-sponsored religion as it were. (Who'd have thought that we'd be talking politics and religion on a programming language mailing list? Egad!) Not that I'm advocating the removal of comments; their sheer practical value makes up for their heathen ways. 2. Getting block comments to hide POD blocks wouldn't require the POD parser to have a full implementation of a Perl parser. It would require the POD parser to have a _limited_ implementation of a Perl parser, one that's capable of identifying block comments. And IIRC, you already have to do something like this with respect to block quotes: say :to(END); =begin POD blah blah blah =end POD END If I understand matters correctly, the POD code in the above example isn't POD code at all, but rather the content of a multi-line quote. So extending the POD parser's awareness of Perl syntax to handle block comments as well isn't much of a stretch. -- Jonathan Dataweaver Lang
Re: POD - Code entanglement
Moritz Lenz:
=begin pod
=head3 Cmethod from_string(Str $s);
[..]
=end pod
method from_string(Str $s){
# implementation of that method here
}
Since method signatures are very expressive in Perl 6, there should be a
way of accessing them in the POD without copy paste.
As I read =head 3 method... I also had the idea that semantically more
meaningful directives might be a good idea.
I mean POD uses constructs like headlines, lists, blocks, italic etc.
which all describe _how it looks like_ and not _what it is_.
A head3 might be the headline of a method documentation as well as one
introducing the contact information for the author of a module.
The directive doesn't have much semantics.
Other people might use head2 for documenting methods, what leads to a
pretty inconsistent look of the documentation.
So maybe directives like method, sub, attribute, class etc. might be a
better choice regarding semantics.
Of course those semantics are directly given in the code, so why not use
them as MarkOv proposed?
It's a bit like HTML-XML, where the former lacks most of the semantics
and makes the information processing - not to speak about a consistent
look over several documents - a lot harder.
I could imagine a semantic documentation in Perl6, that could be
translated to XML/HTML+CSS or to POD(6) for formatting it.
A semantic documentation could also be very useful in IDEs, where the
IDE could clearly (without guessing) determine the documentation for a
certain element.
Also you could automatically test if every method/class/.. has been
documented etc.
Semantics are very useful in documentation, why throw them away?
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
Re: POD - Code entanglement
* Thomas Wittek ([EMAIL PROTECTED]) [070614 15:18]: So maybe directives like method, sub, attribute, class etc. might be a better choice regarding semantics. See OODoc::Parser::Markov It's a bit like HTML-XML, where the former lacks most of the semantics and makes the information processing - not to speak about a consistent look over several documents - a lot harder. In HTML, you have logical markup as well: EM, STRONG, KEY, CODE, etc With id and class, you can make any annotation you like: div class=method my_method OPTIONS This is the description of a method. /div I love the power of CSS. I could imagine a semantic documentation in Perl6, that could be translated to XML/HTML+CSS or to POD(6) for formatting it. The nicest thing would be that the semantic docs become part of the parse tree, which then (using standard introspection) can be used to generate manual pages, natively into POD, roff, HTML, whatever. I see no reason why entangled docs are so hard to parse for Perl6, as Damian arguments. Even it being difficult is not a good reason to make the life of all programmers harder. -- MarkOv Mark Overmeer MScMARKOV Solutions [EMAIL PROTECTED] [EMAIL PROTECTED] http://Mark.Overmeer.net http://solutions.overmeer.net
Re: POD - Code entanglement
Thomas Wittek skribis 2007-06-14 17:18 (+0200):
So maybe directives like method, sub, attribute, class etc. might be a
better choice regarding semantics.
Yes, a better choice indeed. But I would still not be happy with it,
because there would still be a lot of code duplication.
method foo (:$bar = 5) { ... }
I don't want to have to mention *again* that the thing is a method,
and that it is called foo, that it has a named argument identified
as $bar, which defaults to 5.
This is why I (long time ago) suggested is documented. Like Mark, I do
not really care about the actual syntax much:
method foo is documented(Foos its argument interactively)
(
:$bar = 5 is documented(Object to be fooed),
# I'm not sure about the precedence of is.
) {
...
}
The backtick is rather cute and saves a lot of typing. It's like a
comment (#), but ends up as *external* documentation. That's nice.
Semantics are very useful in documentation, why throw them away?
Why not have both? With normal POD as suggested by Damian, you could
still generate it from something else. A few macros could help ignore
the inline documentation.
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
On 6/14/07, Mark Overmeer [EMAIL PROTECTED] wrote:
I had suggested syntax like this, in Perl6:
class Mail::Message {
`base class for message types
.has $msgid;
`The (internet wide) unique string which identifies this
`message object. May be undef as long as the message is
`begin composed.
.has $content_type = 'text/plain';
}
I always thought this could be achieved using traits:
class Mail::Message is doc(base class for message types) {
.has $msgid is doc(The (internet wide) unique string which
identifies this message object. May be undef as long as the message
is begin composed.);
.has $content_type = 'text/plain';
}
--
Aankhen
(We have no branches.)
Re: POD - Code entanglement
On 6/14/07, Thomas Wittek [EMAIL PROTECTED] wrote: It's a bit like HTML-XML, where the former lacks most of the semantics and makes the information processing - not to speak about a consistent look over several documents - a lot harder. Actually, that's incorrect. HTML is a markup language with a particular set of elements, some of which have semantic meaning attached and some of which don't. XML, on the other hand, is a means of writing your own markup languages; this has two consequences in this context: 1. It is just as easy—if not easier—to have an XML dialect containing elements with absolutely no meaning. 2. Even if the dialect contains only elements with well-defined semantics, it's still completely meaningless to a generic XML parser. A parser must be intimately familiar with the dialect to understand that any element has semantic meaning. If you were referring to XHTML vs. HTML, I would like to point out that XHTML 1.0 is merely a reformulation of HTML 4.01 in XML. The elements and their semantics are unchanged. XHTML 1.1 modularizes the DTD and adds a few Ruby (annotation, obviously, not language) elements, in addition to a few other minor changes. As for XHTML 2.0, that's still a long way off. :-) -- Aankhen (We have no branches.)
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
Jonathan Lang wrote:
2. Getting block comments to hide POD blocks wouldn't require the POD
parser to have a full implementation of a Perl parser. It would
require the POD parser to have a _limited_ implementation of a Perl
parser, one that's capable of identifying block comments. And IIRC,
you already have to do something like this with respect to block
quotes:
Actually, the POD parser would have to be a fairly complete Perl parser.
As your example shows:
say :to(END);
=begin POD
blah blah blah
=end POD
END
If I understand matters correctly, the POD code in the above example
isn't POD code at all, but rather the content of a multi-line quote.
So extending the POD parser's awareness of Perl syntax to handle block
comments as well isn't much of a stretch.
If *I* understand matters correctly, Perl 6 will see that as identical to
say :to(END);
END
*because* we want the POD parser be simple, rather than an
almost-complete parser of Perl. After all, there are many ways to hide
POD-like text in Perl.
You might think, Well, how hard is it to look for :to(XYZ) followed
by a line containing XYZ? Going beyond the fact that there are actually
quite a few ways to spell :to(XYZ), Perl code that generates Perl code
will trip you up:
say say :to(END);;
say Here's my text;
say =begin comment;
say My auto-generated code even contains comments on it's strings!
say =end;
say More of my text;
say END;
You have to parse all string syntaxes to avoid that pitfall. And once
you take care of that issue, you have to handle the problem of parsing
Perl code that's trying to parse Perl code, looking for say statements
that use here-doc syntax containing POD comments:
my $checker = regex {
say \s* \: to \( \w+ \) ; $ # match a say with here-doc
(
! \s* $1 .* $
)* # match any lines that don't start with $1
=for comment # match the beginning of an embedded POD comment
}
(No, I don't approve of the indentation of that example. But should your
program fail just because somebody doesn't follow good style?)
And once you've extended the parser to handle *that* case, Finagle's Law
dictates that someone will put the above code sample into a Perl string
literal!
In summary:
As your example pointed out, the POD parser would have to handle all the
various string syntaxes of Perl 6. Then, there is also regular
expression syntax that has to be covered. And who knows what else I'm
overlooking?
Compare that with the simplicity that $larry $damian are promoting.
Yes, it'll be a pain to get the effect you *wanted* from
say :to(END);
=begin POD
blah blah blah
=end POD
END
but the cost to the POD parser is just not worth it.
=thom
-
Finagle's Law: the perversity of the Universe tends towards a maximum.
Re: POD - Code entanglement
Mark Overmeer schreef: The nicest thing would be that the semantic docs become part of the parse tree, which then (using standard introspection) can be used to generate manual pages, natively into POD, roff, HTML, whatever. I like to call them: lexical comments. -- Groet, Ruud
Re: POD - Code entanglement
Thomas Wittek wrote:
Moritz Lenz:
=begin pod
=head3 Cmethod from_string(Str $s);
[..]
=end pod
method from_string(Str $s){
# implementation of that method here
}
Since method signatures are very expressive in Perl 6, there should be a
way of accessing them in the POD without copy paste.
As I read =head 3 method... I also had the idea that semantically more
meaningful directives might be a good idea.
That may be my fault, I didn't care to look if there was a more semantic
way to describe it.
I mean POD uses constructs like headlines, lists, blocks, italic etc.
which all describe _how it looks like_ and not _what it is_.
Headlines, lists and blocks are IMHO semantic markup.
If I'd say Huge font in bold that'd be descriptive rather than
semantic markup.
A head3 might be the headline of a method documentation as well as one
introducing the contact information for the author of a module.
The directive doesn't have much semantics.
That doesn't make a headline worthless. It just shouldn't be abused the
way I did it ;)
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: POD - Code entanglement
Thomas Wittek wrote: I mean POD uses constructs like headlines, lists, blocks, italic etc. which all describe _how it looks like_ and not _what it is_. I think Damian would take exception to that statement. He worked quite hard to make sure that POD describes _meaning_ rather than _appearance_. He even renamed B from bold to basis, I from italic to important, and U from underline to unusual. All of those are fairly odd choices, with the possible exception of important, but they were clearly made with an eye to backwards compatibility of POD while changing people's focus from how it looks to what it is. A head3 might be the headline of a method documentation as well as one introducing the contact information for the author of a module. The directive doesn't have much semantics. Other people might use head2 for documenting methods, what leads to a pretty inconsistent look of the documentation. Well, I'd argue that head3 has plenty of semantics. It's a level-3 header. How that's rendered is decided elsewhere. I think the issue is not that head3 is insufficiently semantic, it's just that you want something that's even more specific. And POD 6 was designed with exactly that kind of thing in mind. You can, according to the existing S26, say things like: =Method the method synopsis goes here =begin Parameters =item foo is the fooiest parameter =item bar is the barstest parameter =end Parameters Furthermore, the Perl parser actually *keeps* the POD chunks, so you can access all that information in the context of the Perl parse. Damian and Larry were clearly laying the groundwork for exactly the sort of javadoc-ish features you are asking for. =thom - The supreme irony of life is that hardly anyone gets out of it alive. --Robert A. Heinlein [Job: A Comedy of Justice]
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
On Thu, Jun 14, 2007 at 09:20:51AM -0600, Thom Boyer wrote: : Compare that with the simplicity that $larry $damian are promoting. Yes, and the simplicity we're promoting here is mostly *syntactic* simplicity. It's obvious that at a semantic level, there has to be a certain amount of incest between the two spheres (if indeed there are only two). From the Perl 6 perspective, information flows easily from the documentation to the program via the %=FOO pod twigil, because the Perl 6 parser is required to embed a pod parser specifically to guarantee that such values will be introspectable. Getting information to flow the other direction is more problematic because documentation is essentially passive data and must be interpreted by something external (often several different somethings). However, for a given language that uses pod for documentation, there can certainly be some conventions for making references to nearby declarations without having to repeat the entire declaration. Such references could be either by name or by position. Positional notation forces you to intersperse things you might not want to. What programmer really wants to see their function signature splattered out over many lines, or wants the beginning of the declaration off the screen before you get to the function body? Also, positional notation doesn't deal well with factoring out identical names from related entities that just want to share a chunk of documenation. So I think a named reference is a good compromise, where the name in the documentation (in some easily recognized syntactic form) refers to the next declaration (or set of declarations) of that same name. Hopefully the pod either knows implicitly or has been told explicitly how to parse out such declarations for insertion into the document. (And a positional notation could just be a degenerate case of not specifying the name (or using a name of * maybe), so it finds the next declaration of any name. Maybe even some kind of wildcarding works for hybrid situations.) The syntax for such named forward references is open for bikeshedding. (I've intentionally not given any examples in this message to avoid prejudicing the matter.) Larry
Re: Is Perl 6 too late? (an aside)
It's a valid aside to note that, while people know what singular and
plural are, few people use or even refer much to the Greek use of a
special intermediary (the dual) when there were exectly two of
something...but the basic mindest of dichotomy is a fundament of the
language. (c.f. the men/de construct so basic to the language).
Perl is like that. There are a lot of little corner cases that are
distinctly Perl, things unlikely to be seen elsewhere, and sometimes
hardly ever even used in Perl but the mindset that is Perl is a
beautiful thing, and that's still there.
Besides, if you don't get the aesthetics of the Schwartzian Transform,
then you should probably be using python or java anyway, hm?
Let's let Perl be Perl. It's a new Perl, but it's still a pearl. =o)
*Paul
--- Larry Wall [EMAIL PROTECTED] wrote:
On Mon, May 14, 2007 at 02:21:47PM -0400, Ryan Richter wrote:
: In Perl 6, the sigil is used to distinguish between
:
: foo bar
:
: which calls bar and passes the return value to foo, and
:
: foo bar
:
: which passes bar as a Code object to foo.
In other words, the sigil is consistently a noun marker in Perl 6,
even when a sigil is used on a verb. In Perl 6, where sigils
distinguish nouns not only from verbs, but also from adjectives (if
you count types as adjectival). With a glance you can tell which
are the nouns and which are the types here:
multi CatDog sub make_catdog (Cat $cat, Dog $dog) {...}
multi CatDog sub make_catdog (Cat Dog $catdog) {...}
While Gabor is correct that in Perl 5 removing the sigils from verbs
made some verbal collisions happen that otherwise wouldn't have, in
Perl 6 we've mostly fixed that by essentially getting rid of most
reserved words, and making even the builtin functions participate
as normal multis and methods. For that reason, and because verbs
linguistically tend to be disambiguated by the nouns fed to them as
argements, verbs don't need to be conjugated nearly as badly as nouns
need to be declined. A lot of nouns typically don't have arguments
to disambiguate them with, at least until you start subscripting
them,
and we don't do multiple dispatch on subscripts.
As for the original complaint, we long ago decided to ignore people
who
are prejudiced against languages that mark nouns. Greek wouldn't be
Greek if you couldn't decline your nouns. (In my estimation, it's
the conjugated verbs that make Greek so difficult to learn, really.
On the other hand, once you learn them they're very expressive in
tense and aspect. It's all tradeoffs.)
Larry
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
Re: POD - Code entanglement
* Thom Boyer ([EMAIL PROTECTED]) [070614 15:49]: the existing S26, say things like: =Method the method synopsis goes here =begin Parameters =item foo is the fooiest parameter =item bar is the barstest parameter =end Parameters Where is the link with the code? That's the point: there is no automatic checking/avoidance of repetition. Besides, your example is not defined by S26: one can decide to use the tags, someone else chooses other names, and they then cannot be combined into one nice homogeneous set of pages. That's a horror! And if you really like above syntax, why not define =method the method synopsis goes here =option foo is the fooiest parameter =default foo 10 =requires bar is the barstest parameter Which is close to how OODoc is extending POD for Perl5. IMO We can (should) do better for Perl6. -- MarkOv Mark Overmeer MScMARKOV Solutions [EMAIL PROTECTED] [EMAIL PROTECTED] http://Mark.Overmeer.net http://solutions.overmeer.net
Re: [GC] Pin Key PMCs During Method Lookup
Am Mittwoch, 13. Juni 2007 05:02 schrieb chromatic: PMC * const key = VTABLE_nextkey_keyed(interp, key_new(interp), ns, ITERATE_FROM_START); If a GC run happens in the rest of this function, it could collect the newly created Key -- PMCs created and held outside of structures visible to GC are vulnerable to collection. This really shouldn't happen. All GC runs that are done due to lack of some ressource are walking the C-stack and the CPU registers I hope[1]. GC runs initiated at the run-loop level don't need this BTW. [1] the real problem might be that on MS the marking of the CPU-registers isn't happening. See also trace_system_areas() in src/cpu_dep.c and e.g. ... # ifdef PARROT_HAS_HEADER_SETJMP Parrot_jump_buff env; /* Zero the Parrot_jump_buff, otherwise you will trace stale objects */ memset(env, 0, sizeof (env)); /* this should put registers in env, which then get marked in * trace_system_stack below */ setjmp(env); # endif ... how to use a standard C lib function to force CPU registers onto the stack. Other methods for other CPUs are present in that file too. leo
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
Larry Wall wrote: So I think a named reference is a good compromise, where the name in the documentation (in some easily recognized syntactic form) refers to the next declaration (or set of declarations) of that same name. Hopefully the pod either knows implicitly or has been told explicitly how to parse out such declarations for insertion into the document. (And a positional notation could just be a degenerate case of not specifying the name (or using a name of * maybe), so it finds the next declaration of any name. Maybe even some kind of wildcarding works for hybrid situations.) The syntax for such named forward references is open for bikeshedding. (I've intentionally not given any examples in this message to avoid prejudicing the matter.) My first instinct for such a thing would be to surround the perl code to be referenced with POD-like tags: =code name class foo ... =/code ...the idea being that a Perl parser treats the =code and =/code lines as line comments, while a Pod parser would take the block of lines that exists between the two and attaches it to 'name', to be rendered as is whenever 'name' is referenced. In short, =code and =/code would define a target which could then be referenced as few or as many times as you want within your regular perl code using something like =ref name ...where POD would substitute class foo ... every time that it sees =ref name -- Expanding on this idea: * if you don't specify a name on a '=ref' line, you automatically reference the next '=code' section to be found. If you don't bother naming a '=code' section, this is the only way that it can be referenced. If you give '^' as the name, then you automatically reference the last code section that was found. So: =begin pod =ref =end pod =code foo =/code =begin pod =ref ^ =end pod would render the same as =begin pod foo =end pod =begin pod foo =end pod * Put a number instead of a name, and it counts up (if negative) or down (if non-negative) through the code blocks, with -1 being the previous code block and 0 being the next one. A blank name is equivalent to 0, and a '^' is equivalent to -1. This should be used sparingly. * Add or subtract a number to/from a name, and you count up or down from that name, with '+1' giving the first code block following the named codeblock and '-1' giving the last code block prior to it. * In the same way that '=code'...'=/code' is designed to mimic the '=begin'...'=end' syntax of POD blocks, you could introduce a variation of '=code' that mimics the '=for' syntax by grabbing the next line or block of code (say, '=codeline' and '=codeblock'), where a block of code is terminated by a blank line. * the final violation of the separation of Church and State would be to have the Church ask the State to do something for it. Let a '=code' line specify a parser (such as perl): Pod passes the block of code to the specified parser; that parser then (presumably) goes through its paces with the goal of extracting language-specific documentation (such as the previously suggested 'is doc' traits), formatting the result as a text block, and handing that block back to the POD parser. If Pod can't talk to the language parser or vice versa, Pod simply uses the code block as is. -- Jonathan Dataweaver Lang
Re: Last bits of PDD 15 implementation
Allison Randal wrote: I'm about half-way through a quick classification of the failing PDD 15 tests (in t/pdd15oo). A number of the failures are quick things anyone could pick off, so I'll share the list: http://rakudo.org/parrot/index.cgi?pdd_15_remaining_features We're only failing 157 out of 764 tests, so we're getting quite close being able to use the new object implementation as a drop-in replacement for the old object implementation. I've finished a full review, and only added a few more items to the list of tasks. It's now down to 126 failing tests. I'm working on taking more out. A question for compiler and PIR tool writers before I change the code/tests for one feature: the current design decision is that class objects always return a 'typeof' Class, while objects instantiated from the class return a 'typeof' the class name. So: $P0 = newclass Foo $S0 = typeof $P0 # returns Class $P1 = new $P0 $S1 = typeof $P1 # returns Foo This is different than the old object model, which would return Foo for both the class object and the instantiated object. The new way seems saner, but which is more useful? You can always figure out if you have a class or an object by calling 'isa' for Class or Object. Allison
[perl #43218] Memory leaks (compreg, invokecc)
# New Ticket Created by Jurosz Michal # Please include the string: [perl #43218] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43218 Attached test use compreg P1, PASM and invokecc it 100,000 times. On win32 (mingw32) it consumes 70MB of RAM with r18834 (107 MB of RAM with r11704). Similar tests can be found here: http://pr.perl6.cz/mj41/down/Parrot/tests-bugs-etc/02-probably%20memory%20leaks/ -- S pozdravem Michal Jurosz set S28, concat S28, .pcc_sub :anon _indi:\n concat S28, get_params \(0,0,0)\, I0, I1, I2\n concat S28, set I3, 23\n concat S28, set_returns \(0)\, I3\n concat S28, returncc\n compreg P1, PASM set I20, 0 NEXT: set_args (0),S28 get_results (0), P0 invokecc P1 needs_destroy P0 sweep 0 inc I20 lt I20, 10, NEXT #sleep 10 end signature.asc Description: PGP signature
Re: [perl #43218] Memory leaks (compreg, invokecc)
On Thursday 14 June 2007 14:42:31 Jurosz Michal wrote: Attached test use compreg P1, PASM and invokecc it 100,000 times. On win32 (mingw32) it consumes 70MB of RAM with r18834 (107 MB of RAM with r11704). With Linux at r19010, the memory use jumped up to 62 MB for me. However, Valgrind says: ==24190== LEAK SUMMARY: ==24190==definitely lost: 128 bytes in 2 blocks. ==24190==indirectly lost: 208 bytes in 1 blocks. ==24190== possibly lost: 0 bytes in 0 blocks. ==24190==still reachable: 0 bytes in 0 blocks. ==24190== suppressed: 0 bytes in 0 blocks. ==24190== 252 (44 direct, 208 indirect) bytes in 1 blocks are definitely lost in loss record 1 of 3 ==24190==at 0x4006620: malloc (vg_replace_malloc.c:149) ==24190==by 0x41A1170: mem_sys_allocate ==24190==by 0x41AF37E: parrot_new_pmc_hash_x ==24190==by 0x41AF45E: parrot_new_pmc_hash ==24190==by 0x424930A: Parrot_Hash_init ==24190==by 0x4203715: Parrot_default_thaw ==24190==by 0x424934B: Parrot_Hash_thaw ==24190==by 0x41AD9C0: visit_todo_list_thaw ==24190==by 0x41AD703: visit_loop_todo_list ==24190==by 0x41AE1EB: run_thaw ==24190==by 0x419B518: init_world ==24190== 84 bytes in 1 blocks are definitely lost in loss record 2 of 3 ==24190==at 0x4006620: malloc (vg_replace_malloc.c:149) ==24190==by 0x41A1170: mem_sys_allocate ==24190==by 0x41EC1DB: queue_init ==24190==by 0x41ED08B: Parrot_init_events ==24190==by 0x419F464: make_interpreter ==24190==by 0x41D3BEB: Parrot_new ==24190==by 0x8048860: main ==24190== 208 bytes in 1 blocks are indirectly lost in loss record 3 of 3 ==24190==at 0x4006620: malloc (vg_replace_malloc.c:149) ==24190==by 0x41A1170: mem_sys_allocate ==24190==by 0x41AF2C9: init_hash ==24190==by 0x41AF45E: parrot_new_pmc_hash ==24190==by 0x424930A: Parrot_Hash_init ==24190==by 0x4203715: Parrot_default_thaw ==24190==by 0x424934B: Parrot_Hash_thaw ==24190==by 0x41AD9C0: visit_todo_list_thaw ==24190==by 0x41AD703: visit_loop_todo_list ==24190==by 0x41AE1EB: run_thaw ==24190==by 0x419B518: init_world I realize the numbers don't add up, but I'm not sure that this is an actual leak. -- c
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
Larry and Thom have each ably explained the rhyme and reason of the choices
that we made for Pod 6. Here I will merely summarize those reasons, and answer
a specific question.
* Pod and Perl (or any other ambient source code) are to be syntactically
separated, even when there are semantic interconnections
* Perl 6 will be able to access ambient Pod via $=POD (and other
$=WHATEVER variables)
* It doesn't make sense for Pod to access ambient Perl, since Pod is a
passive mark-up notation, not an executable language
* It is self-evidently the case that documentation can be usefully
derived from source code, as well as from explicit mark-up
* That does not, however, mean that source code and explicit mark-up are
(or should be) either equivalent or syntactically commingled
* Rather, it means that the *tools* that extract such documentation need to
be able to extract it from both explicit mark-up and source code
* This will be possible in Perl 6, since both the Pod and Perl 6 parsers
will be accessible from Perl 6.
* Pod 6 is not a presentational mark-up scheme; in fact, it has no
presentational elements at all
* Pod 6 is both a structural and a semantic scheme; you can specify both the
structure of a document, and the meaning of its various components
* Structural mark-up features are entirely lower-case (=head, =item, =table)
at the block level, and single-letter upper-case (B, N, S) at the
embedded level
* Semantic mark-up features are entirely upper-case (=METHOD, =PURPOSE,
=DEFAULT)
* The semantic features are intended to be used to facilitate the creation and
use of tools that can autoextract documentation elements directly from code
* Such tools would (usually) convert the information extracted from
[source + semantic-Pod] into purely structural Pod, which could then
be fed to any suitable pod-to-whatever converter
* In other words, the tool-chain envisaged is something like:
perl6doc pod2whatever
source
+ purely
structural Pod --- structural --- plaintext
+ Pod \-- HTML
semantic Pod \- XML
\ roff
\--- MPEG
\etc.
* Which means that Pod 6 needs to be a suitable pure-structural-mark-up
target language with an extensible semantic overlayer
* Which is precisely what it has already been designed to be
* To summarize the summary:
- Use Perl for what Perl is good for (specification)
- Use Pod for what Pod is good for (commentary)
- Then generate unified documentation by extracting information from
wherever its available (source or mark-up), according to what the
reader asks for
- The issue is not having sufficiently powerful Pod syntax;
the issue is having sufficiently powerful documentation-generating *tools*
To answer Mark's specific question:
class Mail::Message {
`base class for message types
.has $msgid;
`The (internet wide) unique string which identifies this
`message object. May be undef as long as the message is
`begin composed.
.has $content_type = 'text/plain';
}
Damian, can you show how you would document the same code in POD6
syntax to get a comparible short man-page?
Like so:
class Mail::Message {
=PURPOSE Base class for message types
has $msgid;
=for PURPOSE
The (internet wide) unique string which identifies this
message object. May be undef as long as the message is
begin composed.
has $content_type = 'text/plain';
}
Damian
PS: I agree that there needs to be a mechanism for abstracting names
within Pod and for extracting those names from ambient code. I will
propose such a mechanism and the syntax for it in a subsequent email
(probably early next week).
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
say :to(END); =begin POD blah blah blah =end POD END If I understand matters correctly, the POD code in the above example isn't POD code at all, but rather the content of a multi-line quote. No. It's Pod. *Any* line that begins with '=begin' always starts a Pod block. Always. To get the multi-line quote, you'd need: say :to(END); =begin POD blah blah blah =end POD END Damian
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
On 6/14/07, Damian Conway [EMAIL PROTECTED] wrote:
snip
To get the multi-line quote, you'd need:
say :to(END);
=begin POD
blah blah blah
=end POD
END
Damian
Would this work as well?
say :to(END);
\x{3D}begin POD
blah blah blah
\x{3D}end POD
END
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
Chas Owens asked:
Would this work as well?
say :to(END);
\x{3D}begin POD
blah blah blah
\x{3D}end POD
END
Yes, except for the :to actually needing to be qq:to (which was wrong
all the way through these examples, BTW).
You could also just use:
say qq:to(END);
\=begin POD
blah blah blah
\=end POD
END
Damian
[perl #43219] segfault in tcl
# New Ticket Created by Will Coleda # Please include the string: [perl #43219] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43219 With recent updates, tcl suite is MUCH faster, but is now segfaulting in several places. No clue when it last worked. Here's a typical bt, caught in t/cmd_array.t... (gdb) run tcl.pbc t/cmd_array.t Starting program: /Users/coke/research/parrot-p6/parrot tcl.pbc t/ cmd_array.t Reading symbols for shared libraries .++.+ done Reading symbols for shared libraries . done Reading symbols for shared libraries . done 1..50 ok 1 - array, no args ok 2 - array, good subcommand, no array ok 3 - array, bad subcommand, bad arary ok 4 - array exists yes ok 5 - array exists no ok 6 - array exists missing ok 7 - array exists too many args ok 8 - array exists lexical ok 9 - array size too many args ok 10 - array size 1 ok 11 - array size 2 ok 12 ok 13 - array set list ok 14 - array set multi list Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0371c63c 0x000e0e50 in ascii_compare (interp=0x26003b0, lhs=0x300f504, rhs=0x35225e8) at src/charset/ascii.c:219 219 const int ret_val = memcmp(lhs-strstart, rhs- strstart, min_len); (gdb) bt #0 0x000e0e50 in ascii_compare (interp=0x26003b0, lhs=0x300f504, rhs=0x35225e8) at src/charset/ascii.c:219 #1 0x00012732 in string_equal (interp=0x26003b0, s1=0x300f504, s2=0x35225e8) at src/string.c:1305 #2 0x000298e9 in Parrot_get_HLL_id (interp=0x26003b0, hll_name=0x35225e8) at src/hll.c:207 #3 0x0002947e in Parrot_register_HLL (interp=0x26003b0, hll_name=0x35225e8, hll_lib=0x35225c4) at src/hll.c:134 #4 0x0018f47a in yyparse (yyscanner=0x26fa120, interp=0x26003b0) at compilers/imcc/imcc.y:525 #5 0x0019ade5 in compile_string (interp=0x26003b0, s=0x2897600 .HLL 'Tcl', ''\n.namespace \n.sub '_anon' :anon\n.local pmc colons, split, epoch\ncolons = get_root_global ['_tcl'], 'colons'\n split = get_root_global ['parrot'; 'PGE::Util'], 'split'\n epoc..., yyscanner=0x26fa120) at compilers/imcc/imcc.l:1153 #6 0x0005b423 in imcc_compile (interp=0x26003b0, s=0x2897600 .HLL 'Tcl', ''\n.namespace \n.sub '_anon' :anon\n.local pmc colons, split, epoch\ncolons = get_root_global ['_tcl'], 'colons'\n split = get_root_global ['parrot'; 'PGE::Util'], 'split'\n epoc..., pasm_file=0, error_message=0xb6f4) at compilers/imcc/ parser_util.c:641 #7 0x0005b717 in imcc_compile_pir_ex (interp=0x26003b0, s=0x2897600 .HLL 'Tcl', ''\n.namespace \n.sub '_anon' :anon\n.local pmc colons, split, epoch\ncolons = get_root_global ['_tcl'], 'colons'\nsplit = get_root_global ['parrot'; 'PGE::Util'], 'split'\nepoc...) at compilers/imcc/parser_util.c:751 #8 0x000c90c7 in pcf_P_Jt (interp=0x26003b0, self=0x27fa8ac) at src/ nci.c:2642 #9 0x00049c30 in Parrot_NCI_invoke (interp=0x26003b0, pmc=0x27fa8ac, next=0x31243a4) at ./src/pmc/nci.pmc:163 #10 0x000f336f in Parrot_Compiler_invoke (interp=0x26003b0, pmc=0x27fa8ac, code_ptr=0x31243a4) at ./src/pmc/compiler.pmc:38 #11 0x0005d88b in Parrot_invokecc_p (cur_opcode=0x312439c, interp=0x26003b0) at src/ops/core.ops:423 #12 0x000beb7c in runops_slow_core (interp=0x26003b0, pc=0x312439c) at src/runops_cores.c:184 #13 0x000b9c58 in runops_int (interp=0x26003b0, offset=3) at src/ interpreter.c:779 #14 0x4f06 in runops (interp=0x26003b0, offs=3) at src/ inter_run.c:88 #15 0x5177 in runops_args (interp=0x26003b0, sub=0x27f9e48, obj=0x282d460, meth=0x0, sig=0x20ade0 vP, ap=0xb9cc ??\002?Ia \002?(\005) at src/inter_run.c:202 #16 0x52a8 in Parrot_runops_fromc_args (interp=0x26003b0, sub=0x27f9e48, sig=0x20ade0 vP) at src/inter_run.c:304 #17 0x0002274f in Parrot_runcode (interp=0x26003b0, argc=2, argv=0xbb98) at src/embed.c:803 #18 0x000529ec in imcc_run_pbc (interp=0x26003b0, obj_file=0, output_file=0x0, argc=2, argv=0xbb98) at compilers/imcc/main.c:569 #19 0x00053409 in imcc_run (interp=0x26003b0, sourcefile=0xbc3a tcl.pbc, argc=2, argv=0xbb98) at compilers/imcc/main.c:766 #20 0x280e in main (argc=2, argv=0xbb98) at src/main.c:61 -- Will Coke Coleda [EMAIL PROTECTED]
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
On Fri, Jun 15, 2007 at 11:59:49AM +1000, Damian Conway wrote:
: Chas Owens asked:
:
: Would this work as well?
:
: say :to(END);
: \x{3D}begin POD
: blah blah blah
: \x{3D}end POD
: END
:
:
: Yes, except for the :to actually needing to be qq:to (which was wrong
: all the way through these examples, BTW).
Well, and the fact that it's \x[3D] these days, not \x{3D}.
Larry
Re: [perl #43219] segfault in tcl
On Thu, 14 Jun 2007 19:10:02 -0700 Will Coleda (via RT) [EMAIL PROTECTED] wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #43219] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43219 With recent updates, tcl suite is MUCH faster, but is now segfaulting in several places. No clue when it last worked. I poked around a bit in gdb. I don't have any answers or patches, but hopefully a little more information will be helpful. In Parrot_get_HLL_id, between the 31st and 32nd calls to this function, the string memory for the name string, from the name_pmc PMC, is freed. The string pointer is not updated. So, the next time around, segfault. Breakpoint 2, Parrot_get_HLL_id (interp=0x804e008, hll_name=0xb591ebb8) at src/hll.c:191 191 PMC * const hll_info = interp-HLL_info; (gdb) next 7 207 if (!string_equal(interp, name, hll_name)) (gdb) print name-strstart $28 = 0xb5607b00 106 (gdb) cont Continuing. Breakpoint 2, Parrot_get_HLL_id (interp=0x804e008, hll_name=0xb591e930) at src/hll.c:191 191 PMC * const hll_info = interp-HLL_info; (gdb) next 7 207 if (!string_equal(interp, name, hll_name)) (gdb) print name-strstart $29 = 0xb5607b00 Address 0xb5607b00 out of bounds (gdb) next Program received signal SIGSEGV, Segmentation fault. 0xb6e4824c in memcmp () from /lib/libc.so.6 Note the pointer value is the same; the first time it's valid and the string is displayed. The second time, it's out of bounds. Valgrind has some very interesting things to say about this test script, including lots of undefined data warnings, lots of accesses outside of allocated ranges, and also such gems as definitely lost: 1,476,179 bytes in 13,925 blocks. But most importantly, it tells us what freed the memory: ==4825== Invalid read of size 1 ==4825==at 0x4023080: bcmp (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==4825==by 0x42632F6: ascii_compare (ascii.c:219) ==4825==by 0x41E28B9: string_equal (string.c:1305) ==4825==by 0x422FEEF: Parrot_get_HLL_id (hll.c:207) ==4825==by 0x422FB1C: Parrot_register_HLL (hll.c:134) ==4825==by 0x4315F83: yyparse (imcc.y:525) ==4825==by 0x43208FF: compile_string (imcc.l:1153) ==4825==by 0x4332752: imcc_compile (parser_util.c:641) ==4825==by 0x4332A12: imcc_compile_pir_ex (parser_util.c:751) ==4825==by 0x423BEA5: pcf_P_Jt (nci.c:2642) ==4825==by 0x429457B: Parrot_NCI_invoke (nci.pmc:163) ==4825==by 0x427CBE2: Parrot_Compiler_invoke (compiler.pmc:38) ==4825== Address 0x7CF1DAC is 1,432,964 bytes inside a block of size 1,945,416 free'd ==4825==at 0x40214AC: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==4825==by 0x41D794C: mem__internal_free (memory.c:200) ==4825==by 0x426242A: compact_pool (resources.c:421) ==4825==by 0x4261F5A: mem_allocate (resources.c:147) ==4825==by 0x4262A3D: Parrot_allocate_string (resources.c:724) ==4825==by 0x41E1888: string_make_direct (string.c:647) ==4825==by 0x41E1DA1: string_concat (string.c:899) ==4825==by 0x41E1489: string_append (string.c:439) ==4825==by 0x43013B6: Parrot_scalar_i_concatenate_str (scalar.pmc:1182) ==4825==by 0x4257343: mmd_dispatch_v_ps (mmd.c:456) ==4825==by 0x41119C6: Parrot_infix_ic_p_s (math.ops:74) ==4825==by 0x41E6026: runops_slow_core (runops_cores.c:184) I don't know *why* it was freed, but at least that tells us *where*. And parrot -G runs great, of course. Mark
Re: [perl #43219] segfault in tcl
On Thursday 14 June 2007 22:17:25 Mark Glines wrote: I poked around a bit in gdb. I don't have any answers or patches, but hopefully a little more information will be helpful. In Parrot_get_HLL_id, between the 31st and 32nd calls to this function, the string memory for the name string, from the name_pmc PMC, is freed. The string pointer is not updated. So, the next time around, segfault. That's consistent with what I saw, too. Valgrind has some very interesting things to say about this test script, including lots of undefined data warnings, lots of accesses outside of allocated ranges, and also such gems as definitely lost: 1,476,179 bytes in 13,925 blocks. Here's my Valgrind alias: alias vgp='valgrind --suppressions=~/dev/parrot/tools/dev/parrot.supp \ --num-callers=500 --leak-check=full --leak-resolution=high \ --show-reachable=yes parrot --leak-test' That ought to help. -- c
