Re: Perl 6 for system-wide use: best practice?
Hi Tom, On Mon, Feb 22, 2016 at 01:50:50PM -0600, Tom Browder wrote: > What is recommended for installing Perl 6 for system-wide use? if you are running a Debian-based system, you could try installing the Debian Rakudo package from either the "stretch (testing)" or "sid (unstable)" suite. It is currently at Rakudo version 2015.11 however work is in progress to get more recent Rakudo releases packaged. Hope that helps a bit. Cheers, Paul
Re: How to do a substring replacement in Perl 6
Hi all! From http://perldoc.perl.org/functions/substr.html: substr has a 4th argument (or you can use substr as an lvalue) for replacement. substr EXPR,OFFSET,LENGTH,REPLACEMENT From http://doc.perl6.org/routine/substr I don't see any way to do a replacement. What is the idiomatic way of doing a positional string replacement in Perl 6? Thanks! Method form: $ perl6 -e 'my $s = abc; $s.substr-rw(1,1) = z; say $s;' azc Function form: $ perl6 -e 'my $s = abc; substr-rw($s, 1,1) = z; say $s;' azc I also do not see substr-rw in doc.perl6.org. It needs to be added. In the meantime, you can find it here: http://design.perl6.org/S32/Str.html thanks, Bruce, for the examples! I've added these to the doc.perl6.org documentation. The entry for substr-rw should appear in roughly half an hour. Cheers, Paul
Re: How to do a substring replacement in Perl 6
Hi Douglas, From http://perldoc.perl.org/functions/substr.html: substr has a 4th argument (or you can use substr as an lvalue) for replacement. substr EXPR,OFFSET,LENGTH,REPLACEMENT From http://doc.perl6.org/routine/substr I don't see any way to do a replacement. What is the idiomatic way of doing a positional string replacement in Perl 6? Thanks! I believe `substr-rw` is what you're looking for: $ perl6 my $s = The black cat climbed the green tree; The black cat climbed the green tree my $z = substr-rw($s, 14, 7) = jumped from; jumped $s.say The black cat jumped from the green tree As far as I know, not all of its behaviour has been implemented yet (FWIW it looks like it shouldn't have returned jumped above; my guess is that it should have been climbed. Nevertheless, it seems to do that which you're looking for. Hope that helps! Cheers, Paul
Re: Perl 5's $0 vs. Perl 6's $*EXECUTABLE_NAME
On 30 May 2015 3:00:25 pm GMT+02:00, Tom Browder tom.brow...@gmail.com wrote: I finally found the Perl 6 version of Perl 5's $0 listed in: tablets.perl6.org/appendix-b-grouped.html#special-variables as '$*EXECUTABLE_NAME', and I expected it to act the same as $0 in Perl 6, but I have two problems with it: 1. When used it yields 'perl6' regardless of the script's name (a bug?). $ cat t.pl #!/usr/bin/env perl6 say $*EXECUTABLE_NAME; $ chmod +x t.pl $ ./t.pl perl6 2. It seems very ungainly to go from two characters to 17. Couldn't it be shortened a bit, say, '$*0' or '$*EXE_NAME' or '$*PROG' or something else? Am I doing something wrong or do I have the wrong expectations? $ perl6 --version This is perl6 version 2015.03-48-g9746e88 built on MoarVM version 2015.03 Best regards, -Tom Hi Tom, I believe what you are looking for is called $*PROGRAM_NAME. See also http://doc.perl6.org/language/variables#Special_Variables Cheers, Paul
Re: Perl 5's $0 vs. Perl 6's $*EXECUTABLE_NAME
Hi Tom, On Sat, May 30, 2015 at 09:03:17AM -0500, Tom Browder wrote: On Sat, May 30, 2015 at 8:30 AM, Tobias Leich em...@froggs.de wrote: Please also take a look at $*EXECUTABLE, $*PROGRAM and $*PROGRAM_NAME. Tobias, I didn't find $*PROGRAM in the doc listed by Paul: http://doc.perl6.org/language/variables#Special_Variables Also, the following were not in: http://tablets.perl6.org/appendix-a-index.html that I could find. $*EXECUTABLE_NAME $*PROGRAM $*PROGRAM_NAME the docs at tablets.perl6.org aren't as up to date as those on doc.perl6.org. The doc.perl6.org docs are currently the reference work for Perl6, however please note that they are very much a work in progress. From a Perl 6 newbie standpoint, it looks like there are too many docs with overlapping purposes referenced on perl.org and which, confusingly, have different pieces missing. Except for the Synopses, I'm not sure what document to go to for the definitive answer. And, as usual, I have no suggestions for an easy fix. This I can understand. We're doing our best to provide current and accurate documentation. Perl6 is a very large language, and thus gaps in the documentation are to be expected; especially considering the volunteer based nature of the project. Thanks for pointing out the $*PROGRAM omission! I've just added it to the list of special variables and it should be available online within the next 10-15 minutes. Kind regards, Paul
Re: Is there an equivalent env var to PERL5LIB for Perl 6 module locations?
On Tue, Mar 31, 2015 at 05:40:44AM -0500, Tom Browder wrote: On Mon, Mar 30, 2015 at 7:35 PM, Rob Hoelz r...@hoelz.ro wrote: Yup, PERL6LIB. =) And how did you find out about it, i.e., where is it documented? http://doc.perl6.org/language/5to6#Environment_variables to be honest I cheated and have written the docs just today. :-) A `git grep LIB` in the spec sources turned up the text on environment variables in S19, so that'd be one place to check as well. In general, if a search like that doesn't seem to turn up much, a `git grep` in the Rakudo sources also turns up quite a bit of info. Cheers, Paul
Re: Example module and its use
Hi Tom,
use Bar :DEFAULT;
but this does not:
use Bar foo;
So is S11 in error!!
That might not necessarily be the case (however S11 certainly isn't clear
about exactly how to import selected routines while `use`-ing a module).
All subs/methods that are marked with `is export` are exported by default,
thus there's actually no need to import anything, hence:
use Bar;
will ensure that the foo() routine is available within the scope of the
`doit.pl` script.
From what I can gather from S11, is that if one wants to override the
default behaviour of importing into the current namespace everything which
is exported by the module, then an EXPORT sub needs to be defined. AFAICT
this is what the error:
no EXPORT sub, but you provided positional argument in the 'use' statement
is trying to tell you.
Nevertheless, I've not been able to work out how to create an EXPORT sub
which does the Right Thing(TM). Reading 'Perl6/Grammar.nqp' in the Rakudo
sources shows that a sub by the name of `EXPORT` is expected which returns
an `EnumMap`, which I suspect contains the names of the subs/methods to be
exported. I'm fairly sure this is getting much too low-level for the
current use-case. Also, sharing this information might simply be muddying
the waters somewhat, so in order that you can get further with what you're
trying to do, your example will work with the following code:
== Bar.pm ==
module Bar;
use v6;
sub foo($a, $b, $c) is export {}
# vim: expandtab shiftwidth=4 ft=perl6
= doit.pl ==
use v6;
use lib .;
use Bar;
my @t = foo(1, 2, 3);
# vim: expandtab shiftwidth=4 ft=perl6
BTW: please don't use the shortcut 'v6;': AFAIU it's been deprecated in
favour of 'use v6;'
Hope this helps a bit.
Cheers,
Paul
Re: Trig Functions to-radians and from-radians
Hi Tom, On Tue, Mar 17, 2015 at 12:52:42PM -0500, Tom Browder wrote: Those two functions are documented here: http://design.perl6.org/S32/Numeric.html#Trigonometric_functions but I have tried to use them with no luck: say 10.to-radians(Degrees); Undeclared name: Degrees used at line 9 So how does one use the two functions? it seems that to-radians() is specified, but not yet implemented in Rakudo (see, for example line 71 in https://github.com/perl6/roast/blob/master/S32-num/cool-num.t; the test is skipped for Rakudo). BTW: doc.perl6.org is a good resource for documentation of the currently implemented parts of the spec. The written spec has also come to mean speculation rather than specification. The specification is basically the roast test suite at present. Hope that helps, Paul
Re: [perl #47289] [PATCH] Move executable code out of jit/i386/exec_dep.h
On 01/04/2008, Mark Glines via RT [EMAIL PROTECTED] wrote: On Sat Mar 29 15:54:09 2008, [EMAIL PROTECTED] wrote: I ran a fulltest with this patch applied, and everything's fine on x86 (where it matters). Hi, The root.in portion of this patch breaks non-i386, JIT capable platforms. Problem is, the patch created an exec_dep.c for i386, but added a Makefile dependency for $(SRC_DIR)/exec_dep.c on *ALL* platforms, and that file doesn't exist anywhere except for x86. So, tetragon is now reporting on IRC that builds fail on ppc. Sounds like reverting r26636 will result in a successful build... testing that now. IIRC there's a special flag one can set inside Makefile.pm (I think... :-/ ) which will allow this dependency to only be added for x86 platforms. My guess is that this would be the appropriate way to get this patch working on all platforms. Paul
Re: [perl #43753] [TODO] $language should be the name of the test Module
Hallo Bernhard, On 06/04/2008, Bernhard Schmalhofer via RT [EMAIL PROTECTED] wrote: On Di. 10. Jul. 2007, 07:15:27, ptc wrote: In the file lib/Parrot/Test.pm there is the todo item: # TODO: $language should be the name of the test Module # that would open the door for Scheme::Test This needs to be implemented. I think that no action needs to be taken on that, so I removed that idle comment. That means we can close this ticket or? Paul
Re: [perl #46927] [PATCH] Remove integer - pointer comparison in slice.pmc
Jim, Given Joshua's comments, should we still be considering this patch? My guess is no. The compiler warning is probably gone by now anyway. Paul
Re: [perl #43414] [PATCH] jit_emit.h changes for various platforms
On 16/03/2008, James Keenan via RT [EMAIL PROTECTED] wrote: On Thu Jun 28 10:26:30 2007, ptc wrote: Hi, as part of my cleaning up the usage of 'INTERP', 'Interp' and 'interpreter' to consistently use 'interp', as well as changing internal_exception()s to real_exceptions(), here are some patches affecting platforms I (unfortunately) don't have access to, so I can't test them (platforms are: hppa, ia64, ppc and arm). Could someone please apply these and test them for me? Thanks heaps in advance! Paul Paul, Since last June some of the files you were proposing to patch have changed considerably. I think the revisions proposed in src/jit/ppc/jit_emit.h have been implemented in the course of other revisions. But it looks like src/jit/arm/jit_emit.h might still benefit from your patch. Could you review these patches? Thank you very much. Unfortunately, I really don't have the tuits to do much more than lurk these days. I also don't have access to a computer with the arm architecture, so I don't know if there's much more I can do as far as the patch is concerned (it'd be nice to test it to see if it worked for instance). I wish I could be of more help :-/ Paul
Re: [perl #46223] [PATCH] Remove dead code in src/pmc/pair.pmc (Coverity CID 5)
On 16/03/2008, James Keenan via RT [EMAIL PROTECTED] wrote: Paul, I see that you touched src/pmc/pair.pmc after your last post in this thread. r22490 | paultcochrane | 2007-10-25 16:10:19 -0400 (Thu, 25 Oct 2007) | 2 lines [pmc] Removing dead code which was picked up in Coverity CID 5 Given that, should we still be considering this patch? If not, can we close the ticket? Given the contents of the commit log message, I'd say we can close this ticket. Paul
Re: [perl #47247] [PATCH] Move executable code out of gcc_pcc header
On 16/03/2008, James Keenan via RT [EMAIL PROTECTED] wrote: On Thu Nov 08 08:25:28 2007, ptc wrote: James, Thanks for the report! I forgot to add parrot.h to the list of includes. Could you add: #include parrot/parrot.h just before the other include statement in gcc_pcc.c and see if things make (after realclean) nicely for you? Paul, I guess I had difficulty editing and applying this patch. Hence, my non-response for several months. Would it be possible for you to post a clean version of the patch? I will then try it out on Darwin? (But I'll ask others to try it as well, as we've been getting 10.4 vs 10.5 problems and ppc vs intel problems.) It would probably be optimal if you tried out the patch (with the #include parrot/parrot.h addition) as I don't have access to a ppc machine to test that the patch works. I would guess that that section of code hasn't changed much since I posted the patch so it should still apply cleanly. Paul
Re: [perl #47289] [PATCH] Move executable code out of jit/i386/exec_dep.h
On 16/03/2008, James Keenan via RT [EMAIL PROTECTED] wrote: Joshua, Paul: Can you give us an update on the status of patch still? As far as I remember, it still needs to be tested on the various runcores. Paul
Re: [svn:parrot] r26013 - trunk/src
I just checked the properties in the repository for this file before and after your commit, and they seem identical. Yeah, that happened to me too but in my svn checkout. In the svk checkout things seemed as though things weren't correct, so I committed the changes. If the test is failing on your svk instance and not your svn instance, I would tend to suspect that your svk repo is out of whack. This used to happen to Chip and I on a regular basis. (I was never able to resolve my svk issues to my satisfaction; I switched back to svn.) I switched back to svn after problems early on in my parrot involvement, however, I thought I'd give svk 2.02 a go, but it seems to have issues. It's also doing some funny things like making checkins it's already done from the last 'svk up -sm'. *sigh* I guess I'd best go back to svn then... Thanks for keeping a watchful eye on things :-) Paul
[perl #50938] [PATCH] Remove instantiate opcode
Patch applied in r25869. Closing ticket.
[perl #50066] [BUG] $LIBPARROT_STATIC macro not expanded properly when building pbc_to_exe
Andy's patch applied in r25763. This corrects the issue. Closing the ticket.
[perl #48142] [DEPRECATED] class_type vtable
Patch applied in r25765. Closing ticket.
[perl #42375] [DEPRECATED] pmcinfo op
Applied a modified version of the patch in r25767. Closing ticket.
Re: [perl #50622] nmake test bug?
On 07/02/2008, Ron Blaschke [EMAIL PROTECTED] wrote: jerry gay wrote: On Feb 7, 2008 5:38 AM, via RT Ted Neward [EMAIL PROTECTED] wrote: t/library/pg. Interestingly, a parrot.exe process is left running, even after Ctrl-C'ing the console window in which the tests are running. Could very well be a configuration problem, would love to know how to correct it if it is. it seems that parrot thinks you have postgres libraries installed. do you? you don't need them to run parrot (i don't have them installed on my windows system.) so, you can work around the problem by taking those libs out of your path, so parrot's configure won't find them. of course, that won't fix the problem, it just works around it. i (or someone else, please!) will have to install postgres libs in an environment and configure/build/test parrot to reproduce this behavior. this may take some time. if you intend to work with parrot and postgres specifically, where this integration would be important, let us know so we can bump up the priority. ~jerry This is with r25584, WinXP, VC9, PostgreSQL 8.3. Without PostgreSQL, eveythings skipped, as expected. $ parrot t/library/pg.t 1..43 ok 1 #skip skipped ok 2 #skip skipped ... ok 42 #skip skipped ok 43 #skip skipped With PostgreSQL (that is, adding ...\PostgreSQL\8.3\bin to PATH): $ parrot t/library/pg.t 1..43 ok 1 - load_bytecode ok 2 - load_bytecode Pg ok 3 - Pg class exists Method 'connectdb' not found for invocant of class 'Pg' current instr.: 'main' pc 67 (t/library/pg.t:48) Hrm, this is something I saw on FreeBSD. However, on that platform it actually fails the test rather than hanging... Paul
Re: [perl #50518] Is the rpms target dead?
On 03/02/2008, via RT Bob Rogers [EMAIL PROTECTED] wrote: # New Ticket Created by Bob Rogers # Please include the string: [perl #50518] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=50518 I notice that config/gen/makefiles/root.in has the following target: rpms : release sudo cp parrot-$(VERSION).tar.gz /usr/src/*/SOURCES sudo cp parrot.spec /usr/src/*/SPECS cd /usr/src/*/SPECS @make_and@ sudo rpm -ba parrot.spec This can never work on my openSUSE 10.2 system because (a) openSUSE always installs at least one other /usr/src/*/ directory with the kernel, and (2) rpm hasn't accepted the -ba option for a long time now (before 9.0, at least four years). Anyone mind if I chuck it? What about updating it so it works? We already have a .deb-related target and it'd be a good idea to have the rpm-based distros also able to install Parrot nicely. Is it worth our while getting Parrot added to Fedora/OpenSuse in addition to Debian? Just my 0.02 Euro... Paul
Re: [perl #50056] [BUG] Undefined symbols on OS X
On 28/01/2008, James Keenan via RT [EMAIL PROTECTED] wrote: On Sun Jan 27 17:14:11 2008, tiro wrote: Could you try setting MACOSX_DEPLOYMENT_TARGET to 10.4 to see if that fixes the problem? Okay, I figured out how to do that ... but no better results. [parrot] 566 $ MACOSX_DEPLOYMENT_TARGET=10.4 [parrot] 567 $ echo $MACOSX_DEPLOYMENT_TARGET 10.4 You also need to export the variable. Assuming you have bash or zsh, try: $ export MACOSX_DEPLOYMENT_TARGET=10.4 HTH, Paul
Re: [perl #50056] [BUG] Undefined symbols on OS X
On 23/01/2008, Allison Randal via RT [EMAIL PROTECTED] wrote:
On Tue Jan 22 15:38:11 2008, [EMAIL PROTECTED] wrote:
Are you building a static or a shared binary? Did this problem only
show up after Coke switched the default to shared?
Shared. I don't know the exact timing of the change in relation to the
failure starting. But, changing config/init/hints/darwin.pm back to
static by default, with a 'realclean' recompile doesn't work either.
Still get Undefined symbols errors:
c++ -o pbc_to_exe pbc_to_exe.o -L/usr/local/lib -L/opt/local/lib
-L/sw/lib -L/sw/lib -L/opt/local/lib -L/sw/lib $(LIBPARROT_STATIC) -lm
-lgmp -lreadline /Users/allison/projects/svn/parrot/src/parrot_config.o
sh: line 1: LIBPARROT_STATIC: command not found
/usr/bin/ld: Undefined symbols:
_PackFile_fixup_subs
[...]
collect2: ld returned 1 exit status
linking failed
current instr.: 'link_file' pc 752 (pbc_to_exe.pir:365)
called from Sub 'main' pc 124 (pbc_to_exe.pir:32)
It does work if I manually substitute blib/lib/libparrot.a for
LIBPARROT_STATIC in the compile command-line:
c++ -o pbc_to_exe pbc_to_exe.o -L/usr/local/lib -L/opt/local/lib
-L/sw/lib -L/sw/lib -L/opt/local/lib -L/sw/lib blib/lib/libparrot.a -lm
-lgmp -lreadline /Users/allison/projects/svn/parrot/src/parrot_config.o
This is interesting as it's the same problem I'm having on Solaris:
$(LIBPARROT_STATIC) isn't getting expanded. Except Solaris complains
that the '(' shouldn't be there. See RT#50066.
Paul
Re: [perl #50066] [BUG] $LIBPARROT_STATIC macro not expanded properly when building pbc_to_exe
On 22/01/2008, chromatic [EMAIL PROTECTED] wrote: On Monday 21 January 2008 08:58:25 Paul Cochrane wrote: when building parrot on Solaris I get most of the way through the build, but right at the end, building pbc_to_exe fails with the following output: It seems that the Makefile macro $(LIBPARROT_STATIC) isn't being expanded. I had a bit of a look around and found the following lines in config_lib.pasm (which is used for the configuration information necessary to build pbc_to_exe): set P0[libparrot], $(LIBPARROT_STATIC) set P0[libparrot_ldflags], $(LIBPARROT_STATIC) further digging showed that these values are set within config/inter/libparrot.pm, and the code in there seems perfectly sane (especially considering that the value would be later expanded by make). Unfortunately, from here I don't know where else to look to solve the problem, however it is stopping me from building parrot on the Solaris platform at present. Are you building Parrot as static or shared? What happens if you switch to shared? I'm just using Cperl Configure.pl to configure the build, and it's setting the build to be static. Using Cperl Configure.pl --parrot_is_shared doesn't make a difference as Configure still determines that it's not building a shared parrot. Is LIBPARROT_STATIC defined correctly in your Makefile? LIBPARROT_STATIC = blib/lib/libparrot.a This looks good to me. This is the value I would expect the Clibparrot configuration value to be expanded to in config_lib.pasm. However, LIBPARROT is in the Makefile: LIBPARROT = $(LIBPARROT_STATIC) Which I would guess comes directly from the configured value, and hence why the value is carried over to config_lib.pasm, although I'm confused as to why this issue of not having an expanded value only occurs on Solaris and not on other Unix based systems. Paul
[perl #48142] [DEPRECATED] class_type vtable
On Tue Dec 04 20:12:24 2007, coke wrote: From PDD17: =item class_type INTVAL class_type(INTERP, PMC* self) Return the integer type of the PMC. [NOTE: will be deprecated when type IDs are deprecated.] The attached patch removes this vtable entry. The only thing still which seems to use class_type is dotnet, however, it fails its tests in exactly the same manner with and without this patch (dotnet does need some work...). If this patch is ok, please say so, otherwise I'll apply it in three days. Paul Index: DEPRECATED.pod === --- DEPRECATED.pod (revision 25016) +++ DEPRECATED.pod (working copy) @@ -74,10 +74,6 @@ See RT #47011. -=item * Cclass_type [post 0.5.1] - -See RT #48142. - =item * Cpmc_namespace [post 0.5.1] See RT# 48144. Replaced by Cget_namespace. Index: src/vtable.tbl === --- src/vtable.tbl (revision 25016) +++ src/vtable.tbl (working copy) @@ -349,7 +349,6 @@ void set_attr_keyed(PMC* key, STRING* idx, PMC* value) :write PMC* get_class() -INTVAL class_type() void add_parent(PMC* parent) :write void remove_parent(PMC* parent) :write Index: docs/pdds/pdd17_pmc.pod === --- docs/pdds/pdd17_pmc.pod (revision 25016) +++ docs/pdds/pdd17_pmc.pod (working copy) @@ -563,12 +563,6 @@ CClass object (or other high-level class object). For low-level PMCs, this returns a CPMCProxy object. -=item class_type [deprecated: See RT# 48142] - - INTVAL class_type(INTERP, PMC* self) - -Return the integer type of the PMC. - =item pmc_namespace [deprecated: See RT# 48144] PMC* pmc_namespace(INTERP, PMC* self)
[perl #42375] [TODO] deprecate pmcinfo op
On Sat Jan 12 04:42:26 2008, allison wrote:
This opcode has been superseded by 'inspect'.
The pmcinfo opcode is removed by the attached patch. I would have
committed this directly however, I'm not 100% sure that removing the:
'Class PMCs also have the I am a class flag set on them.'
test was the right thing to do. Something tells me that it should be
rewritten to use 'inspect' instead, but I don't know how to do this...
Feedback most definitely appreciated,
Paul
Index: DEPRECATED.pod
===
--- DEPRECATED.pod (revision 25038)
+++ DEPRECATED.pod (working copy)
@@ -132,10 +132,6 @@
See RT #48310.
-=item * Cpmcinfo [post 0.5.2]
-
-See RT #42375.
-
=back
=head1 Class Features
Index: src/ops/experimental.ops
===
--- src/ops/experimental.ops (revision 25016)
+++ src/ops/experimental.ops (working copy)
@@ -400,27 +400,6 @@
goto NEXT();
}
-=item Bpmcinfo(out INT, invar PMC, inconst INT)
-
-Extract some information about PMC $2 and store it in $1.
-Possible values for $3 are:
-
-=over 4
-
-=item .PMCINFO_FLAGS Get the PMC's flags.
-
-=back
-
-RT#42375 move/officalize this opcode at next op cleanup.
-
-=cut
-
-op pmcinfo(out INT, invar PMC, inconst INT) {
- if ($3 == PMCINFO_FLAGS)
- $1 = PObj_get_FLAGS($2);
- goto NEXT();
-}
-
=item Badd_io_event(invar PMC, invar PMC, invar PMC, inconst INT)
Index: include/parrot/pmc.h
===
--- include/parrot/pmc.h (revision 25016)
+++ include/parrot/pmc.h (working copy)
@@ -96,14 +96,6 @@
/* HEADERIZER END: src/pmc.c */
-/* pmcinfo parameters */
-
-/* gen_from_def(pmcinfo.pasm) */
-
-#define PMCINFO_FLAGS4 /* see also STRINGINFO_FLAGS */
-
-/* end_gen */
-
#endif /* PARROT_PMC_H_GUARD */
/*
Index: t/pmc/class.t
===
--- t/pmc/class.t (revision 25016)
+++ t/pmc/class.t (working copy)
@@ -17,10 +17,8 @@
=cut
-.const int TESTS = 49
-.include 'pmcinfo.pasm'
+.const int TESTS = 48
-
.sub 'main' :main
load_bytecode 'Test/More.pir'
.local pmc exporter, test_ns
@@ -30,7 +28,6 @@
plan(TESTS)
'new op'()
- 'class flag'()
'name'()
'new method'()
'attributes'()
@@ -59,21 +56,6 @@
isa_ok(class, 'Class')
.end
-
-# LPDD15/Class PMC API/'Class PMCs also have the I am a class flag set on them.'
-.sub 'class flag'
-.local pmc class
-.local int class_flags, class_flag_set
-.const int POBJ_IS_CLASS_FLAG = 536870912 # 1 29
-
-new class, 'Class'
-class_flags = pmcinfo class, .PMCINFO_FLAGS# XXX op currently experimental
-class_flag_set = class_flags POBJ_IS_CLASS_FLAG
-ok(class_flag_set, 'Class PMC has I am a class flag set')
-.end
-
-
-
# LPDD15/Class PMC API/=item name
.sub 'name'
.local pmc class, result
Index: t/pmc/pmc.t
===
--- t/pmc/pmc.t (revision 25016)
+++ t/pmc/pmc.t (working copy)
@@ -7,7 +7,7 @@
use lib qw( . lib ../lib ../../lib );
use Test::More;
-use Parrot::Test tests = 20;
+use Parrot::Test tests = 19;
use Parrot::PMC qw(%pmc_types);
=head1 NAME
@@ -364,22 +364,6 @@
42
OUTPUT
-pasm_output_is( 'CODE', 'OUTPUT', pmcinfo_i_p_ic );
-.include pmcinfo.pasm
-new P0, 'Integer'
-pmcinfo I0, P0, .PMCINFO_FLAGS
-shl I2, 1, 9# PObj_is_PMC_FLAG s. pobj.h
-band I1, I0, I2
-if I1, ok
-print PMC flag not set\n
-end
-ok:
-print ok\n
-end
-CODE
-ok
-OUTPUT
-
# Local Variables:
# mode: cperl
# cperl-indent-level: 4
[perl #48024] [DEPRECATED] type ids
Completed as per r25053.
Re: [perl #48260][PATCH] - compilers/imcc/main.c
Alan, The attached patch should quieten some of the grumbling. It's entirely comments, so should not have any functional impact. The patch wasn't attached. Could you try again? Thanks, Paul
Re: ubuntu-ppc-trunk BUILD FAILED
On 15/01/2008, Matisse Enzer [EMAIL PROTECTED] wrote: On Jan 14, 2008, at 1:00 AM, Paul Cochrane wrote: Matisse, this is great work! Would it be possible for you to summarise this on the parrot wiki somewhere?[1] Then we have a more permanent and central location for the information. Paul [1] http://www.perlfoundation.org/parrot/index.cgi?parrot OK - done. I have edited http://www.perlfoundation.org/parrot/index.cgi?parrot and added a new page http://www.perlfoundation.org/parrot/index.cgi?buildbot Looks great! Good work! Paul
Re: ubuntu-ppc-trunk BUILD FAILED
Matisse,
this is great work! Would it be possible for you to summarise this on
the parrot wiki somewhere?[1] Then we have a more permanent and
central location for the information.
Paul
[1] http://www.perlfoundation.org/parrot/index.cgi?parrot
Both passing and failing builds from buildbot should start showing up
there.
Also, the ircbot is now named eigenbot and remains on #parrot, but
you have to ask it for status info - it will not automatically
announce builds (yet.)
/msg eigenbot status
to watch a currently running build (get builder names from 'status'):
/msg eigenbot watch {builder-name}
On Jan 13, 2008, at 9:33 AM, Andy Armstrong wrote:
On 13 Jan 2008, at 17:28, Matisse Enzer wrote:
Yup, I saw that. Would it help if I set up a mailing list?
Sure - a second person has chimed in saying that a separate list,
hosted anywhere would do.
So create the list and I'll make the email go there.
http://hexten.net/mailman/listinfo/parrot-reports
[EMAIL PROTECTED]
Also, I am testing a patch to /usr/lib/python2.4/site-packages/
buildbot/status/mail.py that will allow configuring a mail notifier
for only passing builds, so that a different subject line (and/or
addresses) can be used for passing builds (right now it only allows
modes of 'failing', 'all' or 'problem' which means the first
failure after a passing build.)
Cool :)
--
Andy Armstrong, Hexten
---
Matisse Enzer [EMAIL PROTECTED]
http://www.matisse.net/ - http://www.eigenstate.net/
Re: [perl #38982] [CAGE] refactor long test files
James, However, based on my experience and ptc's in cage-cleaning, I'd recommend opening up individual RTs for test files that would benefit subdividing. That way, we can more easily identify which test files have been refactored and which remain to be done. Given the way we currently seem to interact with RT, I'd say open a ticket on a test-file by test-file basis rather than having a blanket ticket for the task. This seems to have been working particularly well for you recently, so I'd say resolve this ticket and open new ones as relevant. Paul
Re: [PATCH] probe for gcc -Wxxx only when gcc (well, g++)
On 09/01/2008, chromatic [EMAIL PROTECTED] wrote:
On Monday 07 January 2008 20:09:26 Jarkko Hietaniemi wrote:
--- config/auto/warnings.pm.dist 2008-01-08 05:51:42.0 +0200
+++ config/auto/warnings.pm 2008-01-08 06:01:23.0 +0200
@@ -132,17 +132,22 @@
$verbose = $conf-options-get('verbose');
print \n if $verbose;
-# add on some extra warnings if requested
-push @potential_warnings, @cage_warnings
-if $conf-options-get('cage');
-
-push @potential_warnings, '-Wlarger-than-4096'
-if $conf-options-get('maintainer');
-
-# now try out our warnings
-for my $maybe_warning (@potential_warnings) {
-$self-try_warning( $conf, $maybe_warning );
+my $gcc = $conf-options-get('gccversion');
+
+if (defined $gcc) {
+ # add on some extra warnings if requested
+ push @potential_warnings, @cage_warnings
+ if $conf-options-get('cage');
+
+ push @potential_warnings, '-Wlarger-than-4096'
+ if $conf-options-get('maintainer');
+
+ # now try out our warnings
+ for my $maybe_warning (@potential_warnings) {
+ $self-try_warning( $conf, $maybe_warning );
+ }
}
+
return 1;
}
I think you're right, however I'd like to hear how the identity-confused ICC
handles this patch before we apply it. Paul, how does it look?
Unfortunately I haven't been able to test the patch, however, icc
*should* handle -W flags exactly the same as gcc. And if it doesn't,
then there is an issue there we (or Intel) should deal with. So, I
would update the patch to ask if we have gcc or icc. I agree that -W
doesn't apply to some other compilers, so it's a good idea to restrict
the warnings checks to those compilers for which it is meaningful.
Paul
-- c
Re: [perl #49224] [BUG] Repeated problems with 'svn commit'
James, I've been seeing this problem off and on for over a month. As you've noticed, it's rather intermittent, however, when the problem occurs it persists for up to couple of hours. I've also seen that this is platform independent, and so guessed that the problem existed at the server end (maybe server load?). Unfortunately, I've got nothing consistent enough to be able to pinpoint where the issue is. Paul On 30/12/2007, James Keenan via RT [EMAIL PROTECTED] wrote: On Sun Dec 30 10:01:18 2007, rgrjr wrote: Come to think of it, I did three commits each on Monday and Tuesday, and must have seen it then (either or both days). -- Bob Perhaps not; the problem is intermittent. But yesterday I was getting it on about 1/3 of all my commits.
Re: Another deadlock on Mac OS 10.5.1
On 31/12/2007, James E Keenan [EMAIL PROTECTED] wrote: Andy Armstrong wrote: Sorry if I've missed something recent that means that this is expected behaviour but r24318 is hanging during make test on Mac OS 10.5.1 / Intel. The test log and pictures of the process probe are here: http://hexten.net/junk/20071230-193600/ I also have a few test failures on Ubuntu PPC: Test Summary Report --- t/configure/115-auto_warnings-01.t (Wstat: 0 Tests: 4 Failed: 0) TODO passed: 4 t/src/intlist.t(Wstat: 0 Tests: 4 Failed: 0) TODO passed: 1-4 t/src/io.t (Wstat: 0 Tests: 20 Failed: 0) TODO passed: 16-17, 19 These are the same TODO-ed out tests that are failing most everywhere. In the case of the failure in 115-auto_warnings-01.t, I think the problem is mostly a defect in the construction of the test. When ptc gets back, I hope to speak with him about it. It's not a major concern. I've unfortunately got no time to work on Parrot atm, but wish I did... Life outside of Parrot has become rather full. I'll be back at some stage, I just don't know when. t/examples/shootout.t (Wstat: 2560 Tests: 20 Ah! The shootout! Our old nemesis. Join the crowd; google the list archives. It almost never passes on Darwin and there's an old-ish ticket about it failing on Gentoo Linux. But it seems to pass on Debian. I have a vague feeling that the Gentoo ticket is from me, and I also have a vague feeling that the Gentoo shootout tests are all working atm (can't test that atm though...) I'm really impressed with the activity on Parrot atm; it's great to see :-) Happy New Year everyone! Paul
Re: [perl #47347] [TODO] Merge configuration steps gen::cpu and auto::cpu
On 26/12/2007, James Keenan via RT [EMAIL PROTECTED] wrote: Once I got the tuits, the merging of these two Parrot configuration steps went quite quickly. But before applying a patch to trunk, I would like the assistance of other testers on the 4 CPU platforms handled by gen::cpu and what formerly was auto::cpu. The platforms on which we need testers are: i386 ppc x86_64 sun4 I myself have been able to test on i386-linux and ppc-darwin, so I'm reasonably confident of the results there. (Though it would be great to have testers on, say, Win32 and FreeBSD for i386.) Where I could really use some help is with x86_64 and sun4. The easiest way to test would be to check out a sandbox of the 'cpu' branch in our repository, then do a standard run-through in the sandbox and post any failures or anomalies. That is: svn co https://svn.perl.org/parrot/branches/cpu/ cd cpu perl Configure.pl --test make make test Solaris 9, Sun C 5.8: Failed TestStat Wstat Total Fail List of Failed --- t/configure/025-options_test.t 255 65280 98 6-9 t/examples/library.t 1 256 41 3 (8 subtests UNEXPECTEDLY SUCCEEDED), 14 tests and 619 subtests skipped. Failed 2/523 test scripts. 5/10366 subtests failed. HTH, Paul
Re: Test failures on Solaris 9
On 20/12/2007, James E Keenan [EMAIL PROTECTED] wrote: Paul Cochrane wrote: Hi everyone, these failures probably aren't critical for release, however I thought it best to mention them. Paul System: Solaris 9 cc: Sun C 5.8 2005/10/13 Parrot revision: 24033 t/library/pcre... # Failed test (t/library/pcre.t at line 35) Paul: See http://rt.perl.org/rt3/Ticket/Display.html?id=48074 ... which, perhaps for different reasons, proposes a patch to this test. The test passes on Solaris 9 with the patch. I'd say it's worth committing that one :-) Good work! Paul
Re: [svn:parrot] r24052 - in trunk: . t/src
chromatic, [t] Nuked t/src/vtables.t, which pokes into the guts of libparrot using functions not documented nor promised in the extension API. Making this test work actually correctly in a sane and safe way would require either: Between 1/2 and 2/3 of the functions in src/vtables.c is actually being tested by the test suite (without the vtables.t test); how can we then exercise the remaining code to ensure that it (a) works or (b) is even necessary (IIRC Parrot_new_vtable() is never called)? I would like to (at some stage) increase the test coverage level of the C-language parts of Parrot. How is it best to do this? By testing the C routines directly (my first guess)? Or indirectly via pir or something? Paul
Test failures on Solaris 9
Hi everyone, these failures probably aren't critical for release, however I thought it best to mention them. Paul System: Solaris 9 cc: Sun C 5.8 2005/10/13 Parrot revision: 24033 t/library/pcre... # Failed test (t/library/pcre.t at line 35) # Exited with error code: 1 # Received: # ok 1 # ok 2 # Null PMC access in invoke() # current instr.: 'parrot;PCRE;compile' pc 118 (/home/cochrane/parrot/runtime/parrot/library/pcre.pir:127) # called from Sub 'main' pc 50 (/home/cochrane/parrot/t/library/pcre_1.pir:37) # # Expected: # ok 1 # ok 2 # ok 3 # ok 4 # ok 5 # t/library/pcre...NOK 1/1# Looks like you failed 1 test of 1. t/stm/basic_mt...ok 2/4 # Failed test (t/stm/basic_mt.t at line 168) # Exited with error code: 134 # Received: # src/stm/backend.c:794: failed assertion 'successp' # Abort # # Expected: # /okay/ # t/stm/basic_mt...NOK 3/4# Looks like you failed 1 test of 4. t/examples/library...ok 2/4Null PMC access in invoke() current instr.: 'parrot;PCRE;compile' pc 118 (library/pcre.pir:127) called from Sub 'parrot;PCRE;main' pc 271 (examples/library/pcre.pir:56) # Failed test (t/examples/library.t at line 67) # got: 'asdf =~ /as/ # ' # expected: 'asdf =~ /as/ # 1 match(es): # as # ' t/examples/library...NOK 3/4# Looks like you failed 1 test of 4.
Test failures on Win32
Hi, I've been doing some testing on Win32 as well, here are my current results: (I'm also still getting the failure I posted earlier with t/examples/tutorial.t, so I've left it out) Paul System: WindowsXP cc: Visual Studio 2005 perl: ActiveState Parrot revision: 24034 t/pmc/scheduler..NOK 1# Failed test (t/pmc/sched uler.t at line 25) # Exited with error code: 255 # Received: # # Expected: # created # 1 # t/pmc/scheduler..NOK 2# Failed test (t/pmc/sched uler.t at line 54) # Exited with error code: 255 # Received: # # Expected: # created # 1 # Caught exception on bad initializer # # Looks like you failed 2 tests of 3. t/pmc/scheduler..dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 1-2 Failed 2/3 tests, 33.33% okay
Re: Tests Okay on 32-bit x86 GNU/Linux (GCC 4.1.3)
On 17/12/2007, chromatic [EMAIL PROTECTED] wrote:
After fixing a few small tests, fulltest passes everything but a couple of
in-progress coding standards tests on my platform. The release is ready on
the world's most lenient platform.
Unfortunately, I wish I could say the same. I'm getting the following error:
(Debian, gcc 4.1.2, r24008)
src/ops/experimental.ops:535: error: unable to find a register to
spill in class 'SIREG'
src/ops/experimental.ops:535: error: this is the insn:
(insn 63776 63775 63777 2349 src/ops/set.ops:557 (parallel [
(set (reg:SI 2 cx [57281])
(const_int 0 [0x0]))
(set (reg:SI 5 di [orig:57278 D.58560 ] [57278])
(plus:SI (ashift:SI (reg:SI 2 cx [57281])
(const_int 2 [0x2]))
(reg:SI 5 di [orig:57278 D.58560 ] [57278])))
(set (reg/f:SI 1 dx [orig:57279 clone ] [57279])
(plus:SI (ashift:SI (reg:SI 2 cx [57281])
(const_int 2 [0x2]))
(reg/f:SI 1 dx [orig:57279 clone ] [57279])))
(set (mem/s:BLK (reg:SI 5 di [orig:57278 D.58560 ]
[57278]) [0 S24 A32])
(mem/s:BLK (reg/f:SI 1 dx [orig:57279 clone ] [57279])
[0 S24 A32]))
(use (reg:SI 2 cx [57281]))
(use (reg:SI 19 dirflag))
]) 704 {*rep_movsi} (nil)
(expr_list:REG_UNUSED (reg/f:SI 1 dx [orig:57279 clone ] [57279])
(expr_list:REG_UNUSED (reg:SI 5 di [orig:57278 D.58560 ] [57278])
(expr_list:REG_UNUSED (reg:SI 2 cx [57281])
(expr_list:REG_DEAD (reg:SI 19 dirflag)
(expr_list:REG_UNUSED (reg/f:SI 1 dx [orig:57279
clone ] [57279])
(expr_list:REG_UNUSED (reg:SI 5 di [orig:57278
D.58560 ] [57278])
(expr_list:REG_UNUSED (reg:SI 2 cx [57281])
(nil)
src/ops/experimental.ops:535: confused by earlier errors, bailing out
make: *** [src/ops/core_ops_cg.o] Error 1
This means that I'm currently not able to build parrot (I don't know
how many other people this affects though...).
Any ideas as to what could be causing this? I've got no local changes
either, so this is somewhat odd.
Paul
Re: on non-pdd documentation
the .pod files from the source, imho. (does parrot have a make docs target?) Yes, it's the make html target. Paul
Re: The headerizer and comment blocks
On 12/12/2007, jerry gay [EMAIL PROTECTED] wrote:
On Dec 11, 2007 11:08 PM, Andy Lester [EMAIL PROTECTED] wrote:
I made it make comment blocks look like this:
/*
=item CQUEUE_ENTRY * pop_entry
Does a synchronized removal of the head entry off the queue and
returns it.
=cut
*/
PARROT_CAN_RETURN_NULL
QUEUE_ENTRY *
pop_entry(ARGINOUT(QUEUE *queue))
{
... function body...
a good start.
Does anyone actually run something like perldoc src/filename.c to
look at the docs? I'm thinking that if nobody actually does that, we
could save the doc discussion until we're actually at a point where
we're generating docs. Right now, I think that what I've got as the
prototype above is 90% there, and gets rid of the tons of cut'n'paste
that are sprinkled throughout the C code.
Let me know your thoughts, so I can do more automation and run it on
the rest of the source files.
nobody really looks at docs in generated .c files, we go to the source
(.pmc, .ops, .in, etc.) why don't you finish the plumbing, and we'll
save the bickering for when the information is flowing everywhere we
need.
AFAIK, at least some of the C docs are automatically turned into html
and posted on parrotcode.org (I could be mis-remembering something
here though). But it's hard to know how many people use that. I know
that a lot of the docs which *could* be posted to parrotcode.org (i.e.
via 'make html') unfortunately aren't.
once we've decided on a standard doc style, let's document it in PDD07
so it's law.
Hadn't we decided on that? Basically, add everything in? That's why
I did the effort of the C function docs tests... I would rather the
process of updating the docs be automated though. (BTW: Andy: great
job on the function declaration extraction stuff! It helped
enormously in getting refactoring some of the common code out into a
module, and then reusing it in the c-function docs test).
My apologies that I've not got around to implementing this myself, as
I intended to as you were away Andy, but my tuits are now at the level
of just keeping the coding standards tests running...
Paul
Re: Platform testing for concurrency scheduler runloop
On 07/12/2007, Allison Randal [EMAIL PROTECTED] wrote: Andy Dougherty wrote: Whether this is a defect in the vtables_4 test sourcefile for failing to initialize the vtables, or whether pmc_new ought to be more defensive, I can't say. Looks like a bug in the test, as there are other things in Parrot_exit that won't behave appropriately without an initialized vtable. PTC, this is a new test file you added a few days ago. Do you have some more details on what the 4th test is testing? Essentially the test is just trying to exercise the code in src/vtables.c (I'm still on a bit of a learning curve wrt C-related tests within Parrot, so it's highly likely I've misunderstood something in writing the test). My guess is that the test certainly needs fixing, and probably the docs for the functions in src/vtables.c extended so that one has a good idea how to use the functions. As an aside, I did find that Parrot_new_vtable() is almost never used in the Parrot source; Parrot_clone_vtable() is used instead, so there was a bit of guesswork involved in writing the tests. Is Parrot_new_vtable() therefore necessary? Paul
[perl #48266] [TODO] [C] Write file-level documentation
Apologies for the extra email! This was an abortive attempt to Ctrl-C out of a command line RT session. Closing ticket.
Re: [svn:parrot] r23307 - trunk/examples/sdl
On 02/12/2007, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Sun, Dec 02, 2007 at 10:44:08AM +0100, Paul Cochrane wrote: ... and I only needed to switch off the warnings about a lack of Cuse strict/warnings. At present, this isn't a maintanence burden, but as soon as we get lots of nqp/perl6 files we will need to rethink how we handle them. I don't think it's worth worrying about just yet. I disagree. I think we'll quickly be accumulating a lot of Perl 6/NQP files, and putting the nocritic lines in all of them is a bit of a pain, as well as adjusting them all later. If it helps, we can start marking all such files with 'use v6;', and then the critic (or its driver) can use that to decide if the file should be checked. Or, if that's not good enough, then I'd at least want to put the nocritic lines with the coda instead of at the head of the file (if that's even possible). Unfortunately, putting the nocritic lines at the end of the file with the coda doesn't work. I think marking the files with Cuse v6; would be really good (this syntax isn't recognised yet though, is it?), then I could filter which files should be passed through the relevant policies of Perl::Critic. Paul
Re: [svn:parrot] r23307 - trunk/examples/sdl
On 01/12/2007, Will Coleda [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: Author: paultcochrane Date: Sat Dec 1 06:08:08 2007 New Revision: 23307 Modified: trunk/examples/sdl/blue_rect.pl Log: [examples] - corrected editor coda - added no critic flags to switch off Perl::Critic warnings for the use strict and use warnings pragmas as they aren't part of NQP Modified: trunk/examples/sdl/blue_rect.pl NQP and Perl6 aren't Perl5; Should we really be running the perl5 coding standard tests against them? Probably not, but having the correct coda is a good thing, and I only needed to switch off the warnings about a lack of Cuse strict/warnings. At present, this isn't a maintanence burden, but as soon as we get lots of nqp/perl6 files we will need to rethink how we handle them. I don't think it's worth worrying about just yet. Paul
Re: Seeking Comments on a Variety of RT Tickets
https://rt.perl.org/rt3/Ticket/Display.html?id=46539 [BUG] compilers/pirc/new/pir.l failing t/codingstd/cppcomments.t Coke commented on this on Oct 21, but ticket has not been resolved. Spot check of smoke tests suggests it may now be passing on all OSes. compilers/pirc/new/pir.l is exempt from the coding standards tests. This has been fixed for a while and AFAIK the ticket can be closed. Paul
Re: reference books for Parrot design and development?
Hi Jerry, Besides the obvious _Perl6 and Parrot Essentials_, are there any other books that one could use to get a good background for Parrot development? I'm wondering if there are any references that people developing Parrot are using. AFAIK Perl6 and Parrot Essentials isn't very up to date with the current Parrot status. There is, however, a large body of documentation available which (I hope!) can help you, namely: http://www.parrotcode.org/docs/. The docs/ directory within the Parrot svn repository also contains a lot of information. There are also lots of nice people who hang out on the #parrot irc channel (try irc.perl.org for instance) who I'm sure will be all too happy to answer any questions you have :-). You also might want to check out the archives for this mailing list at http://www.nntp.perl.org/group/perl.perl6.internals/ I hope that helps to some degree, and welcome! Paul
Re: [perl #47886] [TODO] 'make quicktest' target
On 28/11/2007, Patrick R. Michaud via RT [EMAIL PROTECTED] wrote: The attached coretest.patch file adds a make coretest target to Parrot. This target runs a smaller subset of tests than the normal make test target. On my system, make test completes in ~290 seconds, while make coretest completes in ~200. The following tests are not included in make coretest: t/configure/ t/postconfigure/ t/compilers/json/ t/examples/ t/doc/ t/distro/ t/codingstd/ This patch also refactors the way that the default lists of test are constructed in t/harness, so that we aren't globbing test directories for lists of files we're not going to run anyway. Lastly, this patch will make it possible for us to factor out the $(RUNCORE_TESTS) variable that lists other core tests to be run for the various runcores. At present adding core tests to Parrot involves updating both t/harness and the Makefile, this refactor will make it possible to keep the list in one place (t/harness). Feedback welcome. If I hear support for this patch I'll go ahead and apply it (with any suggested changes). Thanks! Pm +1
Re: [perl #47792] [BUG]: languages/dotnet/Configure.pl causes configuration error
On 25/11/2007, via RT James Keenan [EMAIL PROTECTED] wrote: # New Ticket Created by James Keenan # Please include the string: [perl #47792] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47792 While running Configure.pl on Linux today, I repeatedly got this error: Configuring languages...main::get_parrot_config() called too early to check prototype at Configure.pl line 32. main::generate_makefile() called too early to check prototype at Configure.pl line 35. main::generate_config_pm() called too early to check prototype at Configure.pl line 38. Use of uninitialized value in substitution (s///) at Configure.pl line 77. ..done. This error has been happening in dotnet for a long time. I can't give you a better timeframe than that, but it's been in that state (giving these warnings) since before I managed to get it's Configure.pl to go again, (which was a few months ago now). Paul
Re: [perl #47792] [BUG]: languages/dotnet/Configure.pl causes configuration error
On 25/11/2007, James E Keenan [EMAIL PROTECTED] wrote: On Nov 25, 2007, at 12:52 PM, Paul Cochrane via RT wrote: This error has been happening in dotnet for a long time. I can't give you a better timeframe than that, but it's been in that state (giving these warnings) since before I managed to get it's Configure.pl to go again, (which was a few months ago now). Paul: I really have to wonder about that. In my work, I am *constantly* running: svn update;perl Configure.pl ... and I only started to get this error today. As I was offline for a couple of days, the error has to have crept in since Thursday. I too am running Configure.pl constantly, however, not dotnet's Configure.pl. This is the script I was referring to. Paul
Re: [svn:parrot] r22938 - in trunk: config/gen/makefiles include/parrot/atomic src/atomic
On 22/11/2007, chromatic [EMAIL PROTECTED] wrote: On Wednesday 21 November 2007 12:50:48 [EMAIL PROTECTED] wrote: Log: [core,config] Moved executable code out of gcc_x86.h. This closes RT#47245. Does t/src/atomic.t still work for you after this change? It fails for me, because the code's no longer available from external programs (that is, code not built into libparrot). It passes for me (otherwise I wouldn't have made the commit). I'm not sure what the proper fix is, except maybe always copying the correct code into a .c file under src/ with a fixed name independent of platform and manually including that file directly in the source code in the tests. If the failing test is going to be a problem, we could revert the change and I could try to investigate what's happening here. I think your fix is along the right track, as what we need to do here is similar to what happens with the jit code. Paul
Re: [svn:parrot] r22876 - trunk/t/codingstd
On 18/11/2007, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Sun, Nov 18, 2007 at 06:03:28AM -0800, [EMAIL PROTECTED] wrote: Log: [codingstd] If a comma is followed by a single quote, it very likely in a situation like: moo = ','; In which case, there shouldn't be a space after the comma. Updating test to handle this situation. Shouldn't the test simply completely ignore commas (and semicolons) that happen to appear in strings and comments? Agreed. Change implemented in r22900. Paul
Re: [svn:parrot] r22864 - trunk/src/pmc
On 17/11/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: chromatic Date: Sat Nov 17 14:06:29 2007 New Revision: 22864 Modified: trunk/src/pmc/closure.pmc trunk/src/pmc/key.pmc trunk/src/pmc/object.pmc trunk/src/pmc/slice.pmc trunk/src/pmc/timer.pmc Log: [PMC] Cleaned up some compiler warnings, mostly related to missing defaults in switch statements. I added a couple of exceptions which may need review and testing. Who reads commit messages? Let's see if you're on the ball here. It looks ok to me. After I added the warning flag for default cases I noticed that in quite a few instances a Cswitch was used for a single item and therefore where an Cif would have done the job more than adequately. Is there reason to use a Cswitch in such instances? Is it more efficient? Or is it just trying to anticipate the future a bit? Paul
Re: [perl #47523] [NEW] Coding standards test for spacing after commas and semicolons
On 17/11/2007, James E Keenan [EMAIL PROTECTED] wrote: Paul Cochrane wrote: # New Ticket Created by Paul Cochrane # Please include the string: [perl #47523] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47523 Hi everyone! One nit I have about C-code is that I think there should be a space after commas and semicolons. I am not a C-coder, so I don't have an authoritative opinion about this. But I would like to ask: In this a common standard/'best practice' in C programming? If so, then I think the standard should be approved. But if it's not yet generally accepted, I would say no. That's why I posted a patch to the list, so that this could be discussed. My opinion is that code is easier to read if there are spaces after commas, and spaces after semicolons (especially in for loops). E.g: function(foo, bar, moo, baa); is easier on the eyes than: function(foo,bar,moo,baa); and for(i=0; i10; i++) easier to read than: for(i=0;i10;i++) Basically that's my motivation for the patch. If there's something I can do to make the Parrot source tidy and easier for people to develop (even if it's something really small) then I'm all for it. Paul
Re: [perl #47397] t/op/arithmetics.t hangs
Andy, Here are the warnings I got on my latest run, along with the number of times each one appeared: (this was with gcc-4.1.0 on Solaris/SPARC) snip warnings summary This is very helpful for me to try and improve the situtation. Thanks! I'll switch off the visibility attribute warning if possible and then I can start working through some of the other warnings. I just need access to a gcc 4 box now... Paul
Re: [perl #47397] t/op/arithmetics.t hangs
On 13/11/2007, Nicholas Clark [EMAIL PROTECTED] wrote: On Mon, Nov 12, 2007 at 12:33:41PM -0800, Andy Dougherty wrote: It may well be there's an issue with gcc's optimizer, since the problem goes away without optimization, but I think it's also fair to say that the definition of FLOAT_IS_ZERO in include/parrot/misc.h is perhaps not optimal here. I'd prefer the simpler definition: #define FLOAT_IS_ZER0(f) ((f) == 0.0) but I didn't get anywhere last time I proposed that. I don't know what else to do. I suggested f = 0.0 f = 0.0 which I believe is identical, even in the face of NaNs, but should also shut up the whining, er, warning, about comparison. Because I would be so bold as to say that the constant zero would be exempted from any useful warning about floating point equality check. The floating point comparison warning isn't switched on (in gcc) anymore. If it's on somewhere else, then I'd like to know so that we can switch off the warning on that compiler. Paul
Re: [svn:parrot] r22824 - trunk/lib/Parrot/Configure
On 14/11/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: chromatic Date: Tue Nov 13 17:42:13 2007 New Revision: 22824 Modified: trunk/lib/Parrot/Configure/Step.pm Log: [configure] Don't use the libs in the configuration object when linking C files in the configuration tests. For some reason, they're wrong (why does it think I have GDBM installed? I don't have GDBM installed, and it's already done a probe to find GDBM!). This may not be the rightest solution, but in lieu of figuring out how to get the correct configuration object here, one which knows which libraries are actually necessary and installed, I can live with this. Now all tests pass by default on x86 GNU/Linux. Unfortunately, this breaks Configure on Windows. We need to find a cleaner solution to this problem. I'm going to revert this change in order to get Windows back working again. Paul
Re: [perl #47397] t/op/arithmetics.t hangs
On 14/11/2007, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Wed, Nov 14, 2007 at 09:20:40AM -0500, Andy Dougherty wrote: On Tue, 13 Nov 2007, Nicholas Clark via RT wrote: On Mon, Nov 12, 2007 at 12:33:41PM -0800, Andy Dougherty wrote: It may well be there's an issue with gcc's optimizer, since the problem goes away without optimization, but I think it's also fair to say that the definition of FLOAT_IS_ZERO in include/parrot/misc.h is perhaps not optimal here. I'd prefer the simpler definition: #define FLOAT_IS_ZER0(f) ((f) == 0.0) but I didn't get anywhere last time I proposed that. I don't know what else to do. I suggested f = 0.0 f = 0.0 which I believe is identical, even in the face of NaNs, but should also shut up the whining, er, warning, about comparison. Yes, as long as whatever expressions we use for f don't have any side effects (but you both already know this :-). You're probably right. However, given that gcc currently throws over a thousand warnings it's hard to get worried about about another one or two. IIRC, part of the reason we went to some effort to shut up the floating point comparison warnings from gcc was because there were significantly more than one or two of them. :-) But like Andy I've always been strongly in favor of the ((f) == 0.0) approach and simply turning off the float_equals warnings in gcc. The float_equals warnings in gcc *are* off. So why is this warning a problem (maybe I've missed something)? I also don't see over 1000 warnings with gcc (I've got gcc 3.4.5 on Gentoo Linux x86); I have in the order of 100 atm. If we *are* seeing over 1000 warnings with gcc, then either we should turn the warnings level down a bit, or the warnings should be fixed (like some warnings about required non-null arguments I know). Paul
[perl #46697] [TODO] [C] Move the exception macros from src/pmc/coroutine.pmc into exceptions.h
On Sun Nov 11 09:57:07 2007, coke wrote: On Mon Oct 22 15:02:26 2007, rgrjr wrote: From: Paul Cochrane (via RT) [EMAIL PROTECTED] Date: Mon, 22 Oct 2007 10:43:32 -0700 # New Ticket Created by Paul Cochrane # Please include the string: [perl #46697] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46697 In src/pmc/coroutine.pmc there is the todo item: /* XXX put these into exceptions.h */ After this comment there are four macros. These need to be transferred to exceptions.h and then the header used in this file. These macros are not used, so I nuked 'em in r22406. -- Bob Rogers http://rgrjr.dyndns.org/ So, can we close this ticket now? Yup. Closing ticket.
Re: [perl #47349] [BUG] 'make' failure on Darwin
kid51, this error is caused by gcc_pcc.h using 'inline' directly, and I added -std=c89 to the list of gcc compiler options just recently. What you need to do is replace the 'inline' keyword in gcc_pcc.h with PARROT_INLINE and everything should work again. Paul On 11/11/2007, via RT James Keenan [EMAIL PROTECTED] wrote: # New Ticket Created by James Keenan # Please include the string: [perl #47349] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47349 After an 'svn update' to r22806 on my iBook this morning, I configured and sought to build Parrot. 'make' failed about 1/3 of the way through. See attached file; here are the highlights: /usr/local/bin/perl tools/build/c2str.pl src/pmc/undef.c src/pmc/ undef.str /usr/local/bin/perl tools/build/c2str.pl --all src/string.c In file included from include/parrot/atomic.h:26, from include/parrot/thread.h:19, from include/parrot/pmc.h:18, from include/parrot/parrot.h:272, from src/string.c:27: include/parrot/atomic/gcc_pcc.h:26: error: syntax error before static include/parrot/atomic/gcc_pcc.h:50: error: syntax error before static src/string.c: In function `string_escape_string_delimited': src/string.c:2509: warning: switch missing default case make: *** [src/string.o] Error 1 The last time I ran a full 'make' on Darwin was on October 18, so this error probably crept in since then. I configured, built and tested successfully on Linux this morning, so this may be an error that occurs on certain OSes and not others. kid51 [parrot] 549 $ make Compiling with: xx.c /usr/bin/gcc-3.3 -I./include -fno-common -no-cpp-precomp -pipe -I/usr/local/include -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -g -std=c89 -W -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wimport -Winline -Wmain -Wmissing-braces -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wno-unused -Wnonnull -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wsign-compare -Wstrict-aliasing -Wstrict-prototypes -Wswitch -Wswitch-default -Wnested-externs -Wundef -Wunknown-pragmas -Wwrite-strings -Wsign-compare -falign-functions=16 -Wdisabled-optimization -Wformat-nonliteral -Wformat-security -Wpacked -Wno-shadow -DHAS_JIT -DPPC -DHAVE_COMPUTED_GOTO -I. -o xx.o -c xx.c /usr/local/bin/perl tools/build/ops2pm.pl src/ops/core.ops src/ops/bit.ops src/ops/cmp.ops src/ops/debug.ops src/ops/experimental.ops src/ops/io.ops src/ops/math.ops src/ops/object.ops src/ops/pic.ops src/ops/pmc.ops src/ops/set.ops src/ops/stack.ops src/ops/stm.ops src/ops/string.ops src/ops/sys.ops src/ops/var.ops throwcc_pSKIPPED: not in ops.num nor ops.skip throwcc_p_p SKIPPED: not in ops.num nor ops.skip print_newline 1219 experimental, not in ops.num print_newline_p 1220 experimental, not in ops.num gcd_i_n_n 1221 experimental, not in ops.num gcd_i_nc_n1222 experimental, not in ops.num gcd_i_n_nc1223 experimental, not in ops.num gcd_i_nc_nc 1224 experimental, not in ops.num gcd_i_i_i_i_i 1225 experimental, not in ops.num gcd_i_i_i_ic_i1226 experimental, not in ops.num gcd_i_i_i_i_ic1227 experimental, not in ops.num gcd_i_i_i_ic_ic 1228 experimental, not in ops.num splice_p_p_i_i1229 experimental, not in ops.num splice_p_p_ic_i 1230 experimental, not in ops.num splice_p_p_i_ic 1231 experimental, not in ops.num splice_p_p_ic_ic 1232 experimental, not in ops.num slice_p_p_k 1233 experimental, not in ops.num slice_p_p_kc 1234 experimental, not in ops.num slice_p_p_k_ic1235 experimental, not in ops.num slice_p_p_kc_ic 1236 experimental, not in ops.num iter_p_p 1237 experimental, not in ops.num morph_p_i 1238 experimental, not in ops.num morph_p_ic1239 experimental, not in ops.num morph_p_s 1240 experimental, not in ops.num morph_p_sc1241 experimental, not in ops.num exec_s1242 experimental, not in ops.num exec_sc 1243 experimental, not in ops.num classname_p_p 1244
Re: [perl #47349] [BUG] 'make' failure on Darwin
On 12/11/2007, James Keenan via RT [EMAIL PROTECTED] wrote: On Sun Nov 11 10:27:32 2007, ptc wrote: kid51, this error is caused by gcc_pcc.h using 'inline' directly, and I added -std=c89 to the list of gcc compiler options just recently. What you need to do is replace the 'inline' keyword in gcc_pcc.h with PARROT_INLINE and everything should work again. Sorry, everything did not work again. While substituting PARROT_INLINE for inline did not prevent 'make' from succeeding on Linux, I got extensive failures on Darwin. My next guess now is that the -std=c89 gcc compiler option doesn't play nicely with your system headers. I've removed the compiler flag in r22809, see how you go. Paul
Re: [svn:parrot] r22780 - in trunk/src: . pmc
On 10/11/2007, chromatic [EMAIL PROTECTED] wrote:
On Friday 09 November 2007 09:00:00 [EMAIL PROTECTED] wrote:
Author: paultcochrane
Date: Fri Nov 9 08:59:59 2007
New Revision: 22780
Modified:
trunk/src/objects.c
trunk/src/pmc/namespace.pmc
trunk/src/pmc_freeze.c
Log:
[core,pmc] Removed unreachable code compiler warnings
Modified: trunk/src/objects.c
===
=== --- trunk/src/objects.c(original)
+++ trunk/src/objects.c Fri Nov 9 08:59:59 2007
@@ -1918,10 +1918,8 @@
/* RT#45989 escape NUL char */
if (VTABLE_exists_keyed_str(interp, attr_hash, full_attr_name)) {
-char * const c_error = string_to_cstring(interp, full_attr_name);
-real_exception(interp, NULL, 1, Attribute '%s' already exists,
c_error); -/* RT#45991 leak! */
-string_cstring_free(c_error);
+real_exception(interp, NULL, 1, Attribute '%s' already exists,
+string_to_cstring(interp, full_attr_name));
}
I'm not a huge fan of this, especially when removing the RT #45591 link, but a
better solution is to use the format %Ss, which tells Parrot's sprintf engine
that it's getting a STRING. This avoids the memory leak of
string_to_cstring().
Ok, that's good to know. I'll go through and change the recent
commits of this kind to use %Ss which probably also means that I can
get rid of the ticket as well, right?
Paul
Re: [perl #47289] [PATCH] Move executable code out of jit/i386/exec_dep.h
On 09/11/2007, Joshua Isom [EMAIL PROTECTED] wrote: Did you test the exec runcore? I don't think any of that code is used outside of the exec runcore so you aren't actually testing that code. I'll have a go at testing against the exec runcore and see what turns up. This is likely something we should be testing more often right? Paul
Re: [perl #47247] [PATCH] Move executable code out of gcc_pcc header
James, Thanks for the report! I forgot to add parrot.h to the list of includes. Could you add: #include parrot/parrot.h just before the other include statement in gcc_pcc.c and see if things make (after realclean) nicely for you? Ta! Paul Failed on Darwin PPC at about 40% of the way thru 'make'. Note: I only applied this patch; not the other one you posted today. See attached. Compiling with: xx.c /usr/bin/gcc-3.3 -I./include -fno-common -no-cpp-precomp -pipe -I/usr/local/include -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -g -W -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wimport -Winline -Wmain -Wmissing-braces -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wno-unused -Wnonnull -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wsign-compare -Wstrict-aliasing -Wstrict-prototypes -Wswitch -Wnested-externs -Wundef -Wunknown-pragmas -Wwrite-strings -Wsign-compare -falign-functions=16 -Wdisabled-optimization -Wformat-nonliteral -Wformat-security -Wpacked -Wno-shadow -DHAS_JIT -DPPC -DHAVE_COMPUTED_GOTO -I. -o xx.o -c xx.c src/atomic/gcc_pcc.c In file included from src/atomic/gcc_pcc.c:15: include/parrot/atomic/gcc_pcc.h:26: error: syntax error before void include/parrot/atomic/gcc_pcc.h:29: error: syntax error before long src/atomic/gcc_pcc.c:18: error: syntax error before void src/atomic/gcc_pcc.c:43: error: syntax error before long make: *** [src/atomic/gcc_pcc.o] Error 1
Re: [perl #47245] [PATCH] Move executable code out of gcc_x86 header
On 08/11/2007, chromatic [EMAIL PROTECTED] wrote: On Wednesday 07 November 2007 14:58:40 Paul Cochrane wrote: The file include/atomic/gcc_x86.h contains executable code. The attached patch moves this code out into a new file src/atomic/gcc_x86.c. make test passes, so things look ok to make this move from this standpoint, however I'd like some more people's opinions as to whether or not this is a good thing to do. So, comments definitely welcome. If noone complains, (or even better if someone recommends this patch) then I'll commit the patch in about 3 days. Provided someone tests it with make realclean on x86 Linux and x86 Darwin and all tests pass, +1 from me. This tests ok with a make realclean on x86 Linux (Gentoo) Paul
Re: [perl #46727] [TODO] config/auto/ctags.pm: Write unit tests
kid51, On 05/11/2007, James Keenan via RT [EMAIL PROTECTED] wrote: The patch attached refactors configuration step auto::ctags to maximize testability. It also provides 3 test files to replace ptc's original test file. ptc's original functionality is, however, maintained intact. Assuming no objection, I'll apply this in 2-3 days. The patch looks good. One thing which would be a nice to have is the documentation to say what the difference between the four test files is. Or put another way: a comment as to what specific feature of ctags is being tested. Paul
Re: [perl #47043] [BUG] compilers/pirc/macro/macrolexer.c andn macroparser.c: fail metadata, codingstd tests
On 31/10/2007, Klaas-Jan Stol [EMAIL PROTECTED] wrote: On Oct 31, 2007 4:35 AM, chromatic [EMAIL PROTECTED] wrote: On Tuesday 30 October 2007 19:27:52 James Keenan wrote: As has been the case lately, a couple of 'pirc'-related files have been failing metadata and coding standards tests. Here's results from make test on Linux tonight (approx rev 22628). t/distro/file_metadata...# Collecting svn:mime- type attributes... # Collecting svn:keywords attributes... # Collecting svn:eol-style attributes... # Failed test (t/distro/file_metadata.t at line 147) # got: 'Set svn:eol-style with: # svn ps svn:eol-style 'native' compilers/pirc/macro/macrolexer.c; # ' # expected: '' # Collecting svn:eol-style attributes... # Looks like you failed 1 test of 4. dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 3 Failed 1/4 tests, 75.00% okay If you or anyone else see failures like this, feel free to run that command and check in the modified files. That's a quick and easy fix, and it should have no bearing on tests of functional behavior. Fixed in r22630. t/codingstd/linelength... # Failed test (t/codingstd/linelength.t at line 82) # Lines longer than coding standard limit (100 columns) in 2 files: # /home/jimk/work/backtrace/compilers/pirc/macro/macrolexer.c:2179: 109 cols # /home/jimk/work/backtrace/compilers/pirc/macro/macroparser.c:759: 102 cols # Looks like you failed 1 test of 1. dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/1 tests, 0.00% okay This test should be TODO, or not run by default. It's been a broken window for several days, and whoever made it run by default hasn't fixed it. Removed from the default test run in r22631. -- c I'm the one to blame here. The macro parser/lexer is implemented using bison/flex, meaning that the C files are generated. I had a look at which lines failed, and both are generated. I added all files of compilers/pirc/macro to the list of exemptions in lib/parrot/Distribution.pm, but somehow that doesn't work, apparently. I'd like to have it fixed, but I don't know how I can help at this point, except removing the files. kjs: I just realised that the linelength test organises its exemptions differently to the rest of the coding standards tests. The exemptions are listed at the end of the file. Sorry! I could/should have told you that last night If you add the relevant files to the __DATA__ section in t/codinstd/linelength.t then everything should be sorted. Paul
Re: [perl #47043] [BUG] compilers/pirc/macro/macrolexer.c andn macroparser.c: fail metadata, codingstd tests
On 31/10/2007, Klaas-Jan Stol [EMAIL PROTECTED] wrote: sorry, it should have read r22631. On Oct 31, 2007 11:33 AM, Klaas-Jan Stol [EMAIL PROTECTED] wrote: Is it ok to revert r22361 now (where chromatic removed the linelength test from the set of default run tests)? If the tests are passing: yes. Paul
Fwd: [svn:parrot] r22585 - trunk/src
This email didn't make the list so I'm sending it again.
Paul
-- Forwarded message --
From: Paul Cochrane [EMAIL PROTECTED]
Date: 29 Oct 2007 15:36
Subject: Re: [svn:parrot] r22585 - trunk/src
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
On 29/10/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: particle
Date: Mon Oct 29 05:59:52 2007
New Revision: 22585
Modified:
trunk/src/debug.c
trunk/src/inter_create.c
Log:
casting to avoid warnings
Modified: trunk/src/debug.c
==
--- trunk/src/debug.c (original)
+++ trunk/src/debug.c Mon Oct 29 05:59:52 2007
@@ -335,7 +335,7 @@
/* Nonempty and did not start with a letter */
if (c == 0)
-c = -1;
+c = (unsigned long)-1;
*cmdP = c;
@@ -411,7 +411,7 @@
/* generate string (no more than 255 chars) */
while (ch != EOF ch != '\n' (i 255)) {
-c[i++] = ch;
+c[i++] = (char)ch;
ch = fgetc(stdin);
}
@@ -733,7 +733,7 @@
}
/* get the register number */
-condition-reg = atoi(++command);
+condition-reg = (unsigned char)atoi(++command);
/* the next argument might have no spaces between the register and the
* condition. */
Modified: trunk/src/inter_create.c
==
--- trunk/src/inter_create.c(original)
+++ trunk/src/inter_create.cMon Oct 29 05:59:52 2007
@@ -135,7 +135,7 @@
create_initial_context(interp);
interp-resume_flag = RESUME_INITIAL;
/* main is called as a Sub too - this will get depth 0 then */
-CONTEXT(interp-ctx)-recursion_depth = -1;
+CONTEXT(interp-ctx)-recursion_depth = (UINTVAL)-1;
interp-recursion_limit = RECURSION_LIMIT;
Does casting -1 to unint make any sense? It looks here like if
recursion depth has a negative number then something has gone wrong
(in which case I don't know why it was declared unsigned int to begin
with). I've seen these errors/warnings for a while and wondered
whether or not to make the cast, but I believe there is a deeper
problem. Why are we wanting to assign -1 to recursion_depth to start
with? This is also the case where the variable 'c' is set to -1
above. 'c' is ostensibly a character, so why is it being set to -1?
I agree with getting rid of the warnings (there many others which need
attention) but I think we should get rid of them in the right way (and
yes, I do realise this is *me* the one who writes terrible C code
talking here ;-) ).
Paul
Re: [svn:parrot] r22585 - trunk/src
On 30/10/2007, jerry gay [EMAIL PROTECTED] wrote: On Oct 30, 2007 1:58 PM, Paul Cochrane [EMAIL PROTECTED] wrote: Modified: trunk/src/inter_create.c == --- trunk/src/inter_create.c(original) +++ trunk/src/inter_create.cMon Oct 29 05:59:52 2007 @@ -135,7 +135,7 @@ create_initial_context(interp); interp-resume_flag = RESUME_INITIAL; /* main is called as a Sub too - this will get depth 0 then */ -CONTEXT(interp-ctx)-recursion_depth = -1; +CONTEXT(interp-ctx)-recursion_depth = (UINTVAL)-1; interp-recursion_limit = RECURSION_LIMIT; Does casting -1 to unint make any sense? It looks here like if recursion depth has a negative number then something has gone wrong (in which case I don't know why it was declared unsigned int to begin with). I've seen these errors/warnings for a while and wondered whether or not to make the cast, but I believe there is a deeper problem. Why are we wanting to assign -1 to recursion_depth to start with? This is also the case where the variable 'c' is set to -1 above. 'c' is ostensibly a character, so why is it being set to -1? I agree with getting rid of the warnings (there many others which need attention) but I think we should get rid of them in the right way (and yes, I do realise this is *me* the one who writes terrible C code talking here ;-) ). recursion_depth is a UINTVAL, so it can't contain a negative number. -1, when assigned to a UINTVAL (which translates to unsigned long, at least on win32) becomes 4294967295. so, setting an unsigned thing to -1 is a C hack to set to it's maximum value, due to the way numbers are represented internally. since we have warnings turned way up on parrot source, we get a warning unless we cast the -1 to the proper type. this makes the -1 hack much less elegant looking, and more confusing. it's probably time to change all the 'foo = (type)-1' to 'foo = MAXTYPE' to reduce the magic number count in the source, and make the intent of the code more clear. I agree with this sentiment most definitely. Clarity is a Good Thing. Paul
[perl #41862] [CAGE] Make a reasonable set of rules for lint
On Thu Mar 15 19:42:17 2007, ptc wrote: Andy has a pretty decent set of rules for perl5's code in that project's Makefile. Take a look at those for a start. Andy Lester put a large chunk of effort into the options for both Sun lint and BSD lint. After adding some extra flags to BSD lint (r22544) I think we're definitely at the stage of having a reasonable set of rules for lint. Closing ticket.
Re: unallocated memory in string.c?
On 29/10/2007, Joshua Juran [EMAIL PROTECTED] wrote:
On Oct 28, 2007, at 8:28 AM, Klaas-Jan Stol wrote:
hi, when building parrot it reported a warning about some variable
string
in string.c
When checking out, I saw this:
static const char *
nonnull_encoding_name(STRING *s)
{
char *string;
if (!s)
strcpy(string, null string);
else
strcpy(string, s-encoding-name);
return string;
}
Can this be right?
No, it can't.
I thought that the first argument to strcpy needs to
point to some memory, but string (which really should be renamed
I think,
Shouldn't be a problem if you're not 'using namespace std;'. I use
'string' as a variable name in my C++ programs without ill effect.
as it might cause trouble when compiling it using a C++ compiler)
is not
even initialized.
You're quite right -- the listed code is bonkers. If you're lucky,
you'll get a segfault attempting to write to unmapped memory.
This was pointed out by leo++ on #parrot who then described a far more
elegant solution which was committed to the repo not long afterwards
in r22563.
Paul
[perl #41858] [CAGE] Make a reasonable set of rules for splint
On Sun Oct 21 13:25:50 2007, ptc wrote: On Thu Mar 15 19:12:48 2007, ptc wrote: splint spews many many errors by default. Take a look at the Makefile that perl5 has for the start of some rules that Andy worked on for the perl5 code. Andy Lester has done a very large amount of work on this, and a very good set of rules for splint now exists in the Parrot Makefile. Some are commented out and marked as being worthy of adding back in, dependent upon other things being finished. Does the set we have constitute a reasonable set? I.e. can we lay this ticket to rest? After looking into this a bit more, the set of options we have is definitely reasonable. Closing ticket.
[perl #46007] [CAGE] licensing cleanup
On Tue Oct 02 13:39:30 2007, [EMAIL PROTECTED] wrote: Parrot is no longer licensed under the GPL directly (though it is available under the GPL through the Artistic 2.0). Update or remove references to the GPL license in these files: debian/copyright:45 Removed mention of some no-longer-existing files in r22523. The other copyrights mentioned are: lib/Digest/Perl/MD5.pm: Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All rights reserved. lib/Pod/: Copyright (c) 2001-2002 Sean M. Burke. All rights reserved. These two will no longer be a problem when we get the external Perl modules removed from the repository and the bundling working correctly. languages/regex/lib/Regex/Grammar.pm: (c) Copyright 1998-2001 Francois Desarmenien, all rights reserved. This file is automatically generated. So what do we do with files in such cases? It is generated from Parse::Yapp, so can we just generate this file on demand rather than have it committed to the repository? compilers/imcc/imcc.y, compilers/imcc/main.c, compilers/imcc/ parser_util.c, languages/cola/: Copyright (C) 2002 Melvin Smith [EMAIL PROTECTED] Much of Melvin's stuff is co-licensed with The Perl Foundation, so can we safely assume that the copyright here can just be updated to Artistic 2.0? docs/faq.pod:159 There is only one mention of GPL here, and that is to tell people that we use the Artistic 2.0 license and that it's compatible with the GPL, so we don't need to worry about this file anymore. include/parrot/datatypes.h:4 Removed mention of the GPL in r22524. include/parrot/list.h:4 Removed mention of the GPL in r22525 src/datatypes.c:3 src/list.c:3 Removed mention of the GPL in r22526. Review these languages and decide whether to update the license or move them to the google-code repository for Parrot languages: languages/lazy-k/calc.lazy:2 languages/lazy-k/README:21 I don't know what to do with this language. It's not been updated in a while. Should we move it to google-code or should it be deleted? languages/urm/examples/biggerzero.urm:3 languages/urm/examples/distance.urm:3 languages/urm/examples/div.urm:3 languages/urm/examples/mult.urm:3 languages/urm/examples/sim.urm:3 languages/urm/examples/sub.urm:3 languages/urm/README:137 languages/urm/t/syn.t:13 languages/urm/urmc:11 This language is all GPLd, so maybe a good canditate for being moved to google-code. Or perhaps we could ask the author if we can license it under Artistic 2.0? Opinions? If you got this far through this message, thanks! :-) Paul
Re: [perl #46939] [PATCH] Added PCCMETHOD dependencies to Makefile
On 27/10/2007, chromatic [EMAIL PROTECTED] wrote: On Friday 26 October 2007 15:03:12 Paul Cochrane wrote: The attached patch adds dependencies to lib/Parrot/Pmc2c/PCCMETHOD.pm if the .pmc uses PCCMETHODs. This should also then allow the t/codingstd/pccmethod_deps.t test to pass. +1 Patch applied in r22509.
Re: [perl #46823] [TODO] [Pir] Rewrite ResizeablePMCArray tests properly when exceptions are implemented
On 25/10/2007, Allison Randal [EMAIL PROTECTED] wrote: Paul Cochrane wrote: I updated the subject of this ticket to substitute PMC with * as this issue occurs more often than I first guessed (the problems one has when going through code serially...). This issue is actually more general and *any* ResizeablesomethingArray needs the exceptions-related tests updated when we have exceptions implemented. Could you explain more fully what the problem is? Since we're currently implementing the exceptions PDD, it would be helpful to know any edge cases that need to be fixed. To be totally honest I wish I knew. I'm just going through converting the todo items in code into RT tickets and sometimes the todo comments aren't necessarily all that clear as to what needs to be done. I'm also (unfortunately) not familiar enough with pir to see in the code of the tests what needs fixing otherwise I might have been able to expand a little in the ticket. I'm really sorry I can't be of more help here! Paul
Re: [perl #46823] [TODO] [Pir] Rewrite ResizeablePMCArray tests properly when exceptions are implemented
On 24/10/2007, via RT Paul Cochrane [EMAIL PROTECTED] wrote: # New Ticket Created by Paul Cochrane # Please include the string: [perl #46823] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46823 In t/pmc/resizeablepmcarray.t there is the todo item: # TODO: Rewrite these properly when we have exceptions Which is to say that the tests of various error conditions and their output needs to be tested more thoroughly when exceptions are implemented. I updated the subject of this ticket to substitute PMC with * as this issue occurs more often than I first guessed (the problems one has when going through code serially...). This issue is actually more general and *any* ResizeablesomethingArray needs the exceptions-related tests updated when we have exceptions implemented.
Re: [perl #46727] [TODO] config/auto/ctags.pm: Write unit tests
On 23/10/2007, via RT James Keenan [EMAIL PROTECTED] wrote: # New Ticket Created by James Keenan # Please include the string: [perl #46727] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46727 auto::ctags was prepared by ptc and we committed it to trunk over the weekend. For the sake of completeness, I'm opening an RT to track unit tests for it as I did in June for the other configuration step classes. And speaking of which: I just posted this question with respect to config/auto/ attributes.pm, upon which auto/ctags.pm was modelled (I think). Actually I modelled auto/ctags.pm on auto/m4.pm... Why are we using $/ where a newline would suffice: [parrot] 507 $ grep -n '$/' config/auto/ctags.pm 43:print $/ if $verbose; ... but grabbed some elements from auto/attributes.pm. If this is wrong/bad style let me know why (I like to understand stuff) and fix the code as appropriate. Thanks for orgranising the tests on this! Paul
Re: [perl #43331] [TODO] config/init/optimize.pm: Write unit tests
On 23/10/2007, James Keenan via RT [EMAIL PROTECTED] wrote: Am reopening this ticket to pose this question, which I also posed in RT 44171: Why $/ where a newline would suffice: ./config//init/optimize.pm:41:print $/ if $verbose; Again, idiom copied from attributes.pm... If it's not right, blow it away. Paul
Re: [perl #44171] [TODO] config/auto/attributes.pm: Write unit tests
On 23/10/2007, James Keenan via RT [EMAIL PROTECTED] wrote: While examining this file for the purpose of writing tests, I noticed that it uses Perl's special variable $/ in 6 instances where a newline would suffice. [parrot] 504 $ grep -n '$/' config/auto/attributes.pm 54:print $/ if $verbose; 67:$verbose and print trying attribute '$attr'$/; 83:$verbose and print , $command_line, $/; 88:$verbose and print exit code: $exit_code$/; 95:$verbose and print output: $output$/; 100:$verbose and print ccflags: $ccflags$/; Why? i.e., Why we do we need this here when \n suffices everywhere else in the Parrot distribution? Just for completeness (I've already answered this question in other emails/tickets), this code was originally added by Andy Lester afaik, and I just copied the idiom into other test files. If there's no good reason to keep it then make it a newline. Paul
Re: [perl #38844] [TODO] Make lint, splint and tags targets
On 21/10/2007, Joshua Isom [EMAIL PROTECTED] wrote: On Oct 20, 2007, at 2:33 PM, Paul Cochrane via RT wrote: The ctags program is now detected at configuration time (this program sometimes has different names on different systems) and now 'make tags' should work out of the box for all the variations that I'm aware of (namely ctags, exuberant-ctags and ctags-exuberant). This is the situation as of r22321. If noone reports any other variants in the next three days then I'll close this ticket. Paul There's a catch on FreeBSD. There is a ctags included in the base distribution of FreeBSD but it doesn't support the arguments that exuberant ctags supports. You can go to http://www.FreeBSD.org/cgi/man.cgi? query=ctagsapropos=0sektion=0manpath=FreeBSD+6.2- RELEASEformat=html to read more about the one installed in the base system. But in ports, it's possible to install exuberant ctags but it's installed as exctags. The base ctags does work, but it just requires different calling. That's a similar gotcha to what happens on Gentoo Linux. ctags is the Emacs ctags, and exuberant ctags (which is the one required by the Parrot Makefile) is called exuberant-ctags. I'll add 'exctags' to the list of ctags name-variants to check for in the ctags step. Thanks for the info! :-) Paul
[perl #46595] [PATCH] a few spelling fixes
Patch applied in r22363. Thanks!
[perl #41886] [CAGE] Use lcov to show code coverage
On Mon Mar 19 09:54:26 2007, ptc wrote: On Sat Mar 17 14:19:51 2007, ptc wrote: The lcov tool from the Linux Test Project (http://ltp.sourceforge.net/coverage/lcov.readme.php) can be used to produce html output of code coverage information (I believe this looks similar to Devel::Cover's output). A 'make cover' target should be added to the Makefile and lcov should be run regularly over the parrot source to help guide the testing. A 'make cover' target has been in trunk for a while now. All that is required atm to close this ticket is proper integration with Devel::Cover so that the Perl-related components could be tested for coverage as well as the C-related components all from within the same make target. Paul
[perl #41858] [CAGE] Make a reasonable set of rules for splint
On Thu Mar 15 19:12:48 2007, ptc wrote: splint spews many many errors by default. Take a look at the Makefile that perl5 has for the start of some rules that Andy worked on for the perl5 code. Andy Lester has done a very large amount of work on this, and a very good set of rules for splint now exists in the Parrot Makefile. Some are commented out and marked as being worthy of adding back in, dependent upon other things being finished. Does the set we have constitute a reasonable set? I.e. can we lay this ticket to rest? Paul
[perl #40392] [CAGE] convert Cinternal_exception to Creal_exception
The only files which still have this issue outstanding are[1]: src/jit/ppc/jit_emit.h src/jit/alpha/jit_emit.h src/jit/hppa/jit_emit.h src/jit/mips/jit_emit.h src/jit/sun4/jit_emit.h Attached are patches for these files as I am unable to test on these platforms (diff-ed agains r22293). I am fairly sure that they are correct and will do the Right Thing, but of course I'm not 100% sure and don't want to step on anyone's toes just by committing the change. Could some other eyes please look over these patches to confirm that they're ok, and then we can see if we can close this ticket. Paul [1] If one does ack -l internal_exception then one finds several more files, however these are the files in which internal_exception() could/ should be converted to real_exception(). mips_jit_emit.patch Description: Binary data hppa_jit_emit.patch Description: Binary data ppc_jit_emit.patch Description: Binary data alpha_jit_emit.patch Description: Binary data sun4_jit_emit.patch Description: Binary data
[perl #38844] [TODO] Make lint, splint and tags targets
On Tue Jul 10 05:08:19 2007, ptc wrote: Just updating this ticket to the current state of play: The lint target needs to be renamed to splint. Actually, this has been changed to sunlint and bsdlint. The splint target has existed for a while (in two forms; now combined as of r19721 into the one target). Then create a new lint target to support Sun Studio. Done. And update the tags target. Still in need of work. The ctags program is now detected at configuration time (this program sometimes has different names on different systems) and now 'make tags' should work out of the box for all the variations that I'm aware of (namely ctags, exuberant-ctags and ctags-exuberant). This is the situation as of r22321. If noone reports any other variants in the next three days then I'll close this ticket. Paul
Re: [perl #43661] [CAGE] Get parrot configuration to autodiscover gcc warning flags
On 15/10/2007, James E Keenan [EMAIL PROTECTED] wrote: Paul Cochrane via RT wrote: On Sun Jul 08 15:09:19 2007, ptc wrote: At present we have to specify warnings flags for each version of gcc (see config/auto/gcc.pm). This is a pain. Perl 5 is able to work out automatically the warnings flags of gcc and then use those for compilation. Parrot should do this too. Automatic detection of gcc warnings has been implemented for a while now, just not switched on by default. The code is in config/auto/ warnings.pm and I added it to trunk in r21522. This greatly reduces the burden on warnings flag maintenance. Anyway, I'd like the code to be on by default and to rip the old stuff out. Can I? Huh? Huh? Please? Paul ptc, Thanks for being persistent with this. I have a few questions: 1. Where would it be placed in the list of configuration steps found in lib/Parrot/Configure/Step/List.pm? Just after the attribute sniffing code, i.e. add an entry auto::warnings just after auto::attributes. 2. In http://rt.perl.org/rt3/Ticket/Display.html?id=46373, I propose a change in Parrot::Configure::Step::Base which affects the individual configuration step classes. Can we adapt this class for that as well? Plan is for this patch also to be applied after the release. I believe that is already implemented in auto::warnings.pm 3. Can you supply at least a skeleton of a test file for this step? (See tests for other 'auto' steps in the reconfigure/ branch; these will soon be ported to trunk.) I'm going to keep playing with the test I've written so far and try and get it working properly. This way I'll learn a bit more, and be able to add a test for the attribute sniffing code as well. 4. Can you answer the question I posed in my July 8 response to your original post? Ok. Just managed to get some tuits, so am working through stuff now. Paul
Re: [perl #43661] [CAGE] Get parrot configuration to autodiscover gcc warning flags
4. Can you answer the question I posed in my July 8 response to your original post? I can't find anything relevant on July the 8th, although there was an email on Sep the 8th... Is there a ticket number or another pointer you can give me? Thanks! Paul
Re: [perl #39824] [CAGE] tools/dev/check_source_standards.pl -- this should be a test
Hi all, there is now a test in t/codingstds called filenames.t which encapsulates the discussion here. Is this sufficient to now close this ticket and to remove the old check_source_standards.pl program? Paul
[perl #43661] [CAGE] Get parrot configuration to autodiscover gcc warning flags
James, Thanks for pointing out what you meant. I think I must have been having a bit of a brain-fade moment or something... On Sun Jul 08 18:06:03 2007, [EMAIL PROTECTED] wrote: Paul Cochrane wrote: Perl 5 is able to work out automatically the warnings flags of gcc and then use those for compilation. Can you supply a link to the Perl 5 source that does this? The short answer here is no. Unfortunately I can't, and I sort of expected that Andy Lester would have done this since he raised the issue initially. However, now that we've got this functionality in Parrot's configuration, do we really need to worry how Perl 5 did/does it? Paul
[perl #38969] [CAGE] parrot source does not conform to standards
http://rt.perl.org/rt3/Ticket/Display.html?id=39824 Since the above ticket has now been resolved, does this mean that this ticket can also be resolved? Paul
Re: [perl #39824] [CAGE] tools/dev/check_source_standards.pl -- this should be a test
Oops, I forgot to attach the test... On 16/10/2007, Paul Cochrane [EMAIL PROTECTED] wrote: On 15/10/2007, Bernhard Schmalhofer [EMAIL PROTECTED] wrote: Paul Cochrane via RT schrieb: On Fri Nov 17 14:17:18 2006, particle wrote: ~ all but one test have been adapted for and moved to t/codingstd/ ~ remaining test is for not-yet-approved codingstd item The remaining test complains about more than one '.' in a filename and filenames which don't conform to the 8.3 format. I have talked to some VMS people at YAPC::EU 2007. For them the more than one '.' issue was a real problem, that they had to work around before even creating a Makefile. Attached is a test for multiple dot filenames. We have several such files in the source[1], so I don't know how useful such a test is, and whether or not it is worth changing the files around. I could handle having a restriction on the number of dots in filenames but I don't think we would be able to handle an 8.3 filename format restriction. Anyway, a decision would be good about this, then I can clean up and close a couple of annoying tickets. Paul [1] Failed files: 1..1 not ok 1 - No multi-dot filenames # Failed test (t/codingstd/multi_dot.t at line 57) # Multi-dot filename found in 77 files: # README.win32.pod # apps/p3/parrot.small.png # config/gen/makefiles/parrot.pc.in # docs/resources/parrot.small.png # editor/pir.vim.in # examples/shootout/ack.pir.output # examples/shootout/binarytrees.pir.output # examples/shootout/fannkuch.pir.output # examples/shootout/fasta.pir.output # examples/shootout/knucleotide.pir.input # examples/shootout/knucleotide.pir.output # examples/shootout/mandelbrot.pir.output # examples/shootout/nbody.pir.output # examples/shootout/nsieve-bits-2.pir.output # examples/shootout/nsieve-bits.pir.output # examples/shootout/nsieve.pir.output # examples/shootout/partialsums-2.pir.output # examples/shootout/partialsums.pir.output # examples/shootout/pidigits.pir.output # examples/shootout/recursive-2.pir.output # examples/shootout/recursive.pir.output # examples/shootout/regexdna.pir.input # examples/shootout/regexdna.pir.output # examples/shootout/revcomp.pir.input # examples/shootout/revcomp.pir.output # examples/shootout/spectralnorm.pir.output # examples/shootout/sumcol.pir.input # examples/shootout/sumcol.pir.output # examples/shootout/takfp.pir.output # languages/LANGUAGES.STATUS.pod # languages/dotnet/config/N2PConfig.pm.in # languages/lua/t/shootout/binarytrees.lua-3.lua # languages/lua/t/shootout/fannkuch.lua-3.lua # languages/lua/t/shootout/fasta.lua-2.lua # languages/lua/t/shootout/knucleotide.lua-2.lua # languages/lua/t/shootout/mandelbrot.lua-2.lua # languages/lua/t/shootout/message.lua-2.lua # languages/lua/t/shootout/nbody.lua-2.lua # languages/lua/t/shootout/nsieve.lua-3.lua # languages/lua/t/shootout/partialsums.lua-3.lua # languages/lua/t/shootout/pidigits.lua-2.lua # languages/lua/t/shootout/regexdna.lua-3.lua # languages/lua/t/shootout/revcomp.lua-3.lua # languages/lua/t/shootout/spectralnorm.lua-3.lua # languages/plumhead/lex.yy.c # languages/plumhead/y.tab.c # languages/plumhead/y.tab.h # t/TESTS.STATUS.pod # t/configure/101-init_manifest.01.t # t/configure/101-init_manifest.02.t # t/configure/102-init_defaults.01.t # t/configure/102-init_defaults.02.t # t/configure/103-init_install.01.t # t/configure/103-init_install.02.t # t/configure/105-init_hints.01.t # t/configure/105-init_hints.02.t # t/configure/105-init_hints.03.t # t/configure/105-init_hints.04.t # t/configure/107-inter_progs.01.t # t/configure/107-inter_progs.02.t # t/configure/107-inter_progs.03.t # t/configure/107-inter_progs.04.t # t/configure/109-inter_lex.01.t # t/configure/109-inter_lex.02.t # t/configure/109-inter_lex.03.t # t/configure/109-inter_lex.04.t # t/configure/109-inter_lex.05.t # t/configure/110-inter_yacc.01.t # t/configure/110-inter_yacc.02.t # t/configure/110-inter_yacc.03.t # t/configure/110-inter_yacc.04.t # t/configure/110-inter_yacc.05.t # t/configure/113-init_optimize.01.t # t/configure/113-init_optimize.02.t # t/configure/113-init_optimize.03.t # t/configure/113-init_optimize.04.t # t/tools/pmc2cutils/08-pmc.pm.t # Looks like you failed 1 test of 1.
Re: [perl #39824] [CAGE] tools/dev/check_source_standards.pl -- this should be a test
On 15/10/2007, Bernhard Schmalhofer [EMAIL PROTECTED] wrote: Paul Cochrane via RT schrieb: On Fri Nov 17 14:17:18 2006, particle wrote: ~ all but one test have been adapted for and moved to t/codingstd/ ~ remaining test is for not-yet-approved codingstd item The remaining test complains about more than one '.' in a filename and filenames which don't conform to the 8.3 format. I have talked to some VMS people at YAPC::EU 2007. For them the more than one '.' issue was a real problem, that they had to work around before even creating a Makefile. Attached is a test for multiple dot filenames. We have several such files in the source[1], so I don't know how useful such a test is, and whether or not it is worth changing the files around. I could handle having a restriction on the number of dots in filenames but I don't think we would be able to handle an 8.3 filename format restriction. Anyway, a decision would be good about this, then I can clean up and close a couple of annoying tickets. Paul [1] Failed files: 1..1 not ok 1 - No multi-dot filenames # Failed test (t/codingstd/multi_dot.t at line 57) # Multi-dot filename found in 77 files: # README.win32.pod # apps/p3/parrot.small.png # config/gen/makefiles/parrot.pc.in # docs/resources/parrot.small.png # editor/pir.vim.in # examples/shootout/ack.pir.output # examples/shootout/binarytrees.pir.output # examples/shootout/fannkuch.pir.output # examples/shootout/fasta.pir.output # examples/shootout/knucleotide.pir.input # examples/shootout/knucleotide.pir.output # examples/shootout/mandelbrot.pir.output # examples/shootout/nbody.pir.output # examples/shootout/nsieve-bits-2.pir.output # examples/shootout/nsieve-bits.pir.output # examples/shootout/nsieve.pir.output # examples/shootout/partialsums-2.pir.output # examples/shootout/partialsums.pir.output # examples/shootout/pidigits.pir.output # examples/shootout/recursive-2.pir.output # examples/shootout/recursive.pir.output # examples/shootout/regexdna.pir.input # examples/shootout/regexdna.pir.output # examples/shootout/revcomp.pir.input # examples/shootout/revcomp.pir.output # examples/shootout/spectralnorm.pir.output # examples/shootout/sumcol.pir.input # examples/shootout/sumcol.pir.output # examples/shootout/takfp.pir.output # languages/LANGUAGES.STATUS.pod # languages/dotnet/config/N2PConfig.pm.in # languages/lua/t/shootout/binarytrees.lua-3.lua # languages/lua/t/shootout/fannkuch.lua-3.lua # languages/lua/t/shootout/fasta.lua-2.lua # languages/lua/t/shootout/knucleotide.lua-2.lua # languages/lua/t/shootout/mandelbrot.lua-2.lua # languages/lua/t/shootout/message.lua-2.lua # languages/lua/t/shootout/nbody.lua-2.lua # languages/lua/t/shootout/nsieve.lua-3.lua # languages/lua/t/shootout/partialsums.lua-3.lua # languages/lua/t/shootout/pidigits.lua-2.lua # languages/lua/t/shootout/regexdna.lua-3.lua # languages/lua/t/shootout/revcomp.lua-3.lua # languages/lua/t/shootout/spectralnorm.lua-3.lua # languages/plumhead/lex.yy.c # languages/plumhead/y.tab.c # languages/plumhead/y.tab.h # t/TESTS.STATUS.pod # t/configure/101-init_manifest.01.t # t/configure/101-init_manifest.02.t # t/configure/102-init_defaults.01.t # t/configure/102-init_defaults.02.t # t/configure/103-init_install.01.t # t/configure/103-init_install.02.t # t/configure/105-init_hints.01.t # t/configure/105-init_hints.02.t # t/configure/105-init_hints.03.t # t/configure/105-init_hints.04.t # t/configure/107-inter_progs.01.t # t/configure/107-inter_progs.02.t # t/configure/107-inter_progs.03.t # t/configure/107-inter_progs.04.t # t/configure/109-inter_lex.01.t # t/configure/109-inter_lex.02.t # t/configure/109-inter_lex.03.t # t/configure/109-inter_lex.04.t # t/configure/109-inter_lex.05.t # t/configure/110-inter_yacc.01.t # t/configure/110-inter_yacc.02.t # t/configure/110-inter_yacc.03.t # t/configure/110-inter_yacc.04.t # t/configure/110-inter_yacc.05.t # t/configure/113-init_optimize.01.t # t/configure/113-init_optimize.02.t # t/configure/113-init_optimize.03.t # t/configure/113-init_optimize.04.t # t/tools/pmc2cutils/08-pmc.pm.t # Looks like you failed 1 test of 1.
Re: [perl #39824] [CAGE] tools/dev/check_source_standards.pl -- this should be a test
On 16/10/2007, jerry gay [EMAIL PROTECTED] wrote: On 10/16/07, Paul Cochrane [EMAIL PROTECTED] wrote: On 15/10/2007, Bernhard Schmalhofer [EMAIL PROTECTED] wrote: Paul Cochrane via RT schrieb: On Fri Nov 17 14:17:18 2006, particle wrote: ~ all but one test have been adapted for and moved to t/codingstd/ ~ remaining test is for not-yet-approved codingstd item The remaining test complains about more than one '.' in a filename and filenames which don't conform to the 8.3 format. I have talked to some VMS people at YAPC::EU 2007. For them the more than one '.' issue was a real problem, that they had to work around before even creating a Makefile. Attached is a test for multiple dot filenames. We have several such files in the source[1], so I don't know how useful such a test is, and whether or not it is worth changing the files around. I could handle having a restriction on the number of dots in filenames but I don't think we would be able to handle an 8.3 filename format restriction. Anyway, a decision would be good about this, then I can clean up and close a couple of annoying tickets. what we need to do more generally is verify that parrot is buildable and installable on our target operating systems. citing the PDD01 draft: =head2 Target Platforms The ultimate goal of Parrot is portability to more-or-less the same platforms as Perl 5, including AIX, BeOS, BSD/OS, Cygwin, Darwin, Debian, DG/UX, DragonFlyBSD, Embedix, EPOC, FreeBSD, Gentoo, HP-UX, IRIX, Linux, Mac OS (Classic), Mac OS X, Mandriva, Minix, MS-DOS, NetBSD, NetWare, NonStop-UX, OpenBSD, OS/2, Plan 9, Red Hat, RISC OS, Slackware, Solaris, SuSE, Syllable, Symbian, TiVo (Linux), Tru64, Ubuntu, VMS, VOS, WinCE, Windows 95/98/Me/NT/2000/XP/Vista, and z/OS. Recognizing the fact that ports depend on volunteer labor, the minimum requirements for the 1.0 launch of Parrot are portability to major versions of Linux, BSD, Mac OS X, and Windows released within 2 years prior to the 1.0 release. As we approach the 1.0 release we will actively seek porters for as many other platforms as possible. i'd be quite satisfied with a test that verifies that the minimum filename requirements are met for the list of currently targeted operating systems, accompanied by a note in the test (and either a TODO ticket or an item in the porters guide) that this test must be modified and satisfied to address the requirements of all supported platforms. Ok, the currently targeted platforms (as given in PLATFORMS) are: - Darwin - Linux (various flavours) - OpenBSD - FreeBSD (not actually mentioned, but I've seen mention of it working recently) - Solaris (versions 8--10) - OpenSolaris (basically Solaris10) - Tru64 (I don't know anyone with access to such a machine atm) - Win32 (XP, 2000; cygwin; mingw) (what have I forgotten here?) The minimum requirements for filenames should be: - Any character in the set: a-zA-Z0-9,.-_ - Should we make a rule about multiple dots? - Should there be a maximum length? 1024 chars? 100 chars? 12 chars? I'm sure to have missed something here. I'm just trying to get a feel for what our boundaries are so that they can be codified into a test. Paul
[perl #43661] [CAGE] Get parrot configuration to autodiscover gcc warning flags
On Sun Jul 08 15:09:19 2007, ptc wrote: At present we have to specify warnings flags for each version of gcc (see config/auto/gcc.pm). This is a pain. Perl 5 is able to work out automatically the warnings flags of gcc and then use those for compilation. Parrot should do this too. Automatic detection of gcc warnings has been implemented for a while now, just not switched on by default. The code is in config/auto/ warnings.pm and I added it to trunk in r21522. This greatly reduces the burden on warnings flag maintenance. Anyway, I'd like the code to be on by default and to rip the old stuff out. Can I? Huh? Huh? Please? Paul
[perl #39824] [CAGE] tools/dev/check_source_standards.pl -- this should be a test
On Fri Nov 17 14:17:18 2006, particle wrote: ~ all but one test have been adapted for and moved to t/codingstd/ ~ remaining test is for not-yet-approved codingstd item The remaining test complains about more than one '.' in a filename and filenames which don't conform to the 8.3 format. My feeling is that these should be guidelines but are not strict enough for a test. What are people's feelings? Allison: do you wish to make a decision about this particular coding standard item? Anyway, can this file (check_source_standards.pl) be removed and this ticket closed? Paul
[perl #39760] [CAGE] make warnings (r13197 - x86-msvc-7.1)
On Sat Jul 15 14:47:48 2006, rblasch wrote: Jerry Gay (via RT) wrote: # New Ticket Created by Jerry Gay # Please include the string: [perl #39760] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39760 compilers\ast\astparser.c astparser.c compilers\ast\astparser.c(1298) : warning C4102: 'yyerrlab1' : unreferenced label compilers/ast/astparser.c is generated by GNU Bison 1.875. I have GNU Bison 2.1 installed, which generates code that doesn't yield any warning. bison -v -y compilers\ast\ast.y -d -o compilers\ast\astparser.c -p AST C:\Perl\bin\perl.exe -MExtUtils::Command -e touch compilers\ast\ast.y.flag compilers\ast\astparser.c compilers\ast\astparser.h bison -v -y compilers\ast\ast.y -d -o compilers\ast\astparser.c -p AST C:\Perl\bin\perl.exe -MExtUtils::Command -e touch compilers\ast\ast.y.flag compilers\ast\astparser.c compilers\ast\astparser.h compilers\ast\astparser.c astparser.c Is that sufficient to close this issue, or should I provide a patch to disable the C4102 warning? Is this ticket still relevant? Are we still seeing these warnings with msvc? Paul
[perl #46223] [PATCH] Remove dead code in src/pmc/pair.pmc (Coverity CID 5)
On Mon Oct 08 12:14:07 2007, leo wrote: Am Montag, 8. Oktober 2007 19:05 schrieb Paul Cochrane: So, the patch is right (however, for my wrong reasoning)? Is everyone happy if I apply it then? $ svn ann src/pmc/pair.pmc 8374leo A Pair PMC represents one key = value mapping like a one element hash. I actually can't remember the reason for writing this one. But I think it was pugs/perl6 related some time ago, for some value of time ago. As this obvious bug never came up, this pmc looks likes very undertested or more precisely unused to me. I'd check the overall usage of this pmc and estimate the harm of removing it alltogether. That's a good idea. Is it ok to solve this issue first? I've got a better patch which retains the code's logic and has the added advantage that the compiler doesn't complain about missing return statements. Paul pair_pmc.patch Description: Binary data
