Re: PMC_data() harmful?
On Tuesday 10 July 2007 18:37:59 Will Coleda wrote:
Discussion on IRC today about how we can improve the state of the GC
system. One of the things that came up was that perhaps we shouldn't
be poking inside PMC guts outside of src/*pmc/: instead, we should be
using vtable access.
I currently see ~500 instances where we use PMC_data() outside pmc
code (after a build, so probably some generated code in there.)
I think if we had an example of how these should be fixed, that'd
help others contribute, so, lets pick one and dissect it.
Here's a function from src/key.c :
/*
FUNCDOC: key_next
Returns the next key if Ckey is in a sequence of linked keys.
*/
PARROT_API
PMC *
key_next(SHIM_INTERP, PMC *key /*NN*/)
{
return key-pmc_ext ? (PMC *)PMC_data(key) : NULL;
}
Is this in need of fixing? If so, how? If not, is there a better
function to show off what needs fixing?
This isn't a great example, as the guts of hashes and keys and iterators are
all over various files instead of nicely encapsulated in .pmc files.
A better example may be PMC_cont(), strewn about ops, other PMCs, the calling
conventions, and the like. Unraveling that will be tricky.
-- c
Re: Project Idea: Perl 6 Syntax Explainer
Larry Wall wrote:
On Tue, Jul 10, 2007 at 04:37:13PM -0700, Dave Whipp wrote:
: One approach would simply be to edit Perl-6.0.0-STD.pm and add some
: markup. To pick a token at random:
:
: =p6explain *
: An asterix in a version expression matches any version
: =end
: token whatever { '*' {*} }
Indeed, the example you picked indicates how important context
will be. There are many different uses of '*', and a p6explain that
simply lists all the possible meanings will be very nearly useless.
I hope it's not (nearly) useless.
My intention was the following: in most cases the meaning of an operator
is very obvious (for example * as the multiplication operator), there
are just some cases where the meaning is not obvious:
sub foo([EMAIL PROTECTED])
now instead of grep'ping through 16 Synopsis with 24895 lines (with 248
matches in Operator.pod and 189 in Syntax.pod), I'd like to have 2 or
three result pages that list all possible meanings of *. I don't want to
have a full Perl 6 program explained, just the operators/symbols that I
don't know about right now.
You really need to parse the surrounding text to have any idea what
the * means. And a big reason to make the grammar available (including
all the user-defined bits) is so that nobody ever has to reinvent PPI
for Perl 6. A p6 explainer that is sensitive to grammar mutations
really needs to do its work by annotating an entire compilation unit
and then making that information available to something resembling
an IDE. I realize that's a long term goal.
Which leads me to the question: how should the data be assembled so that
it could be used in such a way?
Would it be enough to store the name of the token, along with the
description?
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: Add a --ccflags-append option to Configure.pl?
On 11/07/07, Andy Dougherty [EMAIL PROTECTED] wrote: On Wed, 11 Jul 2007, Paul Cochrane wrote: To be able to configure parrot to build with icc (the intel C compiler) one currently needs a command line which looks like this: perl Configure.pl --cc=icc --link=icc --ld=icc --ccflags=icc-header-path -no-gcc --ccwarn=-wd269 -Wall -Wcheck -w2 However, the only things which need to be specified here are: (a) the cc setting (b) the icc header path the rest is set in the linux hints file. So what's the problem you ask? Well, to get icc to see its own header files, one needs to specify the icc header path in the --ccflags option. This overwrites any settings given in the hints file. Then I'd say the hints file is broken. Unless it has good reason, the hints file shouldn't normally remove command-line information. In perl5 hints, the usual idiom is to add to existing ccflags, not replace them. It would be great to give a configure command like this instead: perl Configure.pl --cc=icc --ccflags-append=icc-header-path For consistency, I would think there should also be an -append option for every Configure variable. (Whether you wish to write it as --ccflags-append=icc_header_path or --append ccflags=icc_header_path or some other syntax is, at some level, irrelevant. What I'm saying is that instead of introducing an append syntax specific to ccflags, you should introduce a generic append syntax and then use it (if needed) for ccflags. That's a really good idea, and works far better in general. :-) I'm also advocating revising the hints file so the append syntax isn't needed! The problem doesn't really reside in the hints file, as the relevant settings are appended there. What happens is that in the Crunstep() method of config/inter/progs.pm all settings set on the command line overwrite (with the help of the Cintegrate() method; see lib/Parrot/Configure/Step.pm) any other settings already worked out by the hints. Should I then just alter the Cintegrate() method to append any settings on the command line to those added in the hints? At present, if any new settings are passed to Cintegrate() then they replace and old settings. Is this a good idea? This changes the current functionality quite a bit, which is something I was wanting to avoid. So, what is the general feeling? Should we add an --append flag_name=extra_settings option, or should we change the way Cintegrate() behaves so as instead of replacing old values with new, it actually goes through and integrates them as its name suggests? Paul
Re: Project Idea: Perl 6 Syntax Explainer
Dave Whipp wrote:
Moritz Lenz wrote:
You're probably right about that, but somebody who writes his own macros
and operators probably doesn't need such a tool anyway. And should write
very good documentation, otherwise he has lost outright.
(I was thinking that your tool would provide a mechanism for them to
provide that very good documentation)
Let's hope it does that some day ;)
It was not my original goal, but it's quite tempting ;)
I think the way to approach it would be to define a
POD6 dialect what provides the necessary markup. The standard grammar
would contain this, as would things like prelude. But anyone would be
able to add it to any code they distribute so as to provide more
comprehensive debug info.
Of course that would be the best solution, but I don't see how I can
implement that soonish. Do you have good idea how to do it?
One approach would simply be to edit Perl-6.0.0-STD.pm and add some
markup. To pick a token at random:
=p6explain *
An asterix in a version expression matches any version
=end
token whatever { '*' {*} }
You convinced me, in-place documentation is probably the best.
This would have the advantage of better documenting the meaning of all
the tokens/rules in the grammar file, which isn't always immediately
obvious from reading it.
Damian's POD Parser can probably do much of the work of actually finding
the p6explain blocks. Establishing a formal link between these and the
token/rule might be more work; but probably isn't necessary, except for
linting purposes.
Which leads me to the question how to do the annotation.
First of all I hope there are no objections against fiddling with STD.pm.
My approach so far (see http://svn.pugscode.org/pugs/misc/perlhints/)
has been to write blocks for each token like so:
key: *
name: Regex Quantifier *
dsl: Regex
syn: token*
desc: matches token zero or more times
ex: 'ab'* # matches the empty string, ab, abab, ababab, ...
link: S05:somwhere
(key: the character(s) that the token stands for; name: a uniq name;
dsl: the domain-specific language the token occurs in (empty if plain
p6; syn: synopsis. desc: description (one to three lines usually); ex:
example; link: reference to the official specs).
It has the advantage of being easily parsable, less character/line noise
and no need for any escapes (expect newlines).
However it is not very PODish, so I'd like to ask for other opinions on
the used markup.
With the link: thing we could actually generate smartlinks that tell you
which part of the synopsis are parsed by which token in STD.pm (Agent
Zhang, are you paying attention? ;-). Do you think that would be desirable?
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: Project Idea: Perl 6 Syntax Explainer
Moritz Lenz wrote:
Dave Whipp wrote:
One approach would simply be to edit Perl-6.0.0-STD.pm and add some
markup. To pick a token at random:
=p6explain *
An asterix in a version expression matches any version
=end
token whatever { '*' {*} }
You convinced me, in-place documentation is probably the best.
This would have the advantage of better documenting the meaning of all
the tokens/rules in the grammar file, which isn't always immediately
obvious from reading it.
Damian's POD Parser can probably do much of the work of actually finding
the p6explain blocks. Establishing a formal link between these and the
token/rule might be more work; but probably isn't necessary, except for
linting purposes.
Which leads me to the question how to do the annotation.
First of all I hope there are no objections against fiddling with STD.pm.
My approach so far (see http://svn.pugscode.org/pugs/misc/perlhints/)
has been to write blocks for each token like so:
key: *
name: Regex Quantifier *
dsl: Regex
syn: token*
desc: matches token zero or more times
ex: 'ab'* # matches the empty string, ab, abab, ababab, ...
link: S05:somwhere
A problem with this might be the lack of multiple language support -
especially for the description.
I'm not sure if you would want docs expanded to huge size to fit every
language in the sun and beyond, but can see real strengths in allowing
it to be inline in order to get it done.
What might be nice ( from my perspective - others may hate it ) is
assigning a URI to each unique instance, so that multiple language
support could be tagged on afterwards, and it could also help with the
link section ( or replace it by reversing the link to many to one rather
than one to one ) - if the synopsis were adjusted to reference these
URIs then the linking info would flow back in the other direction?
The key for your index would then become the URI, and the database could
then be hosted elsewhere ( of course, developers may wish to make there
code contain something similar to the above to help with creating your
data ? )
Steve
Re: Project Idea: Perl 6 Syntax Explainer
Steve Pitchford wrote:
Moritz Lenz wrote:
Dave Whipp wrote:
One approach would simply be to edit Perl-6.0.0-STD.pm and add some
markup. To pick a token at random:
=p6explain *
An asterix in a version expression matches any version
=end
token whatever { '*' {*} }
You convinced me, in-place documentation is probably the best.
This would have the advantage of better documenting the meaning of all
the tokens/rules in the grammar file, which isn't always immediately
obvious from reading it.
Damian's POD Parser can probably do much of the work of actually finding
the p6explain blocks. Establishing a formal link between these and the
token/rule might be more work; but probably isn't necessary, except for
linting purposes.
Which leads me to the question how to do the annotation.
First of all I hope there are no objections against fiddling with STD.pm.
My approach so far (see http://svn.pugscode.org/pugs/misc/perlhints/)
has been to write blocks for each token like so:
key: *
name: Regex Quantifier *
dsl: Regex
syn: token*
desc: matches token zero or more times
ex: 'ab'* # matches the empty string, ab, abab, ababab, ...
link: S05:somwhere
A problem with this might be the lack of multiple language support -
especially for the description.
I'm not sure if you would want docs expanded to huge size to fit every
language in the sun and beyond, but can see real strengths in allowing
it to be inline in order to get it done.
Right. Since English is unofficially Perl's official human language (the
specs are in English), it might be a good idea to keep the English
version in place, and find a good way to synchronize other languages.
For example the combination of 'name' and 'key' (or token name and key)
should be uniq for each token, so it could be handled as a reference for
other human languages.
What might be nice ( from my perspective - others may hate it ) is
assigning a URI to each unique instance, so that multiple language
support could be tagged on afterwards, and it could also help with the
link section ( or replace it by reversing the link to many to one rather
than one to one ) - if the synopsis were adjusted to reference these
URIs then the linking info would flow back in the other direction?
I don't like the idea of fiddling with the synopsis (because it makes
my project seem official, which makes me responsible which I don't
like atm ;-). And with URIs you always have to take care that they are
not broken. I know that the same applies for using name+key as a
reference/anchor, but it's not a problem for the English version at least.
The key for your index would then become the URI, and the database could
then be hosted elsewhere ( of course, developers may wish to make there
code contain something similar to the above to help with creating your
data ? )
I hope they will, because I don't think I can handle that alone, and my
English might not be good enough for that purpose.
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: Project Idea: Perl 6 Syntax Explainer
Moritz Lenz wrote: Steve Pitchford wrote: Moritz Lenz wrote: First of all I hope there are no objections against fiddling with STD.pm. My approach so far (see http://svn.pugscode.org/pugs/misc/perlhints/) has been to write blocks for each token like so: key: * name: Regex Quantifier * dsl: Regex syn: token* desc: matches token zero or more times ex: 'ab'* # matches the empty string, ab, abab, ababab, ... link: S05:somwhere A problem with this might be the lack of multiple language support - especially for the description. I'm not sure if you would want docs expanded to huge size to fit every language in the sun and beyond, but can see real strengths in allowing it to be inline in order to get it done. Right. Since English is unofficially Perl's official human language (the specs are in English), it might be a good idea to keep the English version in place, and find a good way to synchronize other languages. For example the combination of 'name' and 'key' (or token name and key) should be uniq for each token, so it could be handled as a reference for other human languages. What might be nice ( from my perspective - others may hate it ) is assigning a URI to each unique instance, so that multiple language support could be tagged on afterwards, and it could also help with the link section ( or replace it by reversing the link to many to one rather than one to one ) - if the synopsis were adjusted to reference these URIs then the linking info would flow back in the other direction? I don't like the idea of fiddling with the synopsis (because it makes my project seem official, which makes me responsible which I don't like atm ;-). And with URIs you always have to take care that they are not broken. I know that the same applies for using name+key as a reference/anchor, but it's not a problem for the English version at least. Sorry - I should have been clearer. I was refeering to using URIs in a similar way to xml for namespace declaration - http://en.wikipedia.org/wiki/XML_Namespace So that there doesn't actually need to be anything to link to, and broken links are therefore irrelevant - it just seems a nice way of assigning a unique code to all of these operators ( which might offer advatages to the name + key combination ) I can see your point on the synopsis and appreciatte that it isn't the right time to be considering any modifications. Steve
Re: Project Idea: Perl 6 Syntax Explainer: Status
A small status update: The name of the project currently is 'perlhints', as suggested by pmurias++ and [particle]++. Some files can be found in the pugs repository in misc/perlhints/ (repository URL: http://svn.pugscode.org/pugs/misc/perlhints/) There is a command line interface called perlhints5.pl (implemented in p5), and a very basic web interface at http://moritz.faui2k3.org/perlhints/, for example http://moritz.faui2k3.org/perlhints/?q=*. What it lacks mostly is the data ;) Currently all data is read from a single flat file. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: Project Idea: Perl 6 Syntax Explainer
On Tue, Jul 10, 2007 at 12:43:05PM +0200, Moritz Lenz wrote: considering the vast number of Operators and the like, I had the idea to implement a tool where you can enter a small piece of p6 syntax, and it explains what that might mean. (like a perldoc -f for operators/syntax elements instead of functions) I proposed a perldoc -f-a-like for operators a coupla years ago on p5p. People thought it was a good idea. I even started work on it, but stopped before I got very far cos other stuff intervened. I should get back on it. -- David Cantrell | Reality Engineer, Ministry of Information Nuke a disabled unborn gay baby whale for JESUS!
[perl #43230] parrot porters isn't quite the official mailing list.
This has been resolved. subscription requests to [EMAIL PROTECTED] will now be handled by perl6-internals. (parrot-porters is basically just an alias to the old list name.) Thanks for the report. On Sat Jun 16 10:56:21 2007, gdr !-- x -- at go2.pl wrote: Hi, I tried to subscribe to the Parrot list, however the address supplied doesn't work (parrot-porters-subscribe !-- x -- at perl.org ) - the mails keep bouncing. I've been informed on IRC that the proper address is perl6-internals-subscribe !-- x -- at perl.org. Would be nice if this is updated :)
[perl #31166] [TODO] JIT - Make it work on more architectures
This ticket is too vague. If there's a particular architecture we need to target, open a ticket for it. On Sun Aug 15 18:14:19 2004, coke wrote: Make it work on more architectures (from the TODO file)
[perl #37068] [TODO] repair JAPHs in 'examples/japh'
On Mon Dec 26 02:59:20 2005, bernhard wrote: 4 out of 17 JAPHs are working again. I suppose that some of the remaining 13 are easily fixable, while others are obsolete. Any JAPHs that aren't working should be removed.
Checking for unused results
I'm decorating like crazy with PARROT_WARN_UNUSED_RESULT. It's turning up interesting problems. Return codes are getting ignored where I am surprised to see them getting ignored, such as: src/pmc/array.c: In function ‘Parrot_Array_class_init’: src/pmc/array.c:1776: warning: ignoring return value of ‘make_bufferlike_pool’, declared with attribute warn_unused_result src/pmc/array.c:1777: warning: ignoring return value of ‘make_bufferlike_pool’, declared with attribute warn_unused_result src/stm/backend.c: In function ‘Parrot_STM_alloc’: src/stm/backend.c:177: warning: ignoring return value of ‘make_bufferlike_pool’, declared with attribute warn_unused_result src/io/io.c: In function ‘PIO_flush’: src/io/io.c:735: warning: ignoring return value of ‘PIO_flush_down’, declared with attribute warn_unused_result src/io/io.c: In function ‘PIO_reads’: src/io/io.c:774: warning: ignoring return value of ‘PIO_read_down’, declared with attribute warn_unused_result src/io/io_buf.c src/io/io_buf.c: In function ‘PIO_buf_seek’: src/io/io_buf.c:800: warning: ignoring return value of ‘PIO_seek_down’, declared with attribute warn_unused_result Please run your Configure.pl with -DHASATTRIBUTE_WARN_UNUSED_RESULT, assuming you have a reasonably recent GCC, and take a look at the warnings it kicks out. See what turns up. Eventually GCC sniffing at Configure.pl time will figure out whether HASATTRIBUTE_WARN_UNUSED_RESULT is relevant or not. For now, you have to add it manually. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
[perl #43815] pmc2c generates wrong #line numbers for languages/perl6/src/pmc/perl6str.pmc
# New Ticket Created by Mark Glines
# Please include the string: [perl #43815]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43815
perl6str.pmc has an extra-long pmclass statement, which
breaks the #line numbering when pmc2c generates the .c file.
The line numbers are wrong in the generated perl6str.c file.
get_string() starts on line 160, but the generated .c file lists it as
starting on line 154. get_number() starts on line 63, but is #listed
as starting on line 57.
The pmclass statement looks like:
pmclass Perl6Str
extends String
does string
dynpmc
group perl6_group
hll Perl6
maps String {
Interestingly, if I take all of the crud in this pmclass statement and
stick them all on one line, like this:
pmclass Perl6Str extends String does string dynpmc group perl6_group hll Perl6
maps String {
...The #line numbers do not change at all (get_string in the .c file is
still #lined to 154), but now the get_string implementation in the .pmc
file is also on line 154, so everything lines up.
So my guess is, the pmclass statement parser consumes the extra newlines
and doesn't update the line counter, or something.
Mark
Re: [perl #43815] pmc2c generates wrong #line numbers for languages/perl6/src/pmc/perl6str.pmc
On Wed, 11 Jul 2007 23:49:34 -0700
Mark Glines (via RT) [EMAIL PROTECTED] wrote:
The pmclass statement looks like:
pmclass Perl6Str
extends String
does string
dynpmc
group perl6_group
hll Perl6
maps String {
Interestingly, if I take all of the crud in this pmclass statement and
stick them all on one line, like this:
pmclass Perl6Str extends String does string dynpmc group perl6_group
hll Perl6 maps String {
...The #line numbers do not change at all (get_string in the .c file
is still #lined to 154), but now the get_string implementation in
the .pmc file is also on line 154, so everything lines up.
I don't have a fix (yet), but here's a patch to add a couple of tests
for it. One test makes sure it emits the right #line when a complex
pmclass statement is all on one line, and the second makes sure #line is
adjusted when pmclass *isn't* on the same line.
The first test succeeds, the second one fails.
Mark
=== t/tools/pmc2c.t
==
--- t/tools/pmc2c.t (revision 21436)
+++ t/tools/pmc2c.t (local)
@@ -28,7 +28,7 @@
use Fatal qw{open close};
use Test::More;
-use Parrot::Test tests = 11;
+use Parrot::Test tests = 13;
use Parrot::Config;
my $pmc2c = join $PConfig{slash}, qw(. tools build pmc2c.pl);
@@ -181,6 +181,28 @@
);
END_C
+pmc2c_output_like( 'END_PMC', 'END_C', 'maps' );
+pmclass a hll dale maps Integer {
+void init() {
+}
+}
+END_PMC
+Parrot_a_init(Interp *interp, PMC *pmc)
+#line 2
+END_C
+
+pmc2c_output_like( 'END_PMC', 'END_C', 'maps' );
+pmclass a
+hll dale
+maps Integer {
+void init() {
+}
+}
+END_PMC
+Parrot_a_init(Interp *interp, PMC *pmc)
+#line 4
+END_C
+
# Local Variables:
# mode: cperl
# cperl-indent-level: 4
[perl #43823] [CAGE] Make the GCC hints sniff out the GCC capabilities
# New Ticket Created by Andy Lester # Please include the string: [perl #43823] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43823 Instead of trying to maintain a monstrous list of what versions of GCC have what capabilities, use some simple empirical tests to figure it out at configure time. This is a solved problem that needs to be brought over. P5 has done this for a while, and I've added the functionality for all the - DHAS_ATTRIBUTE_* flags myself in P5-land. Now we need to do it over in Parrot-land. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
[perl #43827] Parrot_Context_info's file field is dangerous
# New Ticket Created by Andy Lester # Please include the string: [perl #43827] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43827 I think we may have a memory leak or misfreeing of constants with Parrot_Context_info. The file field in Parrot_Context_infostr seems to be freed, just by printing out the state. It's also not clear if it's a const char*, or a malloced one. I need to get down to the bottom of it, and instrument appropriately. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
[perl #43835] Remove Regexp::Common requirement
# New Ticket Created by Will Coleda # Please include the string: [perl #43835] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43835 Followup from RT#31785 - Regexp::Common is used by tools/dev/extract_file_descriptions.pl: this dependency is easy enough to break by generating the RE on a machine with the module and then adding it to the code (with a note where it came from.)
[perl #43837] Remove tools/dev/run_indent.pl
# New Ticket Created by Will Coleda # Please include the string: [perl #43837] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43837 This file seems to be obsoleted by t/codingstd/c_indent.t; It also relies on the non-standard module C::Scan.
[perl #43829] [CAGE] Headerizer should check for appropriate decorations
# New Ticket Created by Andy Lester # Please include the string: [perl #43829] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43829 Headerizer should check that every pointer argument has NOTNULL() or NULLOK(). Headerizer should also check that funcs that return pointers are decorated with PARROT_CAN(NOT)?_RETURN_NULL. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
[perl #43831] [CAGE] Document how we do function decoration
# New Ticket Created by Andy Lester # Please include the string: [perl #43831] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43831 -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
[perl #43833] [CAGE] object.c built incorrectly
# New Ticket Created by Andy Lester # Please include the string: [perl #43833] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43833 object.c(153) : warning C4098: 'Parrot_Object_add_attribute' : 'void' function returning a value -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
[perl #43839] string_chopn should be split up
# New Ticket Created by Andy Lester # Please include the string: [perl #43839] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43839 There should be string_chopn and string_chopn_inplace instead of an inplace flag. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: PMC_data() harmful?
chromatic wrote:
PARROT_API
PMC *
key_next(SHIM_INTERP, PMC *key /*NN*/)
{
return key-pmc_ext ? (PMC *)PMC_data(key) : NULL;
}
Is this in need of fixing? If so, how? If not, is there a better
function to show off what needs fixing?
This isn't a great example, as the guts of hashes and keys and iterators are
all over various files instead of nicely encapsulated in .pmc files.
It's a great example, but of a different problem. Namely, those guts
should be moved into the .pmc files.
A really simple example of the kind of refactor that needs to happen is
one in the code I'm working on for objects. In src/pmc.c in the
'pmc_type' function, there's a section that retrieves a class entry from
the classname_hash, then calls:
return PMC_int_val((PMC*) item);
to get the integer value from the class entry PMC. What it should call is:
return VTABLE_get_integer(interp, item);
Both return the same answer, but the second doesn't break the
encapsulation boundary. (The second also doesn't depend on data being
stored in the PMC's struct union cache, which is a definite plus if we
deprecate that storage slot.)
Allison
[PATCH] [CLEANUP] Re: [perl #43815] pmc2c generates wrong #line numbers for languages/perl6/src/pmc/perl6str.pmc
On Thu, 12 Jul 2007 18:31:43 -0700
Mark Glines [EMAIL PROTECTED] wrote:
So here's a patch. It's a bit quick dirty, but it'll work. A
cleaner solution would probably involve adding a fourth returned
parameter from parse_flags: a line-count. Ends up being the same
thing, really... just keeps the knowledge of the pmclass line's format
localized to the parse_flags() function.
...and here's the aforementioned cleaner version. Please review and
apply.
Mark
=== lib/Parrot/Pmc2c/Parser.pm
==
--- lib/Parrot/Pmc2c/Parser.pm (revision 21442)
+++ lib/Parrot/Pmc2c/Parser.pm (local)
@@ -67,10 +67,10 @@
sub parse_pmc {
my ( $code, $opt ) = @_;
-my ( $pre, $classname, $flags_ref ) = parse_flags( \$code );
+my ( $pre, $classname, $flags_ref, $pmclass_lines ) = parse_flags( \$code );
my ( $classblock, $post ) = extract_balanced($code);
-my $lineno = 1 + count_newlines($pre);
+my $lineno = 1 + count_newlines($pre) + $pmclass_lines;
$classblock = substr( $classblock, 1, -1 );# trim out the { }
my ( @methods, %meth_hash, $class_init );
@@ -174,13 +174,17 @@
=item *
-the name of the class; and
+the name of the class;
=item *
a hash ref containing the flags associated with the class (such as
-Cextends and Cdoes).
+Cextends and Cdoes); and
+=item *
+
+a count of the newlines we consumed while parsing this statement.
+
=back
BComments: Called internally by Cparse_pmc().
@@ -197,10 +201,11 @@
my %has_value = map { $_ = 1 } qw(does extends group lib hll maps);
my ( %flags, $parent_nr );
+my $skipped_lines = 0;
# look through the pmc declaration header for flags such as noinit
-while ( $$c =~ s/^\s*(\w+)//s ) {
-my $flag = $1;
+while ( $$c =~ s/^(\s*)(\w+)//s ) {
+my ($whitespace, $flag) = ($1, $2);
if ( $has_value{$flag} ) {
$$c =~ s/^\s+(\w+)//s
or die Parser error: no value for '$flag';
@@ -210,6 +215,7 @@
else {
$flags{$flag} = 1;
}
+$skipped_lines += count_newlines($whitespace);
}
# setup some defaults
@@ -218,7 +224,7 @@
$flags{does}{scalar} = 1 unless $flags{does};
}
-return $pre, $classname, \%flags;
+return $pre, $classname, \%flags, $skipped_lines;
}
=head3 Cextract_balanced()
[PATCH] Re: [perl #43815] pmc2c generates wrong #line numbers for languages/perl6/src/pmc/perl6str.pmc
On Thu, 12 Jul 2007 09:26:25 -0700
Mark Glines [EMAIL PROTECTED] wrote:
Interestingly, if I take all of the crud in this pmclass statement
and stick them all on one line, like this:
pmclass Perl6Str extends String does string dynpmc group perl6_group
hll Perl6 maps String {
...The #line numbers do not change at all (get_string in the .c file
is still #lined to 154), but now the get_string implementation in
the .pmc file is also on line 154, so everything lines up.
I don't have a fix (yet), but here's a patch to add a couple of tests
for it. One test makes sure it emits the right #line when a complex
pmclass statement is all on one line, and the second makes sure #line
is adjusted when pmclass *isn't* on the same line.
The first test succeeds, the second one fails.
In the pmc2c parser, parse_pmc() calls parse_flags() to parse the
pmclass line, and sort out all of the necessary attributes.
parse_flags() consumes everything from pmclass to {, and parse_pmc
assumes that it was all on one line, and just uses the the magic number
1 to represent that line.
So here's a patch. It's a bit quick dirty, but it'll work. A
cleaner solution would probably involve adding a fourth returned
parameter from parse_flags: a line-count. Ends up being the same
thing, really... just keeps the knowledge of the pmclass line's format
localized to the parse_flags() function.
Mark
=== lib/Parrot/Pmc2c/Parser.pm
==
--- lib/Parrot/Pmc2c/Parser.pm (revision 21442)
+++ lib/Parrot/Pmc2c/Parser.pm (local)
@@ -67,10 +67,14 @@
sub parse_pmc {
my ( $code, $opt ) = @_;
+my $lineno = 1;
+if($code =~ /(pmclass[^{]+{)/) {
+$lineno += count_newlines($1);
+}
my ( $pre, $classname, $flags_ref ) = parse_flags( \$code );
my ( $classblock, $post ) = extract_balanced($code);
-my $lineno = 1 + count_newlines($pre);
+$lineno += count_newlines($pre);
$classblock = substr( $classblock, 1, -1 );# trim out the { }
my ( @methods, %meth_hash, $class_init );
