RT #41858, reasonable set of rules for splint (was: Re: Parrot Bug Summary)
On 16 Apr 2007 13:00:27 - Parrot Bug Summary <[EMAIL PROTECTED]> wrote: > 41858 [CAGE] Make a reasonable set of rules for splint Hi, Random cage cleaner here. At Andy Lester's suggestion, I've begun working on this splint stuff. So everything below is all his fault. :) I found that "make splint" is currently very dependent on the machine you run it on. I'm running it on Gentoo Linux, and so, Parrot gets built with lots of unixish features (due to their being enabled in has_header.h). For instance, my platform has PARROT_HAS_HEADER_ARPAINET defined, so gets included. Unfortunately, splint barfs on this, because my arpa/inet.h isn't compatible with the +posixstrictlibs flag (because of a lack of in_addr_t typedef in splint's posix lib, I think). Further on, I found splint couldn't parse my pthread.h either, so I eventually gave it a +skip-sys-headers, which got a lot farther. I battled against this for a while, and found this small set of changes (see the attached diff) were helpful to get the majority of the sourcefiles parsing correctly with splint. Unfortunately, I had to turn +posixstrictlibs into +unixstrictlibs to get it to work at all on my machine... which is not the most portable thing to do. Do you think its possible to use a "dummy" config.h and has_header.h and stuff, for the purposes of splint portability? One that doesn't enable any platform-specific stuff, and thus, will generate the same results on any platform? Splint seems to like using its own internal header-library (and it has a few different ones... ISO, POSIX, UNIX), and barfs on my system headers in several places, mostly due to conflicts between its library and my reality. I had to blacklist the following files, because splint could not parse them for whatever reason: compilers/imcc/imcparser.c compilers/imcc/instructions.c compilers/imcc/parser_util.c src/charset/unicode.c src/encodings/ucs2.c src/encodings/utf16.c src/exec_save.c src/io/io.c src/misc.c src/ops/core_ops_cg.c src/ops/core_ops_cgp.c src/pmc/bigint.c src/spf_render.c src/spf_vtable.c src/string_primitives.c But the remaining 177 C source files went through okay, with the following warning summary: Error TypeReported Suppressed === = nullderef0 512 nullpass 0 350 nullret 0 617 nullstate0 363 nullassign 0 148 usedef 0 170 compdef 03858 initallelements 13 0 incondefs1 0 realcompare224 21 unsignedcompare 0 17 nullptrarith 0 7 bitwisesigned 4354 58 shiftnegative0 78 shiftimplementation 0 764 sizeoftype 02181 fixedformalarray 4 0 formalarray 0 22 boolops 01286 predboolint 0 14 predboolptr 01096 predboolothers 837 0 abstract 0 9 mustfreefresh03229 mustfreeonly 04737 usereleased 0 138 compdestroy 0 24010 branchstate 0 958 compmempass 01681 stackref 9 2 dependenttrans 0 23 onlytrans0 719 onlyunqglobaltrans 0 3 temptrans03409 kepttrans0 248 immediatetrans 0 49 statictrans 0 41 unqualifiedtrans 0 419 staticinittrans 0 2 readonlytrans0 721 aliasunique 1 0 mayaliasunique 0 8 observertrans0 35 modobserver 2 0 globs0 271 evalorder5 0 evalorderuncon 0 131 casebreak01251 misscase 0 1 looploopbreak0 35 loopswitchbreak 0 430 switchswitchbreak0 44 looploopcontinue 0 14 ifempty 3 0 noeffect 2 0 retvalother478 103 retvalint0 513 macroredef 88 0 macroparens 0 1 sefuncon 0 5 namechecks 157 167 isoreserved 01008 fcnuse 78 0 par
lint/splint Makefile stuff
Hi,
[08:07] <@particle> hrmm i think i have splint on my laptop
[08:08] <@particle> so i can probably test it on win32/msvc
[09:10] <@particle> the splint target uses sed? oh, we've got some work
do do
[09:14] < Infinoid> I've been using a little perlscript to remove
source filenames from the list that exist in a blacklist file, just to
get splint to limp along well enough to give me a warning summary
[09:15] <@particle> well, i need to convert that sed to perl, so it'll
work portably
[09:16] < Infinoid> that's a good idea
[09:17] <@particle> it's using `echo ...` too, that'll have to go
...And the famous last words:
[09:18] < Infinoid> if you have more important things to work on, I'm
happy to do this cleanup, but it'll have to wait until I get off of
work tonight :)
So, I worked on the splint Makefile rules tonight. I only speak GNU
make, so I'm not really sure which parts are portable and which parts
aren't, so I'm kind of stabbing blindly in the dark and hoping for some
feedback if I've gotten something wrong.
There are a few problems I tried to fix:
1. Presumably non-portable shell escapes
2. Usage of awk, which might not exist on the target machine
3. Presumably the "lint" target should be updated to test the same
sources as "splint"
4. These targets should depend on sources existing, they do not depend
on the $(PARROT) binary
I'm not really sure whether shell escapes are allowed with non-GNU
make, so I actually rolled two patches: one with shell escapes, one
without.
The non-shell-escapes version should be more portable, but it's more
intrusive, thus a bigger, uglier patch, and more maintenance overhead.
Basically, the strategy for this one is to maintain a list of C sources
alongside the object lists. So the static lists have become two lists,
and the autogenerated stuff ends up generating two sets of filenames.
See attached splint_sources_list_try1.diff.
However, if $(shell foo) is portable, this change gets easier: just do
a search & replace, to change the .o extension (except that we ought to
use $(O) instead) into a .c extension. But I did it with perl this
time, because we know that's already installed. (At least, I don't
think you can configure Parrot without it.) See attached
splint_sources_list_try2.diff.
Finally, I changed the splint:, splint2: and lint: rules to use the
lists. Previously, the lint rule just ran on "src/*.c", and
splint/splint2 did an ugly `echo $(O_FILES) | sed ...` type of thing.
And presumably you'd want to run lint on the same list of sources splint
gets run on. (I don't actually have a lint command, but it seems
logical to me.)
I should mention I initially considered using
Parrot::Distribution->get_c_language_files(), but that also returned C
sources for platforms other than my own, and splint broke when trying
to read a darwin-specific file, which couldn't find its header files on
my linux box. So the goal here was to obtain a list of sources which
are actually relevant for the current build environment.
Anyway, if either of these patches seem useful, please apply whichever
one seems more sensible.
Mark
=== config/auto/cgoto.pm
==
--- config/auto/cgoto.pm (revision 20103)
+++ config/auto/cgoto.pm (local)
@@ -47,7 +47,8 @@
if ($test) {
$conf->data->set(
TEMP_cg_h => '$(INC_DIR)/oplib/core_ops_cg.h $(INC_DIR)/oplib/core_ops_cgp.h',
-TEMP_cg_c => <<'EOF',
+TEMP_cg_c => '$(OPS_DIR)/core_ops_cg.c $(OPS_DIR)/core_ops_cgp.c', # runops_cores.c is apparently not built at the moment
+TEMP_cg_compile => <<'EOF',
# generated by config/auto/cgoto.pm
$(OPS_DIR)/core_ops_cg$(O): $(GENERAL_H_FILES) $(OPS_DIR)/core_ops_cg.c
=== config/auto/gc.pm
==
--- config/auto/gc.pm (revision 20103)
+++ config/auto/gc.pm (local)
@@ -90,19 +90,21 @@
if ( $gc =~ /^malloc(?:-trace)?$/ ) {
$conf->data->set(
-TEMP_gc_c => <<"EOF",
+TEMP_gc_compile => <<"EOF",
\$(SRC_DIR)/$gc\$(O): \$(GENERAL_H_FILES) \$(SRC_DIR)/$gc.c
\$(SRC_DIR)/res_lea\$(O): \$(GENERAL_H_FILES) \$(SRC_DIR)/res_lea.c
EOF
+TEMP_gc_c => "\$(SRC_DIR)\/$gc.c \$(SRC_DIR)/res_lea.c",
TEMP_gc_o => "\$(SRC_DIR)\/$gc\$(O) \$(SRC_DIR)/res_lea\$(O)",
gc_flag => '-DGC_IS_MALLOC',
);
}
elsif ( $gc eq 'libc' ) {
$conf->data->set(
-TEMP_gc_c => <<"EOF",
+TEMP_gc_compile => <<"EOF",
\$(SRC_DIR)/gc/res_lea\$(O): \$(GENERAL_H_FILES) \$(SRC_DIR)/gc/res_lea.c
EOF
+TEMP_gc_c => "\$(SRC_DIR)/gc/res_lea.c",
TEMP_gc_o => "\$(SRC_DIR)/gc/res_lea\$(O)",
gc_flag => '-DGC_IS_MALLOC',
);
@@ -110,9 +112,10 @@
else {
$gc = 'gc';
$conf->data->set(
-TEMP_gc_c => <<"EOF",
+TEMP_gc_compile => <<"EOF",
\$(SRC_DIR)/gc/resour
Re: [perl #42597] [CAGE] Add Tests for C++ and C Style
On Tue, 17 Apr 2007 18:53:32 -0700 chromatic (via RT) <[EMAIL PROTECTED]> wrote: > In particular, we need to detect: > > - variable declarations with name 'class' > - variable declarations with the name 'namespace' Hi, After r18274 was checked in, splint's warning count for this dropped from 116 lines to 35. It currently reports the following: compilers/imcc/pbc.c:953:14: Name class is a keyword or reserved word in C++ compilers/imcc/symreg.c:568:14: Name new is a keyword or reserved word in C++ compilers/imcc/symreg.h:103:20: Name namespace is a keyword or reserved word in C++ lib/Parrot/Pmc2c/PCCMETHOD.pm:402:10: Name class is a keyword or reserved word in C++ lib/Parrot/Pmc2c/PCCMETHOD.pm:402:10: Name namespace is a keyword or reserved word in C++ src/debug.c:1276:11: Name new is a keyword or reserved word in C++ src/debug.c:1688:18: Name new is a keyword or reserved word in C++ src/gc/gc_ims.c:936:50: Name new is a keyword or reserved word in C++ src/pic.c:559:25: Name class is a keyword or reserved word in C++ src/pmc/array.pmc:1228:10: Name true is a keyword or reserved word in C++ src/pmc/class.pmc:781:19: Name class is a keyword or reserved word in C++ src/pmc/class.pmc:804:19: Name class is a keyword or reserved word in C++ src/pmc/class.pmc:984:19: Name class is a keyword or reserved word in C++ src/pmc/default.c:2249:54: Name class is a keyword or reserved word in C++ src/pmc/delegate.c:154:57: Name class is a keyword or reserved word in C++ src/pmc/delegate.pmc:43:10: Name class is a keyword or reserved word in C++ src/pmc/delegate.pmc:67:14: Name class is a keyword or reserved word in C++ src/pmc/delegate.pmc:108:47: Name class is a keyword or reserved word in C++ src/pmc/deleg_pmc.c:54:58: Name class is a keyword or reserved word in C++ src/pmc/namespace.c:303:81: Name namespace is a keyword or reserved word in C++ src/pmc/object.pmc:27:19: Name class is a keyword or reserved word in C++ src/pmc/object.pmc:191:19: Name class is a keyword or reserved word in C++ src/pmc/pair.pmc:51:17: Name class is a keyword or reserved word in C++ src/pmc/parrotclass.pmc:111:10: Name class is a keyword or reserved word in C++ src/pmc/parrotclass.pmc:268:11: Name class is a keyword or reserved word in C++ src/pmc/parrotclass.pmc:339:11: Name class is a keyword or reserved word in C++ src/pmc/parrotobject.pmc:32:10: Name class is a keyword or reserved word in C++ src/pmc/parrotobject.pmc:89:10: Name class is a keyword or reserved word in C++ src/pmc/parrotobject.pmc:130:10: Name class is a keyword or reserved word in C++ src/pmc/parrotobject.pmc:166:10: Name class is a keyword or reserved word in C++ src/pmc/parrotobject.pmc:558:10: Name true is a keyword or reserved word in C++ src/pmc/role.pmc:90:14: Name namespace is a keyword or reserved word in C++ src/pmc/role.pmc:122:14: Name namespace is a keyword or reserved word in C++ src/pmc/scalar.pmc:1403:10: Name true is a keyword or reserved word in C++ src/pmc/string.c:577:75: Name new is a keyword or reserved word in C++ It won't be a complete list, because splint is only checking the files which A) are built on my platform, and B) I haven't blacklisted due to parse errors. But I hope it's helpful.
Re: [perl #42602] [PATCH] Cleanup of additional C++ keywords
On Wed, 18 Apr 2007 09:19:09 -0700 Steve Peters (via RT) <[EMAIL PROTECTED]> wrote: > # New Ticket Created by Steve Peters > # Please include the string: [perl #42602] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=42602 > > > > Thanks to Mark Glines email, the following appears to be the > remaining C++ keywords hanging about. Nice :) Your patch reduces the warning count further, from 35 to 9. Here's what I am getting currently: lib/Parrot/Pmc2c/PCCMETHOD.pm:402:10: Name class is a keyword or reserved word in C++ lib/Parrot/Pmc2c/PCCMETHOD.pm:402:10: Name namespace is a keyword or reserved word in C++ src/pmc/delegate.c:154:57: Name class is a keyword or reserved word in C++ src/pmc/delegate.pmc:108:47: Name class is a keyword or reserved word in C++ src/pmc/delegate.pmc:67:14: Name class is a keyword or reserved word in C++ src/pmc/parrotclass.pmc:268:11: Name class is a keyword or reserved word in C++ src/pmc/parrotclass.pmc:339:11: Name class is a keyword or reserved word in C++ src/pmc/parrotobject.pmc:32:10: Name class is a keyword or reserved word in C++ src/pmc/parrotobject.pmc:558:10: Name true is a keyword or reserved word in C++ Mark
Re: I Don't Understand The Context Allocation/Destruction Code
On Sat, 21 Apr 2007 18:24:18 -0700 chromatic <[EMAIL PROTECTED]> wrote: > Then it calculates a slot value: > > const int slot = (reg_alloc + 7) >> 3; > reg_alloc = slot << 3; > > This is where I start not to understand. Why reg_alloc + 7? Why > shift left and right by 3? To me it looks like it's just rounding up to the next 8-byte boundary. Mark
Re: I Don't Understand The Context Allocation/Destruction Code
On Sun, 22 Apr 2007 02:31:26 -0700 Mark Glines <[EMAIL PROTECTED]> wrote: > On Sat, 21 Apr 2007 18:24:18 -0700 > chromatic <[EMAIL PROTECTED]> wrote: > > Then it calculates a slot value: > > > > const int slot = (reg_alloc + 7) >> 3; > > reg_alloc = slot << 3; > > > > This is where I start not to understand. Why reg_alloc + 7? Why > > shift left and right by 3? > > To me it looks like it's just rounding up to the next 8-byte boundary. Oops, 8-slot boundary. Whatever that means. After that add and shifting stuff, slot is guaranteed to be a multiple of 8. That idiom is pretty common for cache alignment purposes and such, but I usually see it being done to a pointer value, not an integer. Well, perhaps they want the pointer to be cache-aligned. Anyway, "slot" is guaranteed to be a multiple of 8. But that entry might not exist in the array yet, so the next if() statement checks for that, and if not, does a realloc() to ensure there are now slot+1 entries, and zeroes out the new pointers. ...after that point, it gets difficult for me to understand :) Mark
Re: [perl #41168] graceful "no compiler" error message?
On Fri, 27 Apr 2007 19:57:47 -0700
"James Keenan via RT" <[EMAIL PROTECTED]> wrote:
> And (I should have asked this earlier) in what sense was the compiler
> not yet installed correctly? Was it, e.g., a standard Win32 box with
> no compiler at all?
In my case, the compiler had not yet been added to $ENV{PATH}.
Mark
Re: [perl #42533] [TODO] do not check PIR coda for languages/dotnet/src/builtins.pir
On Sun, 15 Apr 2007 05:49:06 -0700
Bernhard Schmalhofer (via RT) <[EMAIL PROTECTED]> wrote:
> languages/dotnet/src/builtins.pir is a generated file, so
> editor hints are not very useful there.
>
> So t/codingstd/pir_code_coda.t should not check builtins.pir.
Here's a patch with 2 parts:
1. Make the test script ignore autogenerated files. (Based on the
common idiom that autogenerated files start with a "# THIS IS A
GENERATED FILE! DO NOT EDIT!" comment.) Also, ignore files which don't
actually exist.[1] (Assuming they will be autogenerated, but we haven't
done a "make languages" yet or whatever... haven't gotten to that stage
of the build process yet.)
2. Remove the autogenerated file from source control; it looked like
it had been added and given some editor tagging to satisfy the test in
the meantime. This means the file shows up in "svn st" or "svk st" as
modified, after a "make languages", which annoyed me enough to make
this patch.
[1]: I had to add the file existence check mentioned in part 1, because
the test seemed to interpret a nonexistent file as if it were an empty
file (it didn't die() like I thought it would after reading the
test source). I don't know what that's about.
[EMAIL PROTECTED] ~/parrot $ ls -l languages/dotnet/src/builtins.pir
ls: cannot access languages/dotnet/src/builtins.pir: No such file or directory
[EMAIL PROTECTED] ~/parrot $ prove t/codingstd/pir_code_coda.t
t/codingstd/pir_code_coda
# Failed test (t/codingstd/pir_code_coda.t at line 81)
# PIR code coda missing in 1 files:
# /home/paranoid/parrot/languages/dotnet/src/builtins.pir
# Looks like you failed 1 test of 2.
t/codingstd/pir_code_codadubious
Test returned status 1 (wstat 256, 0x100)
Mark
=== t/codingstd/pir_code_coda.t
==
--- t/codingstd/pir_code_coda.t (revision 20197)
+++ t/codingstd/pir_code_coda.t (local)
@@ -54,6 +54,7 @@
# otherwise, use the relevant Parrot:: path method
my $path = @ARGV ? $file : $file->path;
+next unless -f $path;
# slurp in the file
open( my $fh, '<', $path )
or die "Cannot open '$path' for reading: $!\n";
@@ -62,6 +63,9 @@
$buf = <$fh>;
}
+# skip autogenerated files (based on the first line of the file)
+next if(index($buf, "# THIS IS A GENERATED FILE! DO NOT EDIT!") == 0);
+
# append to the no_coda array if the code doesn't match
push @no_coda => "$path\n"
unless $buf =~ m{\Q$coda\E\n*\z};
=== languages/dotnet/src/builtins.pir
==
--- languages/dotnet/src/builtins.pir (revision 20197)
+++ languages/dotnet/src/builtins.pir (local)
@@ -1,69 +0,0 @@
-# THIS IS A GENERATED FILE! DO NOT EDIT!
-
-.HLL '_dotnet', ''
-
-.sub internal_method_body
-.param pmc class
-.param pmc meth
-.local string class_name, method_name, body
-
-# Get class and method names.
-class_name = class.get_fullname()
-method_name = meth
-if class_name == "System.Object" goto CLASS_System_Object
-goto FAIL
-CLASS_System_Object:
-if method_name == "GetType" goto UNIMPLEMENTED
-if method_name == "InternalGetHashCode" goto BODY_System_Object___InternalGetHashCode
-if method_name == "MemberwiseClone" goto BODY_System_Object___MemberwiseClone
-if method_name == "obj_address" goto BODY_System_Object___obj_address
-goto FAIL
-FAIL:
-$P0 = new .Exception
-$P0["_message"] = "No body supplied for built-in method"
-throw $P0
-BODY_System_Object___InternalGetHashCode:
-body = <<"___BUILTIN_CODE___"
-.param pmc obj
-$I0 = obj.__hash(42)
-.return($I0)
-
-
-___BUILTIN_CODE___
-goto END
-BODY_System_Object___MemberwiseClone:
-body = <<"___BUILTIN_CODE___"
-.local pmc cpy
-cpy = clone self
-.return(cpy)
-
-
-___BUILTIN_CODE___
-goto END
-BODY_System_Object___obj_address:
-body = <<"___BUILTIN_CODE___"
-$I0 = net_pmc_addr self
-.return($I0)
-___BUILTIN_CODE___
-goto END
-# Generic unimplemented internal method body (throws exception).
-UNIMPLEMENTED:
-body = <<"PIR"
-$P0 = new .Exception
-$P0["_message"] = "System.NotImplementedException"
-$P1 = new "System.NotImplementedException"
-$P0["obj"] = $P1
-throw $P0
-PIR
-
-# Return.
-END:
-.return(body)
-.end
-
-
-# Local Variables:
-# mode: pir
-# fill-column: 100
-# End:
-# vim: expandtab shiftwidth=4:
Property changes on: languages/dotnet/src/builtins.pir
___
Name: svn:eol-style
-native
Name: svn:keywords
-Author Date Id Revision
Re: [perl #42774] [PATCH] Configure.pl --gc=libc doesn't compile
On Fri, 27 Apr 2007 11:19:59 -0700 Andy Dougherty (via RT) <[EMAIL PROTECTED]> wrote: > "src/gc/dod.c", line 462: undefined symbol: > PObj_bufstart_external_FLAG I hunted for this a bit lastnight, so I'm posting my progress. The source lines in question are: 461 /* the real external flag */ 462>> if (PObj_bufstart_external_TEST(b))<< 463 PObj_external_SET(b); After some preprocessor nonsense, line 462 becomes: if b)->obj.flags) & PObj_bufstart_external_FLAG)) PObj_bufstart_external_FLAG used to be defined in include/parrot/pobj.h, but it was removed in svn r10582: r10582 | leo | 2005-12-19 08:19:22 -0800 (Mon, 19 Dec 2005) | 9 lines Buffer allocation - Buffer flags * removed unused Buffer flags (bufstart_external, immobile) * create new PObj_is_COWable_FLAG for future generalization of COWed buffers * use managed memory in PIO_reads Please 'make clean' due to changed Buffer flags Strange that r10582 removed the flag itself, but not the accessors (PObj_bufstart_external_TEST and PObj_bufstart_external_SET).
Re: [perl #42883] [PATCH] Fix up headerfile guards
On Sat, 05 May 2007 07:58:45 -0700
"Bernhard Schmalhofer via RT" <[EMAIL PROTECTED]> wrote:
> > * Fix up the indentation problems caused by the above bullet point.
> > (TODO: why does t/codingstd/c_indent.t require indentation for #if
> > and #ifdef, but not for #ifndef?)
> As far as I understand c_indent.t, #ifndef is also covered
Except that it isn't. If you apply the attached patch, you will see
that t/codingstd/c_indent.t starts failing. C_indent.t will not be
happy until you reindent everything else, inside of it. (This patch
should not be checked in, it only exhibits the problem, it does not
solve anything.)
> > I'd like to write some tests for this stuff, and then fix up the
> > rest of the cases (I know I've missed a bunch). How would the list
> > feel about a patch to PDD07 specifying the above for header files,
> > and a codingstd test to enforce it?
> My feeling is that we need to differentiate two cases:
> i. header files that define an interfaces for e.g. a subsystem
> ii. Convenience headers, that contain declaration of internal
> functions
>
> Case i. might need stricter checks than ii.
Thanks for your input. I have written a test case for this,
t/codingstd/c_header_guards.t (attached), which checks the following:
* The existence of an #ifndef PARROT_*_GUARD
* That each header file only contains one #ifndef PARROT_*_GUARD
* The existence of a matching #define (this caught a few misspells)
* The existence of an #endif /* PARROT_*_GUARD */
* That the PARROT_*_GUARD macro is unique (doesn't stomp on any other
files)
I patched up another large set of headers, to pass this test. But
before I send in another big patch with some changes to type ii
("convenience") headers, can you please tell me if there's a clean,
programmatic way to determine which headers it should perform strict
checks on? That way I can fix the test to only run on the
non-"convenience" subset of headers.
Also, should any of the above tests be applied to type ii headers, or
should they only apply to type i headers? (Should type ii headers be
ignored completely, or only subjected to a subset of the tests?)
Mark
Index: src/stm/stm_internal.h
===
--- src/stm/stm_internal.h (revision 18445)
+++ src/stm/stm_internal.h (working copy)
@@ -1,4 +1,4 @@
-#ifndef PARROT_STM_INTERNAL_H_GUARD
+#if !defined(PARROT_STM_INTERNAL_H_GUARD)
#define PARROT_STM_INTERNAL_H_GUARD
#include
#! perl
# Copyright (C) 2006-2007, The Perl Foundation.
# $Id$
use strict;
use warnings;
use lib qw( . lib ../lib ../../lib );
use Test::More tests => 5;
use Parrot::Distribution;
=head1 NAME
t/codingstd/c_header_guards.t - checks for rules related to guards in C header files
=head1 SYNOPSIS
# test all files
% prove t/codingstd/c_header_guards.t
# test specific files
% perl t/codingstd/c_header_guards.t include/parrot/bar.h
=head1 DESCRIPTION
Checks that all C language header files have an #ifndef PARROT_WHATEVER_H_GUARD definition,
and an #endif /* PARROT_WHATEVER_H_GUARD */ at the end, as specified in PDD07.
=head1 SEE ALSO
L
=cut
my $DIST = Parrot::Distribution->new();
my @files = @ARGV ? @ARGV : map { $_->path() } $DIST->c_header_files();
#foreach my $file ( @files ) {
#print $file, "\n";
#}
#exit;
check_header_guards(@files);
exit;
sub check_header_guards {
my (%guardnames, %redundants, %collisions,
%missing_guard, %missing_define, %missing_comment);
F: foreach my $file (@_) {
open my $fh, '<', $file
or die "Can not open '$file' for reading!\n";
my @source = <$fh>;
close $fh;
chomp @source;
my ($ifndef, $define, $endif);
L: foreach my $line (@source) {
$line =~ s/\s+/ /;
$line =~ s/^ //;
# skip Bison parser files
next F if $line =~ /A Bison parser/;
# skip the non-preprocessor lines
next L unless substr($line,0,1) eq '#';
# skip the "#", and any leading whitespace
$line = substr($line, 1);
$line =~ s/^ //;
if($line =~ m[ifndef (PARROT_.+_GUARD)$]) {
# check for multiple guards in the same file
$redundants{$file} = $1 if defined $ifndef;
# check for the same guard-name in multiple files
$collisions{$file} = $guardnames{$1}
if exists $guardnames{1};
$ifndef = $1;
$guardnames{$1} = $file;
}
if($line =~ m[define (PARROT_.+_GUARD)$]) {
$define = $1
if(defined($ifndef) && $ifndef eq $1);
}
if($line =~ m[endif /\* (PARROT_.+_GUARD) \*/$]) {
$endif = $1
if(defined($ifndef) && $ifndef eq $1);
}
}
$missing_guard{$file} = 1 unless defined $ifndef;
$missing_define{$file} =
svn r18461 indentation problem?
Hi Paul! I noticed you reindented the example when checking in the PDD07 change. Sorry to disagree with you, but this seems wrong to me. Elsewhere in PDD07, it says: "neither PARROT_IN_CORE nor the outermost _GUARD #ifdefs cause the level of indenting to increase." So I think the indentation was right. I'm in #parrot, if you'd like to discuss this. And thanks for looking at my patch! Mark
Re: [perl #42908] AutoReply: [PATCH] add guard macro to autogenerated file include/parrot/has_header.h
Hmm. It seems there's more than one header being missed by t/codingstd/c_header_guards.t. I'm going to try to supplement the $DIST->c_header_files() list with items culled from $DIST->generated_files(), or something, if noone can come up with a better idea. In the meantime, here's an additional patch to bring the generated include/parrot/feature.h into conformance. Mark === config/gen/config_h/feature_h.in == --- config/gen/config_h/feature_h.in (revision 20298) +++ config/gen/config_h/feature_h.in (local) @@ -3,7 +3,7 @@ */ -#if !defined(PARROT_FEATURE_H_GUARD) +#ifndef PARROT_FEATURE_H_GUARD #define PARROT_FEATURE_H_GUARD #perl - all below here gets evaled by perl, OUT is the filehandle
Re: [perl #42903] [PATCH] Add guards to the rest of the headerfiles
On Tue, 08 May 2007 10:10:06 -0700 "Paul Cochrane via RT" <[EMAIL PROTECTED]> wrote: > A comment: this patch was in essence three patches (the pod, a test > and a patch of the headers), next time could you separate them into > three patches? The test was itself actually a new file, so it could > have just been attached rather than a patch made of it. Also, when > you add a new file, could you also update MANIFEST as well? These > are meant as positive critisms; you've done great work and your help > is greatly appreciated. Sure, those are all good ideas. Thanks for the tips, and thanks for the checkin! Mark
Re: r18572 - trunk/compilers/imcc
On Thu, 17 May 2007 11:13:45 -0700 "jerry gay" <[EMAIL PROTECTED]> wrote: > char *s = s_key; > *s = 0; > however... why is 's' nulled out, directly after it's initialized to > 's_key'? that looks funny. The first line declares a pointer, pointing to s_key. The second line sets the first byte of s_key's buffer to 0 (the pointer value itself doesn't change). Mark
Re: Parrot Project Management...
On Mon, 21 May 2007 18:51:48 -0400 Will Coleda <[EMAIL PROTECTED]> wrote: > If you notice any missing documentation, please open an RT ticket > with [DOCS] in the subject. ((It won't be processed specially by RT, > but will help me search.)) Ask on the list. Send patches, either to > the parrot repo or the website. How much of the parrot sources are PODable? Think its worth adding a codingstd test for POD coverage? Mark
Re: POD Coverage (was: Parrot Project Management...)
On Mon, 21 May 2007 19:27:26 -0400 James E Keenan <[EMAIL PROTECTED]> wrote: > Mark Glines wrote: > > > > Think its worth adding a > > codingstd test for POD coverage? > > > > > > No. > > Or perhaps: No, not unless you want to start a big "philosophical" > argument about POD coverage. > > I say this as someone who dissents from the prevailing wisdom about > POD coverage as it relates to CPAN modules. That's because the tests > on CPAN that purport to rate the "kwalitee" of the POD coverage of > CPAN distributions will only credit you if you write your POD in one > particular style. If you happen to have written POD for one of your > distros before that standard was formulated, or if you happen to > think that style doesn't suit your distro well, then you don't get > credit and your "kwalitee" sinks. > > There are distros for which I've written 40+ pages of documentation > but which fail these "kwalitee" tests because of the way I structured > the =head tags. > > I happen to think that some of our coding standards amount to > excessive nitpicking ... and when Perl::Critic is applied to some of > the code I maintain, the results, IMHO, are demonstrably less > readable code. And that's for stuff we write in relatively well > structured languages like Perl 5 and PIR. We write POD in English; > need I say more? > > Finally, to add a test for POD coverage is just one more test which > will fail often in 'make test' or 'make smoke' and yet say nothing > about the quality of Parrot. > > In, short: No. Ok. Thanks for the feedback. Lets see what I can do with it... First. Frankly, I don't care about the *style* of POD in use, just that there *is* some. "Well-formedness" for me comes down to parsability, not style. So Perl::Critic can GTFOMI. :) And there already is a POD well-formedness test (t/doc/pod.t), so all the codingstd test I'm proposing would do is make sure some pod exists, at least for non-generated sources in POD-capable file formats. I feel the same way you do about Test::Pod::Coverage; its the reason I haven't added POD coverage tests to my own distributions. It's quite possible to document a module properly without having a separate =head tag for each subroutine in it. Second. How do you feel about a codingstd test for this that is not run during "make test" or "make smoke"? The @coding_std_tests variable in t/harness looks to me like a whitelist for which tests to run on non-release builds... so if this test isn't part of the list, then everyone is happy? (Or have I misunderstood that code?) If you still don't like it, I'll drop the subject :) Mark
Re: [perl #42355] [PATCH] [TODO] use ARG_MAX in pic_callr__() op
On Sun, 08 Apr 2007 12:04:37 -0700
[EMAIL PROTECTED] (Paul Cochrane) wrote:
> # New Ticket Created by Paul Cochrane
> # Please include the string: [perl #42355]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=42355 >
>
>
> In the file src/ops/pic.ops in the pic_callr__() op there is a todo
> item which merely states:
>
> "ARG_MAX"
>
> I believe this means use the ARG_MAX macro instead of a hard-coded
> number in the args[] array mentioned on this line. In short: fix.
There is no ARG_MAX macro. There's a PCC_ARG_MAX macro, defined to
1024, which is probably not quite what we were looking for (the magic
number in question is 6).
There is already a PARROT_MAX_ARGS define in ops.h, set to 8. This
function (pic_callr__) declares an array of 6 args, and does some work
to copy arguments 2+ from the current opcode into this array. I don't
know what the first 2 arguments do or why they were skipped, but here's
a patch to clean up the magic number 6 (the cause of this ticket) as
well as the magic offset number 2, which occurs in several places
farther down in the function.
I was warnocked on the IRC channel asking what all of this stuff was
about, so it's quite probable that the macros this patch adds could
have better names. (Or that I'm calculating 6 from the wrong source.)
Please feel free to correct me. Anyway, here's a patch.
Mark
=== include/parrot/op.h
==
--- include/parrot/op.h (revision 20478)
+++ include/parrot/op.h (local)
@@ -15,7 +15,9 @@
#include "parrot/config.h"
-#define PARROT_MAX_ARGS 8
+#define PARROT_MAX_ARGS 8
+#define PARROT_OP_ARGS_OFFSET 2
+#define PARROT_OP_ARGS(PARROT_MAX_ARGS-PARROT_OP_ARGS_OFFSET)
typedef enum {
PARROT_INLINE_OP,
=== src/ops/pic.ops
==
--- src/ops/pic.ops (revision 20478)
+++ src/ops/pic.ops (local)
@@ -246,7 +246,7 @@
inline op pic_callr__(inconst PMC) :pic {
Parrot_MIC *mic;
Parrot_PIC_lru *lru;
-void *args[6]; /* RT#42355 ARG_MAX */
+void *args[PARROT_OP_ARGS];
parrot_context_t *ctx;
opcode_t *pc;
void **pred_pc;
@@ -277,15 +277,15 @@
switch (sig_bits[i]) {
case PARROT_ARG_INTVAL:
args[1 + i] = (void*)*(INTVAL*)(_reg_base +
-((opcode_t*)cur_opcode)[2 + i]);
+((opcode_t*)cur_opcode)[PARROT_OP_ARGS_OFFSET + i]);
break;
case PARROT_ARG_INTVAL|PARROT_ARG_CONSTANT:
case PARROT_ARG_FLOATVAL|PARROT_ARG_CONSTANT:
-args[1 + i] = (void**)cur_opcode[2 + i];
+args[1 + i] = (void**)cur_opcode[PARROT_OP_ARGS_OFFSET + i];
break;
case PARROT_ARG_FLOATVAL:
args[1 + i] = (_reg_base +
-((opcode_t*)cur_opcode)[2 + i]);
+((opcode_t*)cur_opcode)[PARROT_OP_ARGS_OFFSET + i]);
break;
default:
internal_exception(1, "unhandled sig_bits");
Re: [perl #42938] [BUG] allocation failures in res_lea.c
On Sat, 12 May 2007 12:05:26 -0700
Allison Randal (via RT) <[EMAIL PROTECTED]> wrote:
> On x86 Linux (Ubuntu), this configuration fails 2 tests:
>
> t/library/string_utils.t0 134294 13.79% 28-29
> t/op/stringu.t 2 512252 8.00% 1 19
>
> Both tests are failing with the error:
>
> parrot: src/encodings/utf8.c:271: utf8_encode_and_advance: Assertion
> `i->bytepos <= (s)->obj.u._b._buflen' failed.
Reproduced on Gentoo. Before patch, results are as above.
After patch:
t/library/string_utilsok
t/op/stringu..ok
The code in utf8_encode_and_advance is beautiful. It basically says,
add a utf8 character to the buffer. Ok, now did we overrun the buffer?
CRASH!
It seems safer to check the buffer size *before* writing to it, so
here's a patch to do so. Is it the right fix? I thought so when I
was doing it, but now I'm not so sure; it does introduce a const
warning. Maybe we can resolve that with a cast; maybe its the wrong
solution to the problem. Please provide guidance.
Might be worth it to prereserve 8 bytes or so, to avoid having to
realloc as often, if this will be called a lot. Currently it just
reallocs the minimum necessary to fit the existing string, the new
character and a null terminator.
Mark
=== src/encodings/utf8.c
==
--- src/encodings/utf8.c (revision 20520)
+++ src/encodings/utf8.c (local)
@@ -264,6 +264,9 @@
const STRING *s = i->str;
unsigned char *new_pos, *pos;
+if(i->bytepos + UNISKIP(c) >= PObj_buflen(s)) {
+Parrot_reallocate_string(interp, i->str, i->bytepos + UNISKIP(c) + 1);
+}
pos = (unsigned char *)s->strstart + i->bytepos;
new_pos = utf8_encode(pos, c);
i->bytepos += (new_pos - pos);
Re: [perl #42938] [BUG] allocation failures in res_lea.c
On Thu, 31 May 2007 23:09:54 -0700 Mark Glines <[EMAIL PROTECTED]> wrote: > Might be worth it to prereserve 8 bytes or so, to avoid having to > realloc as often, if this will be called a lot. Currently it just > reallocs the minimum necessary to fit the existing string, the new > character and a null terminator. There is a performance impact from the additional check, but I don't think the above optimization is necessary... or its possible Parrot_reallocate_string() already reserves extra room internally. Either way, I don't see enough of a performance hit from the patch to be too worried about this. I tried "prove t/op t/library" with different scenarios, to try to measure the performance impact. Here are the setups and the results: Configure.pl with no args, and no patches applied All tests successful, 2 tests and 172 subtests skipped. Files=56, Tests=2488, 73 wallclock secs (51.64 cusr + 11.49 csys = 63.13 CPU) Configure.pl with no args, #42938 patch applied All tests successful, 2 tests and 172 subtests skipped. Files=56, Tests=2488, 72 wallclock secs (51.73 cusr + 11.59 csys = 63.32 CPU) Configure.pl --gc=libc, no patches applied Failed Test Stat Wstat Total Fail List of Failed --- t/library/string_utils.t0 6294 28-29 t/op/stringu.t 2 512252 1 19 2 tests and 176 subtests skipped. Failed 2/56 test scripts. 4/2488 subtests failed. Files=56, Tests=2488, 69 wallclock secs (50.57 cusr + 11.19 csys = 61.76 CPU) Failed 2/56 test programs. 4/2488 subtests failed. Configure.pl --gc=libc, #42938 patch applied All tests successful, 2 tests and 176 subtests skipped. Files=56, Tests=2488, 70 wallclock secs (50.67 cusr + 11.24 csys = 61.91 CPU) Mark
GC bug on freebsd/x86, triggered by a perl6 test
I tried the perl6 testsuite on freebsd at Coke's request, and discovered a test that fails on freebsd but succeeds on linux. The test seems to be a GC-related assertion failure; parrot -G does not crash, parrot without -G does crash. I am running on freebsd 6.2, in a checkout of svn r18803. I did a realclean beforehand, and configured with just "perl Configure.pl", no arguments. To reproduce: make realclean perl Configure.pl make cd languages/perl6 LD_LIBRARY_PATH=../../blib/lib make $ LD_LIBRARY_PATH=../../blib/lib ../../parrot perl6.pbc t/00-parrot/05-var-array.t Assertion failed: (s->encoding && s->charset && !PObj_on_free_list_TEST(s)), function string_hash, file src/string.c, line 2024. Abort trap (core dumped) $ LD_LIBRARY_PATH=../../blib/lib ../../parrot -G perl6.pbc t/00-parrot/05-var-array.t 1..11 ok 1 ok 2 ok 3 ok 4 ok 5 ok 6 ok 7 ok 8 ok 9 ok 10 ok 11 (the LD_LIBRARY_PATH bit is required on freebsd so parrot can find libparrot.so.) Mark
Re: GC bug on freebsd/x86, triggered by a perl6 test
On Mon, 4 Jun 2007 13:07:18 -0700 chromatic <[EMAIL PROTECTED]> wrote: > On Monday 04 June 2007 12:49:45 Mark Glines wrote: > > > (the LD_LIBRARY_PATH bit is required on freebsd so parrot can find > > libparrot.so.) > > The GNU linker supports a flag to mark a relocatable shared library. > From my Makefile: > >-Wl,-rpath=/home/chromatic/dev/parrot/blib/lib > > I don't know which linker you use on FreeBSD, but is there a similar > flag? If so, using it could clear up some of the dynamic loading > problems (especially for dynops and dynpmcs). $ ld --version GNU ld version 2.15 [FreeBSD] 2004-05-23 So it probably supports that flag. I know next to nothing about FreeBSD, but here's how libparrot.so.* is currently linked: cc -shared -L/usr/local/lib -Wl,-E -L/usr/local/lib -o blib/lib/libparrot.so.0.4.12 -Wl,-soname=libparrot.so.0.4.12 [list of objects] -lm -lcrypt -lutil -pthread -lreadline Soo... is that just something missing from the freebsd hints file, then? Mark
Re: [perl #43130] AutoReply: Re: GC bug on freebsd/x86, triggered by a perl6 test
On Mon, 04 Jun 2007 13:39:44 -0700 "Parrot via RT" <[EMAIL PROTECTED]> wrote: > Greetings, > > This message has been automatically generated in response to the > creation of a parrotbug regarding: > "Re: GC bug on freebsd/x86, triggered by a perl6 test" This ticket is a duplicate of RT #43128, caused because I sent the original one to both perl6-internals and parrotbug, and then hit "Reply All". So, tickets 43129, 43130, 43131, and 43132 are all duplicates of 43128. Sorry about that; please close. Mark
Re: GC bug on freebsd/x86, triggered by a perl6 test
On Mon, 04 Jun 2007 21:39:08 +0100 Jonathan Worthington <[EMAIL PROTECTED]> wrote: > > Assertion failed: (s->encoding && s->charset > > && !PObj_on_free_list_TEST(s)), function string_hash, file > > src/string.c, line 2024. Abort trap (core dumped) > > > I'm betting that it's the !PObj_on_free_list_TEST(s) bit of the > assertion that failed, and my guess is also that it's related to the > Perl 6 GC failures I posted about yesterday, which cause most of the > Perl 6 test suite to fail on Win32. Is it just the one that fails on > FreeBSD like this? The rest of the failures are also failures I see on Linux, and according to pmichaud, are expected. [08:55] <@pmichaud> we don't have implementations of end blocks, for, ref, or test yet The only unexpected failure is t/00-parrot/05-var-array.t, and I see it on FreeBSD but it passes on Linux. Mark
LD_LIBRARY_PATH required on FreeBSD (was: Re: GC bug on freebsd/x86, triggered by a perl6 test)
On Tue, 5 Jun 2007 01:13:36 -0500 Joshua Isom <[EMAIL PROTECTED]> wrote: > After a little prodding around, I think the problem is that the > dynops aren't build with the rpath. I don't know how "proper" the > following patch is(i.e. linux doesn't seem to have a problem so > either this is right or the other way is right), but it does the > trick. > -our $LDFLAGS = [EMAIL PROTECTED]@ @[EMAIL PROTECTED]; > +our $LDFLAGS = [EMAIL PROTECTED]@ @ld_debug@ @[EMAIL PROTECTED]; Sorry, but this patch didn't change anything for me. The libparrot.so link line looks the same (maybe because its linking with cc, not ld), and I still need to specify an LD_LIBRARY_PATH when invoking parrot from a subdir, later on. Since it works on linux but not freebsd, and since freebsd seems to have the same tools available as linux, could it just be a difference in the hints files? [EMAIL PROTECTED] ~/parrot $ grep rpath config/init/hints/freebsd.pm config/init/hints/linux.pm config/init/hints/freebsd.pm:rpath => '-Wl,-R', config/init/hints/linux.pm:rpath => '-Wl,-rpath=', On the other hand, I don't see an actual "-Wl,-rpath=" clause on the linker line for a linux build, either. And the result works on linux without any LD_LIBRARY_PATH hints, but not on freebsd. Linker line under linux: i686-pc-linux-gnu-gcc -shared -L/usr/local/lib -fPIC -L/usr/local/lib -o blib/lib/libparrot.so.0.4.12 -Wl,-soname=libparrot.so.0.4.12 [long list of objects] -lpthread -lnsl -ldl -lm -lcrypt -lutil -lrt -lgmp -lreadline -lncurses -lpthread -lm -L/usr/lib -licuuc -licudata -lpthread -lm Linker line under freebsd: cc -shared -L/usr/local/lib -Wl,-E -L/usr/local/lib -o blib/lib/libparrot.so.0.4.12 -Wl,-soname=libparrot.so.0.4.12 [long list of objects] -lm -lcrypt -lutil -pthread -lreadline Mark
Re: Removing #pragma
On Tue, 12 Jun 2007 11:39:35 -0700 Allison Randal <[EMAIL PROTECTED]> wrote: > jerry gay wrote: > > On 6/12/07, Andy Lester <[EMAIL PROTECTED]> wrote: > >> > >> I'm very uncomfortable with removing #pragma once from our header > >> files. It is perfectly valid C89 code, and I think bowing to a > >> broken compiler is unhealthy precedent. > >> > > to add some context, in r18884 andy committed a patch (after my > > suggestion) to put C<#pragma once> in every c header file, after > > reading that it should speed up compilation with msvc. i consulted > > my copy of k&r, which states that unrecognized pragmas should be > > ignored, so it should have no ill effects on other platforms. > > Do we have any proof that it does speed up compilation with msvc? > Littering our code with "optimizations" for odd compilers is also an > unhealthy precedent. Note that some versions of gcc also support it, for instance, later compilers in the 3.4.x series support it. (At least, I see it in their changelog, not sure exactly which release they added it in.) I just came up with an artificial benchmark and found that gcc-3.4.6 runs slightly faster with #pragma once protecting a header that includes lots of other headers. (a chain of 200 other headers, in my test.) By "slightly", I mean "compare a 0.86 second average to a 0.92 second average, for 10 runs each". For a more realistic benchmark, parrot r18883 compiles in 3m29.363s, parrot r18884 compiles in 3m29.190s. So, for gcc-3.4.6 at least, I think the difference might be lost in the noise. On the other hand, will #pragma once allow us to get rid of all of those ugly header guard macros? If so, I would argue to keep it for maintenance reasons, regardless of any performance benefits. Mark
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. > # 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 (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 #43241] [PATCH] [CAGE] include/parrot/string.h typedefs STRING and String are redundant
On Tue, 19 Jun 2007 00:33:23 -0700 "Paul Cochrane via RT" <[EMAIL PROTECTED]> wrote: > On Mon Jun 18 15:03:31 2007, petdance wrote: > > > > On Jun 18, 2007, at 11:28 AM, Mark Glines (via RT) wrote: > > > > > Here's a patch to consolidate that, and standardize on STRING > > > (based on the fact that it's used *much* more often than String > > > is). > > > > And also isn't String a standard C++ class? > > > > I've applied your patch. Thanks. > > Does this close this ticket, or are there still outstanding instances? Since the patch also removes the String prototype from the header file, outstanding instances seem unlikely. That said, chromatic did find and fix a failing test caused by this in r19101, which I had missed. Sorry about that. Mark
Re: [svn:parrot] r19231 - trunk/languages/perl6/src/pmc
On Thu, 21 Jun 2007 17:38:15 -0700 chromatic <[EMAIL PROTECTED]> wrote: > > -return string_from_cstring(INTERP, "Str", 3); > > +return string_from_cstring(INTERP, "Bool", 3); > > return SUPER(); > > } > > That 3 looks like it should be 4. Yep, fixed in r19238. Mark
Re: [svn:parrot] r19231 - trunk/languages/perl6/src/pmc
On Fri, 22 Jun 2007 10:07:32 +0100
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > We have a lot of string_from_cstring() calls with constant second
> > parameters and third parameters of 0 that could use updating.
> > There's no sense in calling strlen() all the time.
>
> I think that you need something like this
>
> /* concatenating with "" ensures that only literal strings are
> accepted as argument */ #define STR_WITH_LEN(s) (s ""), (sizeof(s)-1)
>
> /* STR_WITH_LEN() shortcuts */
> #define newSVpvs(str) Perl_newSVpvn(aTHX_ STR_WITH_LEN(str))
>
> ...
>
> (Credit to chip for the concatenating with "" trick)
Nice! I'm always a big fan of letting gcc do the heavy lifting.
So, here's a patch that implements a string_from_cstring_literal()
wrapper around string_from_cstring(), and another patch to fix up most
of the string_from_cstring(interp, "literal", 0) cases to use it. That
was just a regex search & replace, so it will have missed the callers
that span multiple source lines. But it builds and tests fine, so I
think its a good start.
Is string_from_cstring() documented somewhere? I'd like to add a blurb
about string_from_cstring_literal(). Also, should I submit this as a
[PATCH] [CAGE] ticket, or do you want to just apply it?
Mark
=== include/parrot/string_funcs.h
==
--- include/parrot/string_funcs.h (revision 20999)
+++ include/parrot/string_funcs.h (local)
@@ -175,6 +175,9 @@
__attribute__nonnull__(1)
__attribute__warn_unused_result__;
+#define CSTRING_WITH_LEN(s) (s ""), (sizeof(s)-1)
+#define string_from_cstring_literal(i,s) string_from_cstring((i),CSTRING_WITH_LEN(s))
+
PARROT_API STRING * string_from_int( Interp *interp /*NN*/, INTVAL i )
__attribute__nonnull__(1);
=== compilers/imcc/pbc.c
==
--- compilers/imcc/pbc.c (revision 20999)
+++ compilers/imcc/pbc.c (local)
@@ -534,7 +534,7 @@
/* :multi() n = 1, reg = NULL */
if (!pcc_sub->multi[0]) {
STRING *sig;
-sig = string_from_cstring(interp, "__VOID", 0);
+sig = string_from_cstring_literal(interp, "__VOID");
sig_pmc = pmc_new(interp, enum_class_String);
VTABLE_set_string_native(interp, sig_pmc, sig);
=== compilers/pge/PGE/pmc/codestring.pmc
==
--- compilers/pge/PGE/pmc/codestring.pmc (revision 20999)
+++ compilers/pge/PGE/pmc/codestring.pmc (local)
@@ -73,7 +73,7 @@
PIO_printf(interp, "%d %Ss, %d\n", cur_ns, (STRING*)PMC_data(cur_ns), global_serno);
VTABLE_set_integer_native(INTERP, global_serno, 10);
-Parrot_set_global(INTERP, cur_ns, string_from_cstring(INTERP, "$!serno", 0), global_serno);
+Parrot_set_global(INTERP, cur_ns, string_from_cstring_literal(INTERP, "$!serno"), global_serno);
}
}
*/
@@ -108,9 +108,9 @@
STRING *format;
STRING *key;
STRING *repl;
-STRING *PERCENT = string_from_cstring(INTERP, "%", 0);
+STRING *PERCENT = string_from_cstring_literal(INTERP, "%");
STRING *COMMA = string_from_cstring(INTERP, ",", 0);
-STRING *NEWLINE = string_from_cstring(INTERP, "\n", 0);
+STRING *NEWLINE = string_from_cstring_literal(INTERP, "\n");
format = string_copy(interp, orig_format);
@@ -197,14 +197,14 @@
*/
METHOD STRING* escape(STRING *str) {
-STRING *SLASH_U = string_from_cstring(INTERP, "\\u", 0);
-STRING *SLASH_X = string_from_cstring(INTERP, "\\x", 0);
+STRING *SLASH_U = string_from_cstring_literal(INTERP, "\\u");
+STRING *SLASH_X = string_from_cstring_literal(INTERP, "\\x");
str = string_escape_string(interp, str);
str = Parrot_sprintf_c(interp, "\"%Ss\"", str);
if (string_str_index(interp, str, SLASH_U, 0) >= 0
|| string_str_index(interp, str, SLASH_X, 0) >= 0) {
-str = string_concat(interp, string_from_cstring(interp, "unicode:", 0), str, 0);
+str = string_concat(interp, string_from_cstring_literal(interp, "unicode:"), str, 0);
}
return str;
}
=== examples/compilers/japhc.c
==
--- examples/compilers/japhc.c (revision 20999)
+++ examples/compilers/japhc.c (local)
@@ -179,7 +179,7 @@
sub_data->seg = cur_cs;
sub_data->address = cur_cs->base.data;
sub_data->end = cur_cs->base.data + cur_cs->base.size;
-sub_data->name = string_from_cstring(interpreter, "JaPHC", 0);
+sub_data->name = string_from_cstring_literal(interpreter, "JaPHC");
return sub;
}
=== languages/APL/src/pmc/aplvector.pmc
==
--- languages/APL/src/pmc/aplvector.pmc (revision 20999)
+++ languages/APL/src/pmc/aplvector.pmc (local)
@@ -114,7 +114,
Re: [svn:parrot] r19231 - trunk/languages/perl6/src/pmc
On Fri, 22 Jun 2007 11:36:28 -0500 "Patrick R. Michaud" <[EMAIL PROTECTED]> wrote: > > Also, using sizeof() will fix some cases that strlen() doesn't > > handle correctly, specifically, strings containing explicit null > > characters. src/objects.c has a few examples of that. > > string_to_cstring(interp, "\0", 0) will get the size wrong, but > > string_to_cstring_literal(interp, "\0") will get it right. So I > > don't really see a good excuse for not using it everywhere. > > I think you mean "string_from_cstring_literal", not > "string_to_cstring_literal". At least I _hope_ that's > what you mean. :-) Oops, you're absolutely right. > Also, out of curiosity, do we really need "cstring" in the name? > How about simply...? > > string_from_literal(interp, "Foo") > > (I'm not opposed to leaving 'cstring' in the name if it's important > to somehow make it clear that the literal is a cstring literal, I'm > just asking the question.) I just did it to make it look visually similar to string_from_cstring(). I am open to suggestions and happy to make changes. Mark
Re: [svn:parrot] r19231 - trunk/languages/perl6/src/pmc
On Fri, 7 Nov 2008 15:28:40 -0700 chromatic <[EMAIL PROTECTED]> wrote: > On Friday 22 June 2007 02:07:32 Nicholas Clark wrote: > > I think that you need something like this > > > > /* concatenating with "" ensures that only literal strings are > > accepted as argument */ #define STR_WITH_LEN(s) (s ""), > > (sizeof(s)-1) > > > > /* STR_WITH_LEN() shortcuts */ > > #define newSVpvs(str) Perl_newSVpvn(aTHX_ STR_WITH_LEN(str)) > > I'm not sure that's what I was asking. > > string_from_cstring()'s third parameter can be either the length of > the string or zero. If it's zero, the function will call strlen() to > get the string's length. > > If we're passing in a string literal, it seems silly to pass in a > length of 0, as we're recalculating a constant on every call. I > don't see that this macro fixes that. It uses sizeof, not strlen. So, it pushes the calculation to compile-time, so you only have to do it once, and never at runtime. Also, using sizeof() will fix some cases that strlen() doesn't handle correctly, specifically, strings containing explicit null characters. src/objects.c has a few examples of that. string_to_cstring(interp, "\0", 0) will get the size wrong, but string_to_cstring_literal(interp, "\0") will get it right. So I don't really see a good excuse for not using it everywhere. > I do agree that updating strings and string lengths can be tedious, > but I'm not aware of any C89-compliant solution to keep the two > synchronized. sizeof() isn't C89? Mark
Re: [svn:parrot] r19231 - trunk/languages/perl6/src/pmc
On Fri, 22 Jun 2007 10:35:00 -0700
chromatic <[EMAIL PROTECTED]> wrote:
> > > If we're passing in a string literal, it seems silly to pass in a
> > > length of 0, as we're recalculating a constant on every call. I
> > > don't see that this macro fixes that.
>
> > It uses sizeof, not strlen. So, it pushes the calculation to
> > compile-time, so you only have to do it once, and never at runtime.
>
> You and Nicholas are both right. I saw sizeof() but thought
> strlen(). With Patrick's suggestion to use the name
> string_from_literal() instead, I'm satisfied.
Great! Here's a reissued patch with the name changed to
string_from_literal().
Mark
=== compilers/imcc/pbc.c
==
--- compilers/imcc/pbc.c (revision 21001)
+++ compilers/imcc/pbc.c (local)
@@ -534,7 +534,7 @@
/* :multi() n = 1, reg = NULL */
if (!pcc_sub->multi[0]) {
STRING *sig;
-sig = string_from_cstring(interp, "__VOID", 0);
+sig = string_from_literal(interp, "__VOID");
sig_pmc = pmc_new(interp, enum_class_String);
VTABLE_set_string_native(interp, sig_pmc, sig);
=== compilers/pge/PGE/pmc/codestring.pmc
==
--- compilers/pge/PGE/pmc/codestring.pmc (revision 21001)
+++ compilers/pge/PGE/pmc/codestring.pmc (local)
@@ -73,7 +73,7 @@
PIO_printf(interp, "%d %Ss, %d\n", cur_ns, (STRING*)PMC_data(cur_ns), global_serno);
VTABLE_set_integer_native(INTERP, global_serno, 10);
-Parrot_set_global(INTERP, cur_ns, string_from_cstring(INTERP, "$!serno", 0), global_serno);
+Parrot_set_global(INTERP, cur_ns, string_from_literal(INTERP, "$!serno"), global_serno);
}
}
*/
@@ -108,9 +108,9 @@
STRING *format;
STRING *key;
STRING *repl;
-STRING *PERCENT = string_from_cstring(INTERP, "%", 0);
+STRING *PERCENT = string_from_literal(INTERP, "%");
STRING *COMMA = string_from_cstring(INTERP, ",", 0);
-STRING *NEWLINE = string_from_cstring(INTERP, "\n", 0);
+STRING *NEWLINE = string_from_literal(INTERP, "\n");
format = string_copy(interp, orig_format);
@@ -197,14 +197,14 @@
*/
METHOD STRING* escape(STRING *str) {
-STRING *SLASH_U = string_from_cstring(INTERP, "\\u", 0);
-STRING *SLASH_X = string_from_cstring(INTERP, "\\x", 0);
+STRING *SLASH_U = string_from_literal(INTERP, "\\u");
+STRING *SLASH_X = string_from_literal(INTERP, "\\x");
str = string_escape_string(interp, str);
str = Parrot_sprintf_c(interp, "\"%Ss\"", str);
if (string_str_index(interp, str, SLASH_U, 0) >= 0
|| string_str_index(interp, str, SLASH_X, 0) >= 0) {
-str = string_concat(interp, string_from_cstring(interp, "unicode:", 0), str, 0);
+str = string_concat(interp, string_from_literal(interp, "unicode:"), str, 0);
}
return str;
}
=== examples/compilers/japhc.c
==
--- examples/compilers/japhc.c (revision 21001)
+++ examples/compilers/japhc.c (local)
@@ -179,7 +179,7 @@
sub_data->seg = cur_cs;
sub_data->address = cur_cs->base.data;
sub_data->end = cur_cs->base.data + cur_cs->base.size;
-sub_data->name = string_from_cstring(interpreter, "JaPHC", 0);
+sub_data->name = string_from_literal(interpreter, "JaPHC");
return sub;
}
=== include/parrot/string_funcs.h
==
--- include/parrot/string_funcs.h (revision 21001)
+++ include/parrot/string_funcs.h (local)
@@ -175,6 +175,9 @@
__attribute__nonnull__(1)
__attribute__warn_unused_result__;
+#define CSTRING_WITH_LEN(s) (s ""), (sizeof(s)-1)
+#define string_from_literal(i,s) string_from_cstring((i),CSTRING_WITH_LEN(s))
+
PARROT_API STRING * string_from_int( Interp *interp /*NN*/, INTVAL i )
__attribute__nonnull__(1);
=== languages/APL/src/pmc/aplvector.pmc
==
--- languages/APL/src/pmc/aplvector.pmc (revision 21001)
+++ languages/APL/src/pmc/aplvector.pmc (local)
@@ -114,7 +114,7 @@
INTVAL array_t;
STRING* property_name;
-property_name = string_from_cstring(INTERP,"shape",0);
+property_name = string_from_literal(INTERP,"shape");
shape = VTABLE_getprop(INTERP, SELF, property_name);
if (PMC_IS_NULL(shape)) {
/*
@@ -126,7 +126,7 @@
*/
/*
array_t = pmc_type(INTERP,
-string_from_cstring(INTERP, "APLVector", 0)
+string_from_literal(INTERP, "APLVector")
);
*/
shape = pmc_new(INTERP,VTABLE_type(INTERP,SELF));
@@ -165,7 +165,7 @@
INTVAL old_size,new_size,pos;
/*
Re: [perl #41497] [TODO] config - profiling options are specific to gcc in config/init/defaults.pm
On Sun, 24 Jun 2007 21:13:14 -0700
"James Keenan via RT" <[EMAIL PROTECTED]> wrote:
> The profiling options code in config/init/defaults.pm reads:
>
> if ( $conf->options->get('profile') ) {
> $conf->data->set(
> cc_debug => " -pg ",
> ld_debug => " -pg ",
> );
> }
>
> Can anyone confirm that these are indeed gcc-specific? Thanks.
This flag convinces gcc to generate profiling code specifically for
the GNU profiler, "gprof". I find it *extremely* unlikely that this
flag would be available and/or mean the same thing for other compilers,
but I do not currently have any others to test with.
Mark
Re: [perl #43481] t/examples/shootout.t (shootout_16.pir) fails on gentoo/x86
On Mon, 02 Jul 2007 16:46:54 -0700 Mark Glines (via RT) <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] ~/parrot $ ./parrot > "/home/paranoid/parrot/t/examples/shootout_16.pir" > [cgt]gggtaaa|tttaccc[acg] 3 a[act]ggtaaa|tttacc[agt]t 9 > ag[act]gtaaa|tttac[agt]ct 8 > agg[act]taaa|ttta[agt]cct 10 > aggg[acg]aaa|ttt[cgt]ccct 3 > agggt[cgt]aa|tt[acg]accct 4 > agggta[cgt]a|t[acg]taccct 3 > agggtaa[cgt]|[acg]ttaccct 5 > Segmentation fault (core dumped) ...but that test script is pretty huge. Here's a simplified test case (attached). The segfault is in the implementation of an op (substr_s_i_i_s). It calls string_replace() to replace a substring with another, but calls it with a NULL "rep" pointer. String_replace is declared with /*NULLOK*/ for the "rep" pointer, but it then calls string_rep_compatible() (whose arguments are /*NN*/) without checking for nullness first. Sooo... I'm not sure if the "rep" argument is NULL for the same *reason* as the above script (a comment from Coke has made me paranoid that a DOD run may be to blame), but should this emit an error message, or fix it up by using '' instead, or punt to the 3-argument substr() instead, rather than segfaulting? Mark test.pir Description: Binary data
Re: [perl #43481] t/examples/shootout.t (shootout_16.pir) fails on gentoo/x86
On Tue, 3 Jul 2007 12:10:37 -0500 Andy Lester <[EMAIL PROTECTED]> wrote: > > Problem 2, why is this test case passing a NULL pointer all of a > > sudden, exposing Problem #1? Presumably, this used to work. > > That I can't tell. All I'm looking at is the underlying C code, > where it seems to me that passing in a rep of NULL should not be > allowed. Agreed, and this should be fixed. I'm just worried that this is working around a symptom, rather than the actual bug (which is that the regexdna.pir shooutout test has changed behavior, and begun passing a NULL pointer). I tried various workarounds... calling string_substr() from substr_s_i_i_s if rep was null, passing to string_substr() from within string_replace() if rep was null, that kind of thing. The shootout test runs to completion, but still fails: the last line of output had some differing digits. (Apparently some string was supposed to be replaced, and just returning a substr without replacing anything isn't sufficient.) So, while I agree that the "crashing on NULL rep" bug needs to be fixed, I've been mostly focusing on staring at regexdna.pir, hoping to find a fix for the "passing a NULL rep in the first place" bug. Mark
Re: [perl #43481] t/examples/shootout.t (shootout_16.pir) fails on gentoo/x86
On Tue, 03 Jul 2007 09:34:29 -0700 "Andy Lester via RT" <[EMAIL PROTECTED]> wrote: > > Sooo... I'm not sure if the "rep" argument is NULL for the same > > *reason* as the above script (a comment from Coke has made me > > paranoid that a DOD run may be to blame), but should this emit an > > error message, or fix it up by using '' instead, or punt to the > > 3-argument substr() instead, rather than segfaulting? > > The problem seems to be that string_replace's rep should indeed be NN, > not NULLOK. Do you see when it would make sense to pass in NULL rep > to string_replace? I don't think so, there's a separate string_substr() function for that, and the other variants of the "substr" op use that one instead of this. I think the problem is two-fold. Problem 1, why does string_replace() crash when passed a NULL rep argument? Problem 2, why is this test case passing a NULL pointer all of a sudden, exposing Problem #1? Presumably, this used to work. My simplified test case demonstrates Problem #1, but I've thus far failed to figure Problem #2 out. Mark
Re: [perl #43481] t/examples/shootout.t (shootout_16.pir) fails on gentoo/x86
On Tue, 3 Jul 2007 10:18:59 -0700 Mark Glines <[EMAIL PROTECTED]> wrote: > So, while I agree that the "crashing on NULL rep" bug needs to be > fixed, I've been mostly focusing on staring at regexdna.pir, hoping > to find a fix for the "passing a NULL rep in the first place" bug. The behavior of this testcase changed last Thursday, in svn r19441. Patrick's patch to compilers/pge/PGE/Exp.pir seems to be the cause. r19441 | pmichaud | 2007-06-28 19:14:11 -0700 (Thu, 28 Jun 2007) | 3 lines [pge]: * Remove find_type from PGE/Exp.pir (w/test). The test case is: $ ./parrot examples/shootout/regexdna.pir
Re: [perl #43481] t/examples/shootout.t (shootout_16.pir) fails on gentoo/x86
On Wed, 4 Jul 2007 22:56:48 + [EMAIL PROTECTED] wrote: > > This is on gentoo linux x86. I ran Configure.pl with no arguments. > > Apparently this test passes on chromatic's linux box, and on > > particle's win32 box, but fails on my gentoo box and particle's > > ubuntu box. So its a bit sporadic. > I just tried this test case with a fresh parrot from svn on a sparc > machine running gentoo and got the first set of output. > > I don't know if this helps or confuses. It helps, thanks. Glad to know I can't just blame gentoo. After doing the binary search I mentioned earlier and finding that it started breaking in svn r19441, there was some discussion in the IRC channel. The important bit is: [13:35] <@chromatic> Hm, I don't blame 19441 for the shootout test. [13:35] <@chromatic> I think it just changed the memory characteristics of the program sufficiently to trigger a lurking GC bug. So now I'll try to see if there was a DOD run that freed up something it shouldn't have, or something like that. Thanks for testing! Mark
Splint runs!
Thanks to Paul Cochrane, I am now able to run splint on the parrot
sources. I'm using git-svn to sync his "splint" branch up with the
latest changes from trunk, so this is current as of svn r19710.
Summary:
Error TypeReported Suppressed
=== =
nullderef0 536
nullpass 01072
nullret 0 409
nullstate0 696
nullassign 0 153
usedef 0 223
compdef 04084
initallelements 17 0
incondefs1 762
matchfields 0 933
realcompare 0 245
unsignedcompare 0 2
nullptrarith 0 7
bitwisesigned06272
shiftnegative0 114
shiftimplementation 06705
sizeoftype 03942
fixedformalarray 8 374
formalarray 01389
boolops 01303
predboolint 0 14
predboolptr 01140
predboolothers 841 39
abstract 0 9
mutrep 0 188
mustfreefresh04082
mustfreeonly 04731
usereleased 0 335
compdestroy 0 23418
branchstate 01417
compmempass 01801
stackref 5 3
dependenttrans 0 23
onlytrans0 815
onlyunqglobaltrans 0 4
temptrans03900
kepttrans0 277
immediatetrans 0 50
statictrans 0 50
unqualifiedtrans 0 701
staticinittrans 0 8
readonlytrans01321
aliasunique 1 0
mayaliasunique 0 9
observertrans0 57
modobserver 2 0
globs0 268
evalorder5 0
evalorderuncon 0 136
casebreak 648 618
looploopbreak0 42
loopswitchbreak 0 613
switchswitchbreak0 57
looploopcontinue 0 29
ifempty 3 0
noeffect 126 0
retvalother 0 776
retvalint01104
sefuncon 0 7
namechecks 3 0
isoreserved 0 24311
fcnuse 82 423
paramuse 0 12552
varuse 19 15
declundef 37 0
oldstyle 0 8
exitarg 0 16
shadow 49 98
nestedextern25 42
redecl 03048
redef 13881628
exporttype 0 262
includenest 21 288
type 0 10588
enummembers 0 186
formatconst 0 13
voidabstract 0 7
castfcnptr 0 171
charindex0 10
ignoresigns 2 0
sysunrecog 1 0
unrecog 16 0
bufferoverflowhigh 52 0
warnlintcomments 0 3
=
Total 3352 130932
Full log: http://squawk.glines.org/splint2-try3.log
Mark
Re: Splint runs!
On Mon, 09 Jul 2007 20:17:03 -0400 James E Keenan <[EMAIL PROTECTED]> wrote: > Can you give us splint noobs a rundown on how to interpret this data? > Thanks. Click the link ( http://squawk.glines.org/splint2-try3.log ), look for warnings that look interesting, and fix them. :) 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
[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
-C and C).
+C and C); and
+=item *
+
+a count of the newlines we consumed while parsing this statement.
+
=back
B Called internally by C.
@@ -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 C
[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 );
Re: Splint upgrade released
On Fri, 13 Jul 2007 23:39:06 -0500 Andy Lester <[EMAIL PROTECTED]> wrote: > All you splint users, go get the new download. > > http://splint.org/download.html > > Rock on, splinters! Thanks, Andy! I'm already bugging the Gentoo folks to version-bump their package. There's an ebuild attached to http://bugs.gentoo.org/show_bug.cgi?id=185269 if any Gentoo users want it. Mark
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:
> 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.
Ever get the feeling you're just talking to yourself? I do.
Andy's r19845 changes changed the generated .c output slightly, which
broke the tests I had added. Here is an updated patch to
t/tools/pmc2c.t, to make them pass again.
Mark
=== t/tools/pmc2c.t
==
--- t/tools/pmc2c.t (revision 21481)
+++ 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(PARROT_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(PARROT_INTERP, PMC *pmc)
+#line 4
+END_C
+
# Local Variables:
# mode: cperl
# cperl-indent-level: 4
Re: [perl #43899] [BUG] 'make' broken on Darwin
On Sat, 14 Jul 2007 11:54:26 -0700
James Keenan (via RT) <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by James Keenan
> # Please include the string: [perl #43899]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=43899 >
>
>
> I've gotten 'make' failures twice on Darwin this afternoon, both
> after 'make realclean' and 'svn update'. (But 'make' is passing on
> my Linux box.)
>
> Please see attached failure report. Thank you very much.
I nopasted this in #parrot, but I figured I'd attach it here too.
Looks like there are 4 copies of this function, for different system
file formats. And r19674 updated the API, but missed one.
Anyway, I think this patch will fix your builds. Please test it?
Mark
=== src/exec_save.c
==
--- src/exec_save.c (revision 21453)
+++ src/exec_save.c (local)
@@ -461,7 +461,7 @@
#ifdef EXEC_MACH_O
void
-Parrot_exec_save(Parrot_exec_objfile_t *obj, const char *file)
+Parrot_exec_save(PARROT_INTERP, Parrot_exec_objfile_t *obj, const char *file)
{
FILE *fp;
int i;
Re: Documenting the PARROT_XXX macros
On Sun, 15 Jul 2007 23:48:54 -0500 Andy Lester <[EMAIL PROTECTED]> wrote: > I want to document all the PARROT_XXX macros that I've been creating > and applying, but I'm not sure where they'd be best. I don't think > pdd07_codingstd.pod is right, because it's not coding standards > exactly. I want to talk about defensive programming, and why these > macros are good, and consting is good, and all the seat belts I'm > trying to put in place. I'm thinking a new doc is in order. There's two similar subjects here. One is, all of the features you're adding to save us from our stupid coding mistakes, how they work, why they work, that kind of thing. The second is, how to use those features when writing code. The latter should definitely go in PDD07. But I think you're right, the former doesn't really fit there. Though it could certainly be referenced from there. My two cents, Mark
Re: [perl #44009] src/dynext.c casting warnings
On Tue, 17 Jul 2007 16:32:09 -0700 "jerry gay" <[EMAIL PROTECTED]> wrote: > that's a big, ugly mess of macros. your solution is concise, but void > pointers are dangerous and should be avoided wherever possible. it's > not a coding standard yet, but it will be *soon*. perhaps there's a > solution that's both easier on the eyes, and safer. I agree that void* pointers are dangerous, but hey, that's what Parrot_dlsym returns. Macros can gloss over the issue, but at some point, you have to assign Parrot_dlsym's void* return value to something else, and hope you get that right. You can try to hide it behind some macros, which is what UINTVAL2PTR() is for, and I did try that, and it didn't work. Short of storing symbol-prototype information in a special linker section and strcmp()ing that at runtime, which is probably even *uglier* and less portable, I don't know what else you can do here. But I'm open to suggestions. Mark
Re: [perl #44041] [CAGE] Verify all functions are used
On Wed, 18 Jul 2007 09:58:12 -0700 Andy Lester (via RT) <[EMAIL PROTECTED]> wrote: > Verify that all functions actually get used. We could do this by > either: > > * Creating a tool that verifies that each function is used at least > once > > * Run splint with whatever flags necessary to do global reference > matching. And then sift out the ones which get used for other configurations / platforms than your own. Mark
[PATCH] [PDD] PDD07: header guard example should use #ifndef
Hi, A while back, I submitted some patches to fix up header guards, make their syntax consistent and such. These were applied in r18461, r18464, and others. PDD07 contains an example which is no longer consistent with the current headers. I'm submitting this patch for review. It changes "#if !defined(PARROT__H_GUARD)" into "#ifndef PARROT__H_GUARD" in PDD07's example. Also note that PDD07 actually has two header guard examples; grep for PARROT__H_GUARD and grep for PARROT_FOO_H_GUARD. I think these should be consolidated as well, but this patch does not address that. Mark Index: docs/pdds/pdd07_codingstd.pod === --- docs/pdds/pdd07_codingstd.pod (revision 20368) +++ docs/pdds/pdd07_codingstd.pod (working copy) @@ -631,7 +631,7 @@ /* file header comments */ -#if !defined(PARROT__H_GUARD) +#ifndef PARROT__H_GUARD #define PARROT__H_GUARD /* body of file */
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: > 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. tewk's branch merge (r20228) seems to have fixed this. The tests should still be valid, so I've added those, but the main issue of this ticket is now resolved. Mark
Re: [perl #42938] [BUG] allocation failures in res_lea.c
On Thu, 31 May 2007 23:09:54 -0700 Mark Glines <[EMAIL PROTECTED]> wrote: > The code in utf8_encode_and_advance is beautiful. It basically says, > add a utf8 character to the buffer. Ok, now did we overrun the > buffer? CRASH! So if I add a call to Parrot_reallocate_string if the buffer isn't big enough, I get a warning about the const flag being discarded on i->str. I could just cast around it, but it makes me wonder: if String_iter's STRING member is const, then why are we writing to it? I guess I'm hoping someone can explain the purpose of String_iter. To me it just looks like an abstraction to hide the details of UTF8 or UCS32 or whatever encoding, but this doesn't explain why the string needs to be const. Mark
Re: [perl #37287] [TODO] pdb - don't die on exceptions
> This patch makes parrot stop execution of the vm when running as a > debugger. > > This makes the pdb stop executing and shows the exception message > instead of silently exiting. Hi, pancake! I have tried to update your patch to svn r20469, see attached patch. Unfortunately, it doesn't work any longer. I wrote a simple test file (see attached test.pir) that just generates an exception. Then I tried to run it under parrot, and it generated an exception, as expected. [EMAIL PROTECTED] ~/parrot $ ./parrot test.pir Null PMC access in get_string() current instr.: 'main' pc 0 (test.pir:3) Problem is, when I then ran it under pdb, it died pretty horribly. [EMAIL PROTECTED] ~/parrot $ ./pdb test.pir Parrot Debugger 0.4.x Please note: the debugger is currently under reconstruction (pdb) r Restarting Hijacked exception: Null PMC access in get_string() Restarting *** glibc detected *** ./pdb: free(): invalid pointer: 0xb6f191b8 *** === Backtrace: = /lib/libc.so.6[0xb6e4efaf] /lib/libc.so.6(__libc_free+0x89)[0xb6e4fce9] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(mem_sys_free+0x23)[0xb7c3b9b3] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(PDB_free_file+0x98)[0xb7c2eb38] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(PDB_disassemble+0x62)[0xb7c2e712] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(Parrot_debug+0x65)[0xb7c31c85] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(runops_slow_core+0x60)[0xb7c76130] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(runops_int+0x190)[0xb7c46b80] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(runops+0xfd)[0xb7c474cd] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14[0xb7c476e6] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(Parrot_runops_fromc_args+0x36)[0xb7c477f6] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(Parrot_runcode+0x22f)[0xb7c31c0f] ./pdb(main+0x2d2)[0x8048f22] /lib/libc.so.6(__libc_start_main+0xe2)[0xb6dfe9d2] ./pdb[0x8048bb1] === Memory map: 08048000-0804a000 r-xp fe:03 636705 /home/paranoid/parrot/pdb 0804a000-0804b000 rw-p 1000 fe:03 636705 /home/paranoid/parrot/pdb 0804b000-0841 rw-p 0804b000 00:00 0 [heap] b5b0-b5b21000 rw-p b5b0 00:00 0 b5b21000-b5c0 ---p b5b21000 00:00 0 b5cca000-b5d0c000 rw-p b5cca000 00:00 0 b5d0c000-b5d0d000 ---p b5d0c000 00:00 0 b5d0d000-b650d000 rw-p b5d0d000 00:00 0 b650d000-b650e000 ---p b650d000 00:00 0 b650e000-b6d1 rw-p b650e000 00:00 0 b6d1-b6d18000 r-xp fe:00 292092 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.6/libgcc_s.so.1 b6d18000-b6d19000 rw-p 7000 fe:00 292092 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.6/libgcc_s.so.1 b6d19000-b6ddf000 r-xp fe:00 292103 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3 b6ddf000-b6de4000 rw-p 000c6000 fe:00 292103 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3 b6de4000-b6de9000 rw-p b6de4000 00:00 0 b6de9000-b6f16000 r-xp 03:01 40041 /lib/libc-2.6.so b6f16000-b6f17000 r--p 0012d000 03:01 40041 /lib/libc-2.6.so b6f17000-b6f19000 rw-p 0012e000 03:01 40041 /lib/libc-2.6.so b6f19000-b6f1c000 rw-p b6f19000 00:00 0 b6f1c000-b6f57000 r-xp 03:01 6397 /lib/libncurses.so.5.6 b6f57000-b6f6 rw-p 0003a000 03:01 6397 /lib/libncurses.so.5.6 b6f6-b6f8c000 r-xp 03:01 20277 /lib/libreadline.so.5.2 b6f8c000-b6f9 rw-p 0002b000 03:01 20277 /lib/libreadline.so.5.2 b6f9-b6f92000 rw-p b6f9 00:00 0 b6f92000-b6fc3000 r-xp fe:00 7746 /usr/lib/libgmp.so.3.4.1 b6fc3000-b6fc4000 rw-p 00031000 fe:00 7746 /usr/lib/libgmp.so.3.4.1 b6fc4000-b6fcb000 r-xp 03:01 35535 /lib/librt-2.6.so b6fcb000-b6fcd000 rw-p 6000 03:01 35535 /lib/librt-2.6.so b6fcd000-b6fcf000 r-xp 03:01 40037 /lib/libutil-2.6.so b6fcf000-b6fd1000 rw-p 1000 03:01 40037 /lib/libutil-2.6.so b6fd1000-b6fd6000 r-xp 03:01 40035 /lib/libcrypt-2.6.so b6fd6000-b6fd8000 rw-p 4000 03:01 40035 /lib/libcrypt-2.6.so b6fd8000-b6fff000 rw-p b6fd8000 00:00 0 b6fff000-b7001000 r-xp 03:01 40028 /lib/libdl-2.6.so b7001000-b7003000 rw-p 1000 03:01 40028 /lib/libdl-2.6.so b7003000-b7016000 r-xp 03:01 6394 /lib/libnsl-2.6.so b7016000-b7018000 rw-p 00012000 03:01 6394 /lib/libnsl-2.6.so b7018000-b701b000 rw-p b7018000 00:00 0 b701b000-b79ca000 r--p fe:00 384232 /usr/lib/libicudata.so.36.0 b79ca000-b79cb000 rw-p 009ae000 fe:00 384232 /usr/lib/libicudata.so.36.0 b79cb000-b7adc000 r-xp fe:00 403052 /usr/lib/libicuuc.so.36.0 b7adc000-b7ae3000 rw-p 00111000 fe:00 403052 /usr/lib/libicuuc.so.36.0 b7ae3000-b7ae5000 rw-p b7ae3000 00:00 0 b7ae5000-b7b08000 r-xp 03:01 40040 /lib/liAborted [EMAIL PROTECTED] ~/parrot $ It's a useful patch, and I think it *almost* works. Maybe pdb itself is broken. Also note I've created a test program[1] for pdb,
Re: More on the HLL/Tcl Fix
On Sun, 5 Aug 2007 23:44:16 -0700
chromatic <[EMAIL PROTECTED]> wrote:
> +enum {
> +e_HLL_name,
> +e_HLL_lib,
> +e_HLL_typemap,
> +e_HLL_MAX
> +} HLL_enum_t;
> +
Shouldn't that be a typedef? In other words:
typedef enum {...} HLL_enum_t;
I think that'll fix Coke's build failure.
Mark
Re: [perl #44379] config/auto/attributes.pm ought to use its own test_c.in
On Mon, 6 Aug 2007 15:20:39 -0700
chromatic <[EMAIL PROTECTED]> wrote:
> On Monday 06 August 2007 15:10:30 Andy Lester wrote:
>
> > On Mon, Aug 06, 2007 at 02:40:06PM -0700, chromatic
> > ([EMAIL PROTECTED])
> wrote:
>
> > > I find these two lines confusing:
> > >
> > > my %eval = eval cc_run();
> > > return if !%eval;
>
> > Have you looked at the string it returns? It looks like this:
> >
> > (
> >GCC_VERSION => 3,
> >GCC_MINOR => 4
> >);
> >
> > Or something similar. It perplexed me as well.
>
> I thought so too, but the probe uses config/auto/attributes/test_c.in:
>
> /* as long as the file compiles, everything is okay */
> int
> main(int argc, char *argv[])
> {
> return EXIT_SUCCESS;
> }
>
> That's not exactly the same as a stringified hash. I think we can
> just remove the cc_run() bits and be fine (at least, it worked for
> me).
I just chased this down, and then found this mailing list thread. So
please excuse my arriving late to the party :)
Currently (r20530), I'm not getting *any* attributes defined on my x86
linux box, because of this. This despite the fact that gcc 3.4.6
supports lots (if not all) of the attributes, and Configure.pl
--verbose reports "exit code 0" (meaning, success).
cc_run() returns "", eval cc_run() returns (), which fails the !%eval
check on the line below. Which means lots of nice things,
PARROT_DOES_NOT_RETURN for instance, are currently noops in my build.
Removing the cc_run bit sounds like the right fix to me, too. The whole
stringified hash thing seems to be used elsewhere to detect compiler
version, but we don't need anything compiler-specific in this
particular check. The important part is that it built, which was
already checked.
Mark
Re: [perl #44379] config/auto/attributes.pm ought to use its own test_c.in
On Mon, 6 Aug 2007 15:20:39 -0700 chromatic <[EMAIL PROTECTED]> wrote: > That's not exactly the same as a stringified hash. I think we can > just remove the cc_run() bits and be fine (at least, it worked for > me). Indeed, with the attached patch I have working attributes again. Mark Index: config/auto/attributes.pm === --- config/auto/attributes.pm (revision 20530) +++ config/auto/attributes.pm (working copy) @@ -66,7 +66,7 @@ my $ccflags = $conf->option_or_data( 'ccflags'); my $tryflags = "$ccflags -D$attr"; -# These are OK to fail, becuase we're trying them out. +# These are OK to fail, because we're trying them out. my $command_line = "$cc -o test -Iinclude $tryflags test.c"; $verbose and print " ", $command_line, $/; @@ -75,9 +75,6 @@ return if $exit_code; -my %eval = eval cc_run(); -return if !%eval; - $conf->data->set( ccflags => $tryflags ); return;
Re: [perl #43481] t/examples/shootout.t (shootout_16.pir) fails on gentoo/x86
On Thu, 9 Aug 2007 22:19:29 -0500 "Patrick R. Michaud" <[EMAIL PROTECTED]> wrote: > On Thu, Aug 09, 2007 at 04:37:30PM -0600, Lloyd Miller wrote: > > >(Like you, I'm also running kubuntu feisty on an x86_64 system, > > >gcc 4.1.2.) > > > > OK, I tried svn r20585 and this fail is gone from make test. > > Excellent. Thanks for confirming. > > I'm looking to close this ticket if we can... is anyone > still seeing a failure in the shootout/regexdna.pir test > in the latest svn HEAD ? If so, what OS and architecture? Sorry, regexdna.pir still segfaults here. svn r20595, Linux x86 (gentoo hardened). [EMAIL PROTECTED] ~/parrot $ prove t/examples/shootout.t t/examples/shootoutok 15/20 # Failed test (t/examples/shootout.t at line 104) # Exited with error code: 139 # Received: # agggtaaa|tttaccct 0 # [cgt]gggtaaa|tttaccc[acg] 3 # a[act]ggtaaa|tttacc[agt]t 9 # ag[act]gtaaa|tttac[agt]ct 8 # agg[act]taaa|ttta[agt]cct 10 # aggg[acg]aaa|ttt[cgt]ccct 3 # agggt[cgt]aa|tt[acg]accct 4 # agggta[cgt]a|t[acg]taccct 3 # agggtaa[cgt]|[acg]ttaccct 5 # sh: line 1: 30855 Segmentation fault ./parrot "/home/paranoid/parrot/t/examples/shootout_16.pir" < examples/shootout/regexdna.pir.input # # Expected: # agggtaaa|tttaccct 0 # [cgt]gggtaaa|tttaccc[acg] 3 # a[act]ggtaaa|tttacc[agt]t 9 # ag[act]gtaaa|tttac[agt]ct 8 # agg[act]taaa|ttta[agt]cct 10 # aggg[acg]aaa|ttt[cgt]ccct 3 # agggt[cgt]aa|tt[acg]accct 4 # agggta[cgt]a|t[acg]taccct 3 # agggtaa[cgt]|[acg]ttaccct 5 # # 101745 # 10 # 133640 # t/examples/shootoutok 18/20# Looks like you failed 1 test of 20. t/examples/shootoutdubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 16 Failed 1/20 tests, 95.00% okay Failed Test Stat Wstat Total Fail List of Failed --- t/examples/shootout.t1 256201 16 Failed 1/1 test scripts. 1/20 subtests failed. Mark
Re: [perl #38982] [CAGE] refactor long test files
On Sun, 19 Aug 2007 19:19:22 -0500 Andy Lester <[EMAIL PROTECTED]> wrote: > > On Aug 19, 2007, at 7:15 PM, David Romano wrote: > > > The patch splits string.t (originally almost 3000 lines) into > > different > > files, as well as moves some of the tests for sprintf into > > t/op/sprintf_tests. > > Why is this a good thing, to be splitting up the files like this? I > can see sprintf getting their own, but why is 3000 lines a bad thing? First thing that comes to mind, splitting it up associates the individual tests with more descriptive filenames, which makes it easier to see what broke at a glance. My $0.02, Mark
Re: [perl #44769] [BUG] Parrot failing to 'make' on Darwin
On Mon, 20 Aug 2007 16:00:28 -0700 chromatic <[EMAIL PROTECTED]> wrote: > On Monday 20 August 2007 05:13:07 James E Keenan wrote: > > > t/src/compiler# > > '/usr/bin/g++-3.3 -L/usr/local/lib  t/src/compiler_2.o > > src/parrot_config.o -o t/src/compiler_2 blib/lib/libparrot.a  -lm' > > failed with exit code 1 # Failed to build 't/src/compiler_2': ld: > > multiple definitions of symbol _PMCNULL # t/src/compiler_2.o > > definition of _PMCNULL in section (__DATA,__common) # > > blib/lib/libparrot.a(pmc.o) definition of _PMCNULL in section > > (__DATA,__common) > > This one looks like fallout of r20649. Mark? I don't believe r20649 would cause duplicate definitions. Missing definitions, sure, but not duplicates. No, I think this is fallout from the win32 workaround I mentioned to you in #parrot a few days ago... a different commit. See r20641. The correct solution is to fix PARROT_API so libparrot.dll exports the PMCNULL global correctly, which will fix win32, and to remove the "PMCNULL" definitions from t/src/compiler.t, which will fix Darwin. I've been working on the win32 linker part of that, but haven't made any progress yet. I've been trying to make a test dll project to play with, but I can't seem to convince the linker to do the same thing with my dll that it does with parrot's. (It neglects to generate a .lib file, which seems needed for linking applications against the dll.) Mark
Re: [perl #44783] [PATCH] t/distro/file_metadata.t and git
On Sun, 19 Aug 2007 22:22:06 -0700 David Romano (via RT) <[EMAIL PROTECTED]> wrote: > # New Ticket Created by David Romano > # Please include the string: [perl #44783] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=44783 > > > > Testing svn file metadata isn't always appropriate when using git. > When git mirrors an svn repo, it can store the metadata for each file > in .git/svn/git-svn/unhandled.log, but sometimes the user chooses not > to store the metadata. If the user does store it, this patch allows > for the tests to pass (and not hang). If the user doesn't have the > metadata but has a .git directory, then the tests are skipped. Thanks, applied as r20743. I've used git-svn once or twice in the past for some branch merging, and it was a bit rough; the test suite hated it. Anything to make its use easier is a good thing, in my book. :) Mark
Current win32 linking issues: Summary
The parrot needs help, hopefully before tomorrow's release. There are two issues with linking against libparrot.dll on win32: 1. It refuses to export the "_PMCNULL" symbol (the PMCNULL global variable defined at the top of src/pmc.c), and thus, embedders cannot use the PMC_IS_NULL macro. This causes t/src/compiler.t to fail. Jerry added a workaround in r20641, declaring a local variable PMCNULL within the test code, to get it to pass. Unfortunately, this workaround causes Darwin to fail with the message "ld: multiple definitions of symbol _PMCNULL". 2. The filenames written by Configure.pl are wrong. This causes the linker command line to get the wrong library-name. It looks like this: # 'link -nologo -nodefaultlib -debug -machine:x86 -debug t\src\string_3.obj src\parrot_config.obj -out:t\src\string_3.exe -Lblib\lib libparrot$(A) kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib' failed with exit code 80 # LINK : fatal error LNK1104: cannot open file 'libparrot$(A).obj' The variable $(A) is not expanded properly in the win32 shell. Quoth the Jerry: [18:30] <@particle> with gcc, you do "-lparrot" to find the library [18:31] <@particle> on win32, you do "libparrot.lib" [18:31] <@particle> in Parrot::Config, it's stored as "libparrot$(A)" [18:31] <@particle> during make, that evaluates to "libparrot.lib" [18:31] <@particle> but not in the shell, which is where that value is being used [18:31] <@particle> 2 ways to fix [18:32] <@particle> 1: put something in Parrot::Config that has what win32 needs [18:32] <@particle> 2: make a function available in Parrot::Config that resolves the variables, and call the func Once these two issues are resolved, the extra PMCNULL variables should be removed from t/src/compiler.t, which will make Darwin happy too. :) Please help! I'm clueless about win32... Mark
Re: Current win32 linking issues: Summary
On Mon, 20 Aug 2007 18:37:05 -0700 Mark Glines <[EMAIL PROTECTED]> wrote: > Jerry added a workaround in r20641, declaring a local variable > PMCNULL within the test code, to get it to pass. Unfortunately, this > workaround causes Darwin to fail with the message "ld: multiple > definitions of symbol _PMCNULL". Quick followup: in r20750, I reverted this portion of r20641. The test passes again on Darwin, and is skipped again on win32. (I kept the typo fixes in compiler.t, and I didn't revert r20641's changes to the other test files.) The win32 skippage will need to be removed again, once the PMCNULL symbol is exported correctly from libparrot.dll. Mark
Re: [perl #44809] [PATCH] use Storable instead of Data::Dumper for PMC .dump files
On Tue, 21 Aug 2007 09:52:01 -0700
chromatic <[EMAIL PROTECTED]> wrote:
> return unless -f $filename;
> return retrieve($filename);
>
> My preference is the latter, for clarity and context reasons.
Thanks, you're absolutely right. Here's an updated patch.
Mark
Index: lib/Parrot/Pmc2c/Pmc2cMain.pm
===
--- lib/Parrot/Pmc2c/Pmc2cMain.pm (revision 20762)
+++ lib/Parrot/Pmc2c/Pmc2cMain.pm (working copy)
@@ -4,7 +4,7 @@
use strict;
use warnings;
use FindBin;
-use Data::Dumper;
+use Storable;
use Parrot::Vtable;
use Parrot::PMC;
use Parrot::Pmc2c::VTable;
@@ -226,7 +226,7 @@
$self->read_dump('filename');
B A F<.dump> file is the result of a call to C and
-consists of a print-out of a hash reference Data::Dumper-style.
+consists of a binary dump of a hash reference, Storable-style.
C reads in the F<.dump> file, recreates the data structure and
returns a new hash reference holding the data structure.
@@ -248,11 +248,8 @@
my ( $self, $filename ) = @_;
$filename = $self->find_file( filename($filename, '.dump'), 1 );
-my $class;
-eval do { slurp($filename); };
-die $@ if $@;
-
-return $class;
+return unless -f $filename;
+return retrieve($filename);
}
=head3 C
Index: lib/Parrot/Pmc2c/VTable.pm
===
--- lib/Parrot/Pmc2c/VTable.pm (revision 20762)
+++ lib/Parrot/Pmc2c/VTable.pm (working copy)
@@ -5,7 +5,7 @@
use warnings;
use base qw( Exporter );
our @EXPORT_OK = qw();
-use Data::Dumper;
+use Storable;
use Parrot::Vtable;
use Parrot::Pmc2c::Method;
use Parrot::Pmc2c::UtilFunctions qw(spew);
@@ -73,9 +73,7 @@
my $dump_filename = cwd() . q{/} . basename(
Parrot::Pmc2c::UtilFunctions::filename($self->filename, '.dump') );
-my $Dumper = Data::Dumper->new( [$self], ['class'] );
-$Dumper->Indent(3);
-spew($dump_filename, $Dumper->Dump);
+store($self, $dump_filename);
return $dump_filename;
}
Index: lib/Parrot/Pmc2c/PMC.pm
===
--- lib/Parrot/Pmc2c/PMC.pm (revision 20762)
+++ lib/Parrot/Pmc2c/PMC.pm (working copy)
@@ -25,7 +25,7 @@
use warnings;
use base qw( Exporter );
our @EXPORT_OK = qw();
-use Data::Dumper;
+use Storable;
use Parrot::PMC;
use Parrot::Pmc2c::UtilFunctions qw(spew);
use Parrot::Pmc2c::Method;
@@ -61,9 +61,7 @@
#gen_parent_lookup_info( $self, $pmc2cMain, $pmcs );
#gen_parent_reverse_lookup_info( $self, $pmcs, $vtable_dump );
-my $Dumper = Data::Dumper->new( [$self], ['class'] );
-$Dumper->Indent(1);
-spew($self->filename('.dump'), $Dumper->Dump);
+store($self, $self->filename('.dump'));
}
#methods
Index: config/gen/makefiles/dynpmc_pl.in
===
--- config/gen/makefiles/dynpmc_pl.in (revision 20762)
+++ config/gen/makefiles/dynpmc_pl.in (working copy)
@@ -17,6 +17,10 @@
use warnings;
use File::Copy qw(copy);
+use FindBin;
+use lib "$FindBin::Bin/../..";
+use lib "$FindBin::Bin/../../lib";
+use Storable;
# q[] isn't guaranteed to work, but it's safer than "" as some platforms
# (eg FreeBSD) have ""s embedded in their substution values. q[] is used
@@ -189,8 +193,7 @@
my ( %group_files, %group_libs, %pmc_group, %pmc_libs );
for my $pmc (@pmcs) {
-our $class;
-require "$pmc.dump";
+our $class = retrieve("$pmc.dump");
# there can be many libs
my %libs = %{ $class->{flags}{lib} || {} };
Re: Current win32 linking issues: Summary
On Tue, 21 Aug 2007 13:08:05 +0200 Ron Blaschke <[EMAIL PROTECTED]> wrote: > > The win32 skippage will need to be removed again, once the PMCNULL > > symbol is exported correctly from libparrot.dll. > > Not adding the skip on the other t/src tests will cause them to > fail. I think it would be best to skip them all, or none of them. Hi Ron, I agree. If we can't find a quick fix to get the tests to pass, I can clean things up to make them consistent (all-failing or all-skipped) before the release. I don't have a preference which route we take. > Don't know if its a problem if they fail. I don't have a problem with > failures as they tell me there's something that needs attention. True. Well, these issues do need attention, so maybe they *should* fail. :) 1. Do you have any ideas for how we need to decorate PMCNULL so it gets exported by the dll? PARROT_API doesn't seem to be sufficient. I think maybe its because its a variable, not a function. 2. Do you have any preference on how we fix up the Parrot::Config stuff so we can put "libparrot.lib" on the link command-line for win32, in the t/src/ tests? Sorry to ask so many questions, but I'm a linux geek, and utterly clueless about win32... Mark
Re: Current win32 linking issues: Summary
On Wed, 22 Aug 2007 11:16:12 +0200 Ron Blaschke <[EMAIL PROTECTED]> wrote: > >> Don't know if its a problem if they fail. I don't have a problem > >> with failures as they tell me there's something that needs > >> attention. > > > True. Well, these issues do need attention, so maybe they *should* > > fail. :) > > Jerry mentioned yesterday that there shouldn't be any failures for a > release, which makes sense as it would only upset users. Maybe there > should be a ticket for the failures then? Or an environment variable > like PARROT_PORTER which makes all tests fail that are skipped because > they are broken, not because the feature is not supported on the > platform? Or maybe we should wait until the release, then stop skipping the error, which should help ensure it gets fixed before the next release. (It is a pretty important issue, I think, so I don't want to mask it any longer than absolutely necessary. Embeddability is important to me.) > Many thanks for helping with the t/src issues, I'm glad you jumped on > the Windows train. Some things work differently on Windows and Visual > C++, especially the linking and loading part, with symbol > exports/imports on the very top. > > One great way to find out about compiled objects, libraries and > executables is the COFF/PE Dumper (dumpbin), which shows details about > the binary image. Another fine tool is the Dependency Walker > (depends), which exactly shows you which libraries would be loaded, > including their full path, what symbols they export and which they > import. Great, good tips. I don't know if I'm really on the "windows train", though. I'm still primarily linux with a bit of freebsd on the side; for me, win32 is mostly in the category of "bizarre platform to make portability testing more interesting". But it will be good to know my way around a little bit better, so I can solve things more quickly next time. :) > Please don't hesitate to ask if you have any questions. Depending on > $job workload it might take some time before I can get back to you, > though. I know the feeling. Thanks! Mark
[perl #44855] Re: Current win32 linking issues: Summary
On Wed, 22 Aug 2007 11:16:12 +0200 Ron Blaschke <[EMAIL PROTECTED]> wrote: > Jerry mentioned yesterday that there shouldn't be any failures for a > release, which makes sense as it would only upset users. Maybe there > should be a ticket for the failures then? I have created ticket #44855 for this issue. It sounds like we need to pass -DIN_LIBPARROT or somesuch to the compiler when compiling objects that end up in libparrot.dll. Then, we can use that to decide how PARROT_API will be defined. Sometime in the next couple of days, I'll see what's required to pass additional defines to the compiler, from within the Makefile system. Mark
Re: [perl #44809] [PATCH] use Storable instead of Data::Dumper for PMC .dump files
Oops. I replied to this on the RT site, but it looks like I neglected to tell it to copy the list (or you). I'll cutpaste my response below. On Tue, 21 Aug 2007 21:02:39 -0400 James E Keenan <[EMAIL PROTECTED]> wrote: > I do have some qualms. > > (1) I know that there have been issues with incompatibility among > different versions of Storable. I myself have been bit by these > issues with different versions of Storable distributed with different > versions of Perl 5.8 (not to mention 5.6). Some of these issues are > alluded to in the POD > (http://search.cpan.org/dist/Storable/Storable.pm#FORWARD_COMPATIBILITY). > I have never heard such compatibility issues with respect to > Data::Dumper. This is not a killer objection, but it should be > considered. > > (2) Not that I'm opposed to Storable entirely. Hey, I use it in > Parrot::Configure::Trace! But there, as in other places I've used > it, I've always found I got better mileage by using 'nstore' instead > of 'store'. Hi! I agree, nstore is more useful for stuff that's kept around for a while, exchanged between machines and so forth. But, keeping in mind these files are built by pmc2c.pl as part of the parrot build process, rebuilt whenever the pmc file changes, and removed whenever you do a "make clean", does forwards compatibility (or even endian-portability) actually matter? Correct me if I'm wrong, but I don't think we keep any of these files around. Mark
Re: [perl #47704] [BUG]Memory leak with STRING's
On Thu, 22 Nov 2007 10:35:21 -0800
"Mehmet Yavuz Selim Soyturk" (via RT)
<[EMAIL PROTECTED]> wrote:
> # New Ticket Created by "Mehmet Yavuz Selim Soyturk"
> # Please include the string: [perl #47704]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=47704 >
>
>
> There is a memory leak with the STRING's. Next C code consumes more
> and more memory, but does not free it:
>
> for(i=0;i<2000;i++) {
> string_from_literal(INTERP, "nothing");
> }
Hi,
Unless I'm mistaken, string_from_literal() is an allocation function.
The string it returns needs to be freed again, with a call to
string_cstring_free(). I think this is true for all of the
string_from_* functions.
If there's a memory leak here, it is not in string_from_literal(), but
rather, in the code that calls it. I think the code you mentioned
in your previous ticket ([perl #47572]) is a good example of that.
Mark
Re: [svn:parrot] r29610 - in branches/pdd13pbc: src/pmc t/pmc
On Saturday 19 July 2008 11:19:27 chromatic wrote: > Poking at strings directly seems unclean; do we need to add another > function to src/packfile.c to return a packed packfile as a C string, > and then create the string directly here in get_string()? I agree, poking around in STRING internals isn't clean, or fun. (Also, the quoted code gets a nice segfault later on because the encoding and charset weren't initialized.) I don't know that a separate function is necessary... I could just allocate the buffer and then wrap a STRING around that afterwards. I will make that change once I've sorted out a couple of other issues, probably later today. As an aside, what's with PARROT_BINARY_CHARSET? It sounds like that's what my strings need to be using for holding binary data, but the comparison function always returns 0. Am I misunderstanding what the binary charset plugin is for? It doesn't look like it's used very often. -- Mark
Re: [perl #57188] [PATCH] pbc_to_exe --install
On Tuesday 22 July 2008 04:56:53 Reini Urban wrote: > Attached patch adds --install to pbc_to_exe, > adds a basic pod to pbc_to_exe, > and applies --install to perl6. > > link against install_config.o and add installable prefix. > Limitation: With --install the first arg infile must have no > directory part! > > Now we can generate make install for the languages. Hi! When I try to apply your patch, I get: [EMAIL PROTECTED] parrot-trunk % patch -p0 <~/Desktop/installable_pbc_to_exe.patch patching file languages/perl6/config/makefiles/root.in patching file tools/dev/pbc_to_exe_gen.pl misordered hunks! output would be garbled Hunk #4 FAILED at 11. misordered hunks! output would be garbled Hunk #5 FAILED at 70. misordered hunks! output would be garbled Hunk #6 FAILED at 318. 3 out of 10 hunks FAILED -- saving rejects to file tools/dev/pbc_to_exe_gen.pl.rej Any chance of getting an in-order diff? If not, could you just attach your pbc_to_exe_gen.pl? Thanks, Mark
Re: Inter-HLL Mapping Notes
On Tuesday 22 July 2008 15:37:33 chromatic wrote: > The wiki page at: > > http://www.perlfoundation.org/parrot/index.cgi?inter_hll_mapping_not >es > > seems to be missing the rationale for *why* it's necessary to map > types between languages? (Also see "If Perl 6 has to care about the > internal storage format of an Integer PMC, it's doing something very > wrong.") Integer is a good example of the problem, actually. The internal storage format doesn't change, but the methods you can call on it definitely will. HLLs wrap the Integer class with their own subclasses, so that they have methods they can call on integers, which are expected by the HLL. But when your perl6 function passes a Perl6Int to a TCL function, TCL HLL code code will try to access the integer, but it's not a TclInt, its a Perl6Int! The value itself is fine, but the methods it expects to find will not be there. Hence the need for conversion/mapping. -- Mark
Re: [perl #57358] Enable parallel testing
On Monday 28 July 2008 09:52:36 Moritz Lenz wrote: > >> t/steps/auto_attributes-01.t (Wstat: 65280 Tests: 9 > >> Failed: 0) Non-zero exit status: 255 > >> Parse errors: Bad plan. You planned 12 tests but ran 9. > >> t/steps/auto_headers-03.t (Wstat: 65280 Tests: 8 > >> Failed: 0) Non-zero exit status: 255 > >> Parse errors: Bad plan. You planned 12 tests but ran 8. If there are interdependencies (or setup/teardown constraints) between those series of tests, maybe we could just merge each series into a single test script? Mark
Re: [perl #57608] [PATCH] add ports/cygwin
On Tuesday 05 August 2008 20:57:53 chromatic wrote: > On Tuesday 05 August 2008 01:35:48 Reini Urban wrote: > > Attached patch adds the directory ports/cygwin with > > the most recent cygports file, > > the most recent src patch and the sources for the CYGWIN patches. > > (the contents of parrot-0.6.4-2.cygwin.patch which creates those > > files in CYGWIN-PATCHES/) > > Thanks, applied as r30048. This patch causes t/codingstd/filenames.t to fail (because the filename has multiple dots). Perhaps an exception should be made in this case? Mark
Re: [perl #59880] DOD crash in r31926, t/op/bitwise.t #27 on linux/x86_64
On Tuesday 14 October 2008 07:14:51 Mark Glines wrote: > On Monday 13 October 2008 16:15:54 chromatic wrote: > > That's pretty clearly not a PMC. Can you use the breakpoint > > technique to figure out 1) What creates this CPointer PMC and > > In the following dump, the offending PMC ix 0x1731de8. The arena's > base pointer varies every time, but I seem to be able to catch it > with a pointer suffix check. Yes, I'm an idiot. I meant 0x20f3de8 of course. I've run through this several times, and like I said, it keeps changing... > Breakpoint 3, Parrot_CPointer_init (interp=0x1f99080, pmc=0x20f3de8) -- Mark
Re: [perl #59880] DOD crash in r31926, t/op/bitwise.t #27 on linux/x86_64
On Monday 13 October 2008 16:15:54 chromatic wrote:
> That's pretty clearly not a PMC. Can you use the breakpoint
> technique to figure out 1) What creates this CPointer PMC and
In the following dump, the offending PMC ix 0x1731de8. The arena's base
pointer varies every time, but I seem to be able to catch it with a
pointer suffix check.
Breakpoint 3, Parrot_CPointer_init (interp=0x1f99080, pmc=0x20f3de8)
at ./src/pmc/cpointer.pmc:67
67 mem_allocate_typed(Parrot_CPointer_attributes);
(gdb) bt
#0 Parrot_CPointer_init (interp=0x1f99080, pmc=0x20f3de8)
at ./src/pmc/cpointer.pmc:67
#1 0x7fa669216be0 in pmc_new (interp=0x1f99080, base_type=52)
at src/pmc.c:93
#2 0x7fa6691dfe74 in Parrot_build_sig_object_from_varargs (
interp=0x1f99080, sig=0x7fa66944bb33 "PPP->P", args=0x7fff71a10230)
at src/multidispatch.c:477
#3 0x7fa6691e05c6 in Parrot_mmd_multi_dispatch_from_c_args (
interp=0x1f99080, name=0x7fa66944c310 "modulus",
sig=0x7fa66944bb33 "PPP->P") at src/multidispatch.c:574
#4 0x7fa6692c159f in Parrot_default_modulus (interp=0x1f99080,
pmc=0x20f3f00, value=0x2072a08, dest=0x2071e70)
at ./src/pmc/default.pmc:1673
#5 0x7fa669172af8 in Parrot_mod_p_p_p (cur_opcode=0x20f36a0,
interp=0x1f99080) at src/ops/math.ops:760
#6 0x7fa669217c2f in runops_slow_core (interp=0x1f99080,
pc=0x20f36a0)
at src/runops_cores.c:222
#7 0x7fa6691d7ed4 in runops_int (interp=0x1f99080, offset=0)
at src/interpreter.c:937
#8 0x7fa6691d88c3 in runops (interp=0x1f99080, offs=0)
at src/inter_run.c:101
#9 0x7fa6691d8b7a in runops_args (interp=0x1f99080, sub=0x20738b0,
obj=0x2026020, meth_unused=0x0, sig=0x7fa669442cfb "vP",
ap=0x7fff71a10500)
at src/inter_run.c:236
#10 0x7fa6691d8d6b in Parrot_runops_fromc_args (interp=0x1f99080,
sub=0x20738b0, sig=0x7fa669442cfb "vP") at src/inter_run.c:300
#11 0x7fa6691ba81e in Parrot_runcode (interp=0x1f99080, argc=1,
argv=0x7fff71a107e0) at src/embed.c:951
#12 0x7fa66941bf38 in imcc_run_pbc (interp=0x1f99080, obj_file=0,
output_file=0x0, argc=1, argv=0x7fff71a107e0) at
compilers/imcc/main.c:791
#13 0x7fa66941c837 in imcc_run (interp=0x1f99080,
sourcefile=0x7fff71a11165 "t/op/bitwise_27.pir", argc=1,
argv=0x7fff71a107e0) at compilers/imcc/main.c:1079
#14 0x00400c64 in main (argc=1, argv=0x7fff71a107e0) at
src/main.c:61
(gdb) cont
Continuing.
Breakpoint 4, Parrot_CPointer_set_pointer (interp=0x1f99080,
pmc=0x20f3de8,
value=0x7fff71a10358) at ./src/pmc/cpointer.pmc:167
167 Parrot_CPointer_attributes * const data =
PARROT_CPOINTER(SELF);
(gdb) bt
#0 Parrot_CPointer_set_pointer (interp=0x1f99080, pmc=0x20f3de8,
value=0x7fff71a10358) at ./src/pmc/cpointer.pmc:167
#1 0x7fa6691e0189 in Parrot_build_sig_object_from_varargs (
interp=0x1f99080, sig=0x7fa66944bb33 "PPP->P", args=0x7fff71a10230)
at src/multidispatch.c:497
#2 0x7fa6691e05c6 in Parrot_mmd_multi_dispatch_from_c_args (
interp=0x1f99080, name=0x7fa66944c310 "modulus",
sig=0x7fa66944bb33 "PPP->P") at src/multidispatch.c:574
#3 0x7fa6692c159f in Parrot_default_modulus (interp=0x1f99080,
pmc=0x20f3f00, value=0x2072a08, dest=0x2071e70)
at ./src/pmc/default.pmc:1673
#4 0x7fa669172af8 in Parrot_mod_p_p_p (cur_opcode=0x20f36a0,
interp=0x1f99080) at src/ops/math.ops:760
#5 0x7fa669217c2f in runops_slow_core (interp=0x1f99080,
pc=0x20f36a0)
at src/runops_cores.c:222
#6 0x7fa6691d7ed4 in runops_int (interp=0x1f99080, offset=0)
at src/interpreter.c:937
#7 0x7fa6691d88c3 in runops (interp=0x1f99080, offs=0)
at src/inter_run.c:101
#8 0x7fa6691d8b7a in runops_args (interp=0x1f99080, sub=0x20738b0,
obj=0x2026020, meth_unused=0x0, sig=0x7fa669442cfb "vP",
ap=0x7fff71a10500)
at src/inter_run.c:236
#9 0x7fa6691d8d6b in Parrot_runops_fromc_args (interp=0x1f99080,
sub=0x20738b0, sig=0x7fa669442cfb "vP") at src/inter_run.c:300
#10 0x7fa6691ba81e in Parrot_runcode (interp=0x1f99080, argc=1,
argv=0x7fff71a107e0) at src/embed.c:951
#11 0x7fa66941bf38 in imcc_run_pbc (interp=0x1f99080, obj_file=0,
output_file=0x0, argc=1, argv=0x7fff71a107e0) at
compilers/imcc/main.c:791
#12 0x7fa66941c837 in imcc_run (interp=0x1f99080,
sourcefile=0x7fff71a11165 "t/op/bitwise_27.pir", argc=1,
argv=0x7fff71a107e0) at compilers/imcc/main.c:1079
#13 0x00400c64 in main (argc=1, argv=0x7fff71a107e0) at
src/main.c:61
(gdb) print *pmc
$3 = {cache = {_b = {_bufstart = 0x20f3db0, _buflen = 0}, _ptrs = {
_struct_val = 0x20f3db0, _pmc_val = 0x0}, _i = {_int_val =
34553264,
_int_val2 = 0}, _num_val = 1.7071580694083094e-316,
_string_val = 0x20f3db0}, flags = 72353280, vtable = 0x1ffbf30,
data = 0x2135c00, pmc_ext = 0x2125418, real_self = 0x20f3de8}
(gdb) print *((Parrot_CPointer_attributes *) 0x2135c00)
$4 = {pointer = 0x7fff71a10358, sig = 0x0}
> 2) What's
Re: [perl #59880] DOD crash in r31926, t/op/bitwise.t #27 on linux/x86_64
chromatic wrote:
> 2) What's setting an invalid pointer-to-a-PMC here?
This question is answered at the end of the following dump. (This is
one of the things I nopasted during our IRC discussion last week, thanks
for your guidance in producing it.)
One interesting question: the pointer-to-a-PMC is written a couple times
by the CPointer class, and then written by BigInt once. Was that expected?
(By the way, I've also reproduced this on one of the x86-32 gentoo boxes
I tried it on, so it is not x86-64 specific. It is also not specific to
one version of gcc.)
(gdb) break src/headers.c:324 if ((long)pmc & 0xfff) == 0xde8
No source file named src/headers.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (src/headers.c:324 if ((long)pmc & 0xfff) == 0xde8) pending.
(gdb) run t/op/bitwise_27.pir
Starting program: /work/parrot-dev/parrot-trunk/parrot t/op/bitwise_27.pir
[Thread debugging using libthread_db enabled]
warning: Lowest section in /usr/lib64/libicudata.so.38 is .hash at
0190
[New Thread 0x7f3245daf710 (LWP 1013)]
[Switching to Thread 0x7f3245daf710 (LWP 1013)]
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=1024)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=1024)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=5120)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=5120)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=0) at
src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=1024)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=1024)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=0) at
src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=1024)
at src/headers.c:324
324 if (!pmc)
(gdb) bt
#0 new_pmc_header (interp=0x13bd080, flags=1024) at src/headers.c:324
#1 0x7f3245753f78 in get_new_pmc_header (interp=0x13bd080,
base_type=52,
flags=1024) at src/pmc.c:267
#2 0x7f3245753bc3 in pmc_new (interp=0x13bd080, base_type=52)
at src/pmc.c:92
#3 0x7f324571ce74 in Parrot_build_sig_object_from_varargs (
interp=0x13bd080, sig=0x7f3245988b33 "PPP->P", args=0x7fff4df4d770)
at src/multidispatch.c:477
#4 0x7f324571d5c6 in Parrot_mmd_multi_dispatch_from_c_args (
interp=0x13bd080, name=0x7f3245989310 "modulus",
sig=0x7f3245988b33 "PPP->P") at src/multidispatch.c:574
#5 0x7f32457fe59f in Parrot_default_modulus (interp=0x13bd080,
pmc=0x1517f00, value=0x1496a08, dest=0x1495e70)
at ./src/pmc/default.pmc:1673
#6 0x7f32456afaf8 in Parrot_mod_p_p_p (cur_opcode=0x15176a0,
interp=0x13bd080) at src/ops/math.ops:760
#7 0x7f3245754c2f in runops_slow_core (interp=0x13bd080, pc=0x15176a0)
at src/runops_cores.c:222
#8 0x7f3245714ed4 in runops_int (interp=0x13bd080, offset=0)
at src/interpreter.c:937
#9 0x7f32457158c3 in runops (interp=0x13bd080, offs=0)
at src/inter_run.c:101
#10 0x7f3245715b7a in runops_args (interp=0x13bd080, sub=0x14978b0,
obj=0x144a020, meth_unused=0x0, sig=0x7f324597fcfb "vP",
ap=0x7fff4df4da40)
at src/inter_run.c:236
#11 0x7f3245715d6b in Parrot_runops_fromc_args (interp=0x13bd080,
sub=0x14978b0, sig=0x7f324597fcfb "vP") at src/inter_run.c:300
#12 0x7f32456f781e in Parrot_runcode (interp=0x13bd080, argc=1,
argv=0x7fff4df4dd20) at src/embed.c:951
#13 0x7f3245958f38 in imcc_run_pbc (interp=0x13bd080, obj_file=0,
output_file=0x0, argc=1, argv=0x7fff4df4dd20) at
compilers/imcc/main.c:791
#14 0x7f3245959837 in imcc_run (interp=0x13bd080,
sourcefile=0x7fff4df4e165 "t/op/bitwise_27.pir", argc=1,
argv=0x7fff4df4dd20) at compilers/imcc/main.c:1079
#15 0x00400c64 in main (argc=1, argv=0x7fff4df4dd20) at
src/main.c:61
(gdb) step
329 if (flags & PObj_is_PMC_EXT_FLAG) {
(gdb)
330 flags |= PObj_is_special_PMC_FLAG;
(gdb)
331 pmc->pmc_ext = new_pmc_ext(interp);
(gdb)
new_pmc_ext (interp=0x13bd080) at src/headers.c:363
363 Small_Object_Pool * const pool =
interp->arena_base->pmc_ext_pool;
(gdb)
366 return (PMC_EXT *)pool->get_free_object(interp, pool);
(gdb)
gc_ms_get_free_pmc_ext (interp=0x13bd080, pool=0x13be7e0)
at src/gc/smallobject.c:275
275 PMC_EXT *free_list = (PMC_EXT *)pool->free_list;
(gdb)
278 if (!free_list) {
(gdb)
283 ptr = free_list;
(gdb)
284 pool->free_list = ptr->_next_for_GC;
(gdb)
285 ptr->_next_for_
Re: [perl #60068] [BUG] t/pmc/packfile.t: set_integer_keyed_str test failing on Darwin PPC
[oops, forgot to copy the list.] If darwin has gdb, you can do the following to get a backtrace: $ gdb parrot gdb> run t/pmc/packfile_6.pir [segfault should occur here] gdb> bt Mark
Re: [perl #60642] [CAGE] add a codingstd test to ensure TODOed tests have an RT ticket number
James Keenan via RT wrote: On Tue Nov 18 10:22:25 2008, [EMAIL PROTECTED] wrote: This will probably be quite challenging. Let's assume that all tests are found in files with names ending in '.t'. Those .t files can be written in any language, which probably have different ways of classifying a test as TODO. My count tonight is that 1384 .t files in the distribution. Of these 524 are *not* found under ./languages/. I wonder if we could formulate the specification in this ticket a bit more precisely before someone embarks on coding. Yes, absolutely. I just added the basic ticket on the spur of the moment, to make sure I didn't forget about it. I've been thinking about this. A few things come to mind, for instance detecting the language based on the hashbang (if any) or subdirectory it's in, and invoking a language-specific parser. And detecting the cases we can't handle, and skipping those. But to me that sounds like way too much work. It doesn't really matter to me whether the ticket number occurs within the TODO output string, a nearby comment is good enough for me. So how about skipping all the above nonsense and just ignoring the test language entirely? How about a simple regex-based test that tallies all instances of /TODO/ in the set of test files, skipping the lines that start with obvious comment characters, and for each instance, looks for a match of /#\d+/? It can even expand the search to also look a couple lines above and below the TODO line, for additional flexibility. I think that should be reasonable for most, if not all, possible test languages. Do you think that would catch all the cases? It's a heck of a lot more feasable, it would work in every example I can think of (except maybe Befunge), and it seems flexible enough to deal with languages we haven't thought up yet. So I guess I'm seriously proposing this. Looking forward to your opinion, Mark
Re: [perl #60642] [CAGE] add a codingstd test to ensure TODOed tests have an RT ticket number
James Keenan via RT wrote: On Wed Nov 19 23:13:27 2008, [EMAIL PROTECTED] wrote: James Keenan via RT wrote: On Tue Nov 18 10:22:25 2008, [EMAIL PROTECTED] wrote: This will probably be quite challenging. Let's assume that all tests are found in files with names ending in '.t'. Those .t files can be written in any language, which probably have different ways of classifying a test as TODO. My count tonight is that 1384 .t files in the distribution. Of these 524 are *not* found under ./languages/. I wonder if we could formulate the specification in this ticket a bit more precisely before someone embarks on coding. Yes, absolutely. I just added the basic ticket on the spur of the moment, to make sure I didn't forget about it. I've been thinking about this. A few things come to mind, for instance detecting the language based on the hashbang (if any) or subdirectory it's in, and invoking a language-specific parser. And detecting the cases we can't handle, and skipping those. But to me that sounds like way too much work. It doesn't really matter to me whether the ticket number occurs within the TODO output string, a nearby comment is good enough for me. So how about skipping all the above nonsense and just ignoring the test language entirely? How about a simple regex-based test that tallies all instances of /TODO/ in the set of test files, skipping the lines that start with obvious comment characters, and for each instance, looks for a match of /#\d+/? It can even expand the search to also look a couple lines above and below the TODO line, for additional flexibility. I think that should be reasonable for most, if not all, possible test languages. Do you think that would catch all the cases? Two thoughts: 1. We already have code that can detect the existence of TODO in certain kinds of files. Cf. t/codingstd/fixme.t. Paul Cochrane used that a couple of years back to generate hundreds of RTs -- most of which are probably still outstanding. Can we leverage that Parrot::Distribution-based code? I'm sure we can. Though I'm not really sure why the test you mention is limited to only checking C sources. In fact, PDD07 says: If a bug must be fixed soon, use "XXX" and put a ticket in the bug tracking system. This means that each "XXX" should have an RT ticket number next to it. As such, we might just extend fixme.t to look for a nearby ticket number, and fail if it can't find one. And do this everywhere, not just C sources or tests. (PDD07 doesn't seem to be talking about code written in a particular language, here.) This sounds quite doable to me, and if it sounds reasonable to everyone else, I'll take a shot at it this evening just to see how badly it breaks. It does also raise the question of how to disambiguate between RT and trac tickets mentioned within the parrot sources. We could just use /#\d+/ for both, which makes the test happy, but then humans won't know where to go find the ticket. Mark
Re: [perl #59680] Build error: tools/build/ops2pm.pl: Could not mkdir /home/moritz/src/parrot/lib/Parrot/OpLib: File exists!
Will Coleda wrote: On Tue, Nov 25, 2008 at 2:18 PM, Mark Glines via RT <[EMAIL PROTECTED]> wrote: On Sat Oct 18 12:13:51 2008, [EMAIL PROTECTED] wrote: There's a race condition, if that directory doesn't exist and multiple processes execute that code simultaneously. Fortunately, Parrot::Ops2pm::print_module() creates that directly when it writes Parrot::OpLib::core -- the only file in that directory. Fixed in r32016. Hi, I'm still seeing this race occur, about once every hundred builds. r33196 contains a simple workaround (if mkpath failed, but the directory now exists, someone else created it, so silently continue). Mark Can we avoid this issue by just shipping an empty svn directory? That's one possibility, maybe with a ".keep" file or whatever to keep git happy. Another solution I considered is to make the ops rules in the Makefile depend on some "make-the-directory" rule, to keep the ordering straight. However, r33196 seemed like the simplest possible solution, and it won't have any effect at all when the race condition didn't occur (which seems like about 99% of the time), so that's the one I checked in. Feel free to revert it if a different solution is preferred. Mark
Re: fudging the headerizer
Andy Lester wrote: This patch http://www.parrotvm.org/svn/parrot/revision?rev=34423 is not a long-term solution. The headerizer has to get run at will. Infinoid, can you tell me more about those ifdefs so I can make the headerizer happy? Happy to. The functions in question (is_ins_save and _is_ins_save) are declared as static, but conditionally defined inside of an #ifdef. If the prototypes are not put in the same #ifdefs, the following warnings result: compilers/imcc/optimizer.c:87: warning: '_is_ins_save' declared 'static' but never defined compilers/imcc/optimizer.c:153: warning: 'is_ins_save' declared 'static' but never defined This has shown up a couple of times in RT, most recently as #53990. Mark
Re: [perl #62010] [PATCH] fix PARROT_EXPORT visibility=default for gcc other than 4.x
donald.hun...@gmail.com wrote:
I was pretty averse to adding an additional configure step myself. The
problem is that warnings.pm checks specifically for supported compiler
flags and I didn't want to include other things there. The bug is that
gcc.pm is hardcoded for version 4.x rather than checking. I didn't want
to add a duplicate check for -fvisibility=hidden in this file.
As I understand it, -fvisibility=hidden goes hand in hand with
__attribute__((visibility("default") so a single check covers both. If
you want to implement the fix as an explicit check for
__attribute__((visibility("default") in gcc.pm then that would work.
Perhaps the simplest thing to do is just move my check into warnings.pm
after all. My guess is that it's never right to use -fvisibility=hidden
without also using __attribute__ ... so if one is used then the other
needs to be as well. That seems to be the best argument for keeping them
in the same place.
Is there any version of gcc which accepts -fvisibility=hidden but not
__attribute__((visibility("default")))? If not, then I'm worrying about
nothing, and we can probably just use the existing check for both. But
I agree, neither of these features makes much sense without the other.
Mark
Re: [perl #62202] Problem with Configure.PL under Windows
Alan Rocker (via RT) wrote: auto::gmp - Does your platform support GMP...Can't spawn ".\test_616.exe": Bad file descriptor at lib/Parrot/Configure/Utils.pm line 86. Thanks, this is a known issue with the libgmp.dll built with strawberry perl. (It was built with SSE2 instructions that aren't supported by several classes of x86 processor, including my AMD Athlon XP.) I bugged Alias about this a couple of times and even built and sent him a known good library to replace it with, but the issue is still present in strawberry perl. Merging #62202 into #50212. Mark
Re: [perl #63626] Re: bouncing parrot...@parrotcode.org
Geoffrey Broadwell wrote: > Out of curiosity, why don't we allow emails to create tickets in Trac? There's a plugin to do this, called "email2trac". It's being set up, but doesn't work yet. See TT #49. Mark
Re: [perl #50212] Configure step fails on Windows
Hi, Alan! What kind of CPU do you have? If you have an AMD Athlon XP
(or something of similar lineage), I think I know what the problem is.
On Thu, 24 Jan 2008 12:52:35 -0800
Alan Rocker (via RT) <[EMAIL PROTECTED]> wrote:
> Determining if your platform supports GMP...Can't spawn ".\test.exe":
> Bad file descriptor at lib/Parrot/Configure/Utils.pm line 85.
> no.
>
> (Windows wanted to 'phone home about test.exe too.)
Yeah, I get that on Strawberry Perl too. It surprised me, and it
pauses the configure process until you click "Don't send report".
> Might there be some obscure connection with
> [perl #41508] [BUG] Configure losing flags... ?
Nah, I think the test app just broke for whatever reason. The mingw32
environment packaged with Strawberry Perl does include a libgmp.a and
libgmp.la, so the test app was built properly, but failed to run.
I reproduced it by copying config/auto/gmp/gmp.in to gmp.c, and
compiling with:
> gcc -O2 -Wall -g -ggdb -o gmp.exe gmp.c -lgmp
The resulting gmp.exe crashes and Windows prompts if I want to send an
error report to microsoft.com.
I poked around a bit with gdb, and discovered its barfing on an SSE2
instruction ("pmuludq") in libgmp.a (at __gmpn_divrem_1+266), which my
CPU (an athlon XP) can't handle. So I'm going to ask the Strawberry
Perl guy about this.
For the record, here's what GDB says:
Program received signal SIGILL, Illegal instruction.
0x00405aaa in __gmpn_divrem_1 ()
(gdb) bt
#0 0x00405aaa in __gmpn_divrem_1 ()
#1 0x00401ae8 in mpn_sb_get_str ()
#2 0x0001 in ?? ()
#3 0x003d2680 in ?? ()
#4 0x0022fc1b in ?? ()
#5 0x0011 in ?? ()
#6 0x12e0be82 in ?? ()
#7 0x0002 in ?? ()
#8 0x003d in ?? ()
#9 0x4161 in ?? ()
#10 0x7c91056d in ntdll!RtlFreeThreadActivationContextStack ()
from C:\WINDOWS\system32\ntdll.dll
#11 0x in ?? ()
And the relevant disassembly:
0x00405aa4 <__gmpn_divrem_1+260>: paddd %mm0,%mm2
0x00405aa7 <__gmpn_divrem_1+263>: punpckldq %mm0,%mm1
0x00405aaa <__gmpn_divrem_1+266>: pmuludq %mm4,%mm2
0x00405aad <__gmpn_divrem_1+269>: paddq %mm2,%mm1
0x00405ab0 <__gmpn_divrem_1+272>: pxor %mm2,%mm2
Mark
Re: minimal Parrot for small (embedded) system
On Tue, 11 Mar 2008 20:02:25 + "Wim Vanderbauwhede" <[EMAIL PROTECTED]> wrote: > I've read "Parrot for small platforms" in pdd01_overview, it says > "For small platforms, any parser, compiler, and optimizer modules are > replaced with a small bytecode loader module which reads in Parrot > bytecode and passes it to the interpreter for execution." > I guess that's what I need; but I have no idea how to compile parrot > this way. Any pointers would be much appreciated. Hi Wim, I don't think that feature is implemented yet. I don't see any Configure.pl options for this mode of operation, and the PDD says its not a requirement of the 1.0 release. So I'm afraid the answer is not yet, sorry. Mark
Re: [perl #51718] Consolidate test infrastructure in t/codingstd and t/distro
On Fri, 14 Mar 2008 16:19:48 -0700 "James Keenan via RT" <[EMAIL PROTECTED]> wrote: > Mark: > > This looks good to me. However, one of the tests being revised is > currently failing, probably for different reasons. See: > http://rt.perl.org/rt3/Ticket/Display.html?id=51750. Thanks for the code review! Yep, that's a preexisting failure. The recent changes to that file are the reason I started looking at the codingstd tests to begin with. On Wednesday morning, it was failing 3 of the codingstd tests, one of which (trailing_spaces.t) didn't even give line numbers. > I recommend holding off applying it to trunk until after that bug is > resolved -- which I suspect means holding off until after this coming > Tuesday's release as well. I'm going to hold off until after Tuesday's release, in any case, just to make sure I don't break anything else. Mark
Re: [perl #51718] Consolidate test infrastructure in t/codingstd and t/distro
On Fri, 14 Mar 2008 17:01:39 -0700 Mark Glines <[EMAIL PROTECTED]> wrote: > I'm going to hold off until after Tuesday's release, in any case, just > to make sure I don't break anything else. I committed my previous patch (after some merging) as r26480. But I think this ticket should stay open, as there are still more codingstd tests to convert, and I haven't even looked at t/distro yet. Mark
Re: [perl #51916] Error in tests after build
On Fri, 21 Mar 2008 07:16:07 -0400 James E Keenan <[EMAIL PROTECTED]> wrote: > Ted Neward wrote: > > BTW, I didn't want to file a bug, but the Lua compiler in the > > latest bits uses a tool "yapp" that doesn't appear to be a part of > > the bundle--is it supposed to be? > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > > I don't think so ... but can our Lua experts respond to this? I am not a Lua expert, but that sounds an awful lot like Lua has a build-dependency on Parse::Yapp from CPAN. Mark
Re: [perl #51976] [PATCH] fixed uninitialized variable warning in dynext.c:Parrot_init_lib()
On Fri, 21 Mar 2008 08:21:44 -0700 "Andrew Whitworth" (via RT) <[EMAIL PROTECTED]> wrote: > # New Ticket Created by "Andrew Whitworth" > # Please include the string: [perl #51976] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=51976 > > > > I'm fixing a compile error that's generated (at least) on Win32 using > cl.exe. In dynext.c, the function Parrot_init_lib(), the variable > lib_pmc is, possibly, left undefined before it is used in a > conditional statement. I assume, from looking at the context of the > code, that the variable should be initialized to NULL > > included is a simple patch that corrects this issue, and should > suppress one compile-time warning. Thanks, applied in r26510. Mark
Re: [perl #51980] [PATCH] fixed multiple redefines of snprintf macro
On Fri, 21 Mar 2008 09:03:08 -0700 "Andrew Whitworth" (via RT) <[EMAIL PROTECTED]> wrote: > # New Ticket Created by "Andrew Whitworth" > # Please include the string: [perl #51980] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=51980 > > > > the snprintf macro was defined in Parrot/misc.h and src/spf_render.c. > I moved both definitions into the misc.h file and used conditionals to > determine which one to activate. The current definition goes like > this: > > 1) if the _MSC_VER macro is defined, use _snprintf > 2) if the PARROT_HAS_C99_SNPRINTF macro is not defined, use > Parrot_secret_snprintf instead > 3) otherwise, don't define the snprintf macro at all. > > In Parrot/has_header.h (which is, I know, automatically generated), > there is a definition on my system for PARROT_HAS_SNPRINTF, but not a > definition for PARROT_HAS_C99_SNPRINTF. I assume, on first glance that > these two macros are one in the same and should be united. I'm not so sure of this - my Linux box, for instance, has both defined. On first glance, it sounds like your system has an snprintf(), but Configure.pl has decided your snprintf() is not C99-compatible. Mark
Re: [perl #51982] [PATCH] fixed signed/unsigned typecast in string_primitives.c
On Fri, 21 Mar 2008 09:06:59 -0700
"Andrew Whitworth" (via RT) <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by "Andrew Whitworth"
> # Please include the string: [perl #51982]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=51982 >
>
>
> src/string_primitives.c:Parrot_char_digit_value was producing a
> compile-time warning because the function is supposed to be returning
> a UINTVAL, and is returning -1 on error. I applied a simple typecast
> to make this warning go away.
As discussed on IRC, I think the correct fix for this is to change the
return type of Parrot_char_digit_value(). This function will return 0
through 9 given a character in ('0'..'9'), and will return -1
otherwise. The unsignedness of the return type is just silly.
Mark
Re: [perl #51984] [PATCH] fixed "const int" to "unsigned char" conversion warnings
On Fri, 21 Mar 2008 09:26:42 -0700 "Andrew Whitworth" (via RT) <[EMAIL PROTECTED]> wrote: > # New Ticket Created by "Andrew Whitworth" > # Please include the string: [perl #51984] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=51984 > > > > The file src/utils.c was producing a number of compile-time warnings > involving possible loss of data in conversions from const int to > unsigned char. This stemmed from the macro "move_reg", which passed > integer values to a function of type "reg_move_func", which takes only > unsigned char parameters. To remove the warnings, I added explicit > typecasts to unsigned char for the parameters. Thanks, applied (with minor modifications) as r26511. Mark
Re: [perl #51982] [PATCH] fixed signed/unsigned typecast in string_primitives.c
On Fri, 21 Mar 2008 13:19:09 -0400 "Andrew Whitworth" <[EMAIL PROTECTED]> wrote: > Okay, i changed the function declaration in src/string_primitives.c > and include/Parrot/string_primitives.h. After a search, I couldn't > find any other files where the function Parrot_char_digit_value was > used, so I don't think anything else needed to be changed. Thanks, applied in r26512. Mark
Re: [perl #51988] [PATCH] file descriptor duplication updates
On Fri, 21 Mar 2008 11:15:51 -0700 "Andrew Whitworth" (via RT) <[EMAIL PROTECTED]> wrote: > # New Ticket Created by "Andrew Whitworth" > # Please include the string: [perl #51988] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=51988 > > > > A number of small updates to file descriptor duplication functions: > > 1) Calling _dup() instead of the deprecated dup() in src/io/io.c, and > src/io/io_unix.c > 2) Created macro PIO_DUP_FD(x) to handle duplication and typecasting > (may be overkill) > 3) Used PIO_DUP_FD(x) in src/io/io.c to help alleviate warnings > 4) Added a typecast from an integer to a PIOHANDLE to help alleviate a > warning about a comparison. > > These fixes should quiet a number of compile warnings, and shouldn't > affect the operation of the code at all. The new macro may be overkill > since It's only used in one place, but I'm assuming that it might be > useful elsewhere. If not, we can easily remove it and substitute the > guts of it into the body of the function. Your patch does not build for me on Linux, sorry. "_dup" is not a valid symbol on my architecture, so your patch causes compiler warnings and a linker error. Mark
Re: [perl #52224] Parrot::Test calls parrot with a bogus optimization values when run in /opt
On Sat, 29 Mar 2008 07:03:17 -0700
"James Keenan via RT" <[EMAIL PROTECTED]> wrote:
> If we simply add a forward slash after 'opt', does that solve the
> problem? (see attached)
Should this code really be checking the absolute pathname? We don't
have any control over where a user places a parrot checkout, and
honestly, I think we should be ignoring that as much as possible. I
think a safer solution is to chuck the filename through basename()
before doing the match.
This changes Parrot::Test's behavior: an alternate "-O" option will only
be used if the *filename* contains "optN", not if a leading directory
name contains it. I don't see any uses of "optN" in directory names
in the parrot tree, so I think it's ok. And it fixes the bug for me.
See attached.
Mark
Index: lib/Parrot/Test.pm
===
--- lib/Parrot/Test.pm (revision 26625)
+++ lib/Parrot/Test.pm (working copy)
@@ -263,6 +263,7 @@
use Cwd;
use File::Spec;
+use File::Basename;
use Memoize ();
use Parrot::Config;
@@ -766,11 +767,12 @@
# Name of the file with test code.
my $code_f = File::Spec->rel2abs( per_test( '.pir', $test_no ) );
+my $code_basef = basename($code_f);
# output file
my $out_f = per_test( '.pasm', $test_no );
-my $opt = $code_f =~ m!opt(.)! ? "-O$1" : "-O1";
+my $opt = $code_basef =~ m!opt(.)! ? "-O$1" : "-O1";
my $args = $ENV{TEST_PROG_ARGS} || '';
$args .= " $opt --output=$out_f";
$args =~ s/--run-exec//;
Re: [perl #52224] Parrot::Test calls parrot with a bogus optimization values when run in /opt
On Sat, 29 Mar 2008 11:59:25 -0700
Mark Glines <[EMAIL PROTECTED]> wrote:
> This changes Parrot::Test's behavior: an alternate "-O" option will
> only be used if the *filename* contains "optN", not if a leading
> directory name contains it. I don't see any uses of "optN" in
> directory names in the parrot tree, so I think it's ok. And it fixes
> the bug for me. See attached.
Found a second place in Parrot::Test which was doing the same thing,
causing a failure in t/pmc/sub.t. Fixed in the same way, new diff
is attached. Now everything in "make test" passes for me.
Mark
Index: lib/Parrot/Test.pm
===
--- lib/Parrot/Test.pm (revision 26625)
+++ lib/Parrot/Test.pm (working copy)
@@ -263,6 +263,7 @@
use Cwd;
use File::Spec;
+use File::Basename;
use Memoize ();
use Parrot::Config;
@@ -575,6 +576,7 @@
die "Unknown test function: $func";
}
$code_f = File::Spec->rel2abs($code_f);
+my $code_basef = basename($code_f);
# native tests are just run, others need to write code first
if ( $code_f !~ /\.pbc$/ ) {
@@ -583,7 +585,7 @@
# honor opt* filename to actually run code with -Ox
my $args = $ENV{TEST_PROG_ARGS} || '';
-my $opt = $code_f =~ m!opt(.)! ? "-O$1" : "";
+my $opt = $code_basef =~ m!opt(.)! ? "-O$1" : "";
$args .= " $opt";
my $run_exec = 0;
@@ -766,11 +768,12 @@
# Name of the file with test code.
my $code_f = File::Spec->rel2abs( per_test( '.pir', $test_no ) );
+my $code_basef = basename($code_f);
# output file
my $out_f = per_test( '.pasm', $test_no );
-my $opt = $code_f =~ m!opt(.)! ? "-O$1" : "-O1";
+my $opt = $code_basef =~ m!opt(.)! ? "-O$1" : "-O1";
my $args = $ENV{TEST_PROG_ARGS} || '';
$args .= " $opt --output=$out_f";
$args =~ s/--run-exec//;
Re: [perl #51464] [TODO] [PDD] add date stamps to PDD's
On Thu, 03 Apr 2008 12:18:47 -0700 "James Keenan via RT" <[EMAIL PROTECTED]> wrote: > Datestamps in the filename (e.g., MMDD)? Or somewhere inside the > file? > > Wouldn't the former create repository problems? Couldn't the latter be done automatically with an $Id$ tag? Mark
Re: [perl #43102] t/pmc/threads.t tests 5,7 fail with --gc=libc
On Thu, 03 Apr 2008 13:40:20 -0700 "Bernhard Schmalhofer via RT" <[EMAIL PROTECTED]> wrote: > On Fr. 01. Jun. 2007, 08:42:43, [EMAIL PROTECTED] wrote: > > While testing/trying to fix RT #42938, I noticed an additional test > > failure in t/pmc/threads.t. Test 7 crashes with a signal 11 > > (segmentation fault), on my Gentoo Linux-x86 box. This is with svn > > r18722. > > Hi Mark, > > is this still an issue? Test 7 still crashes with a signal 11, yes. Tested with r26715 built with --gc=libc on a Linux-amd64 box. Mark
Re: [perl #52462] [PATCH] [UGLY] FixedIntegerArray->new_from_string() needs cleanup
On Fri, 4 Apr 2008 12:50:27 -0500 "Patrick R. Michaud" <[EMAIL PROTECTED]> wrote: > On Fri, Apr 04, 2008 at 10:06:39AM -0700, chromatic wrote: > > On Thursday 03 April 2008 15:47:12 Mark Glines wrote: > > > > > When doing a test for --gc=libc, I noticed test 10 of > > > t/op/calling.t was hanging. The test creates a FixedIntegerArray > > > from the string "0, 0x20, 0x20, 0". The new_from_string() > > > constructor relies on STRING* buffers containing a trailing NULL > > > (which isn't counted in the "strlen" tally). The existence of > > > that NULL is not a valid assumption in the gc=libc case. > > > [...] > > > I've attached a fix. It isn't very pretty, and it probably > > > really hurts performance. But it fixes the hang, and allows the > > > test script to complete successfully. I am submitting it to RT > > > in the hopes that someone with better knowledge of parrot > > > internals can come up with a Better Way (tm). > > > > Using CONST_STRING to build the null STRING will hurt performance > > less, but the right solution is to excise all traces of > > new_from_string() throughout the system, and then completely forget > > it ever existed. > > Correct. Perhaps this ticket should be merged with RT#47011 , > which talks about new_from_string() being deprecated? (Or at least > link to that ticket.) If it's going to stay around, it should be fixed. But removing it entirely works for me too. Mark
