[perl #76828] Rakudo Star 'make' fails on Darwin/PPC

[James Keenan via RT]

On Fri Jul 30 17:58:48 2010, coke wrote:
> 
> Based on recent history, I think 1G is the minimum recommend memory
> for building rakudo
> (for that file in particular).
> 
> Someone should probably add this to the README.

Has the Rakudo project established minimum recommended memory
requirements for Rakudo*?

If so, and if they're above what I have available on this machine, then
I'll simply abandon my attempt to build Rakudo on this machine.  (Rakudo
might still build, of course, on Darwin/PPC machines with more memory.)

If memory requirements have not been established, then this ticket
should probably remain open.

Thank you very much.
Jim Keenan

[perl #76808] Searching for libraries under MacOS X

[James Keenan via RT]

Cf. these Parrot tickets, which appear to relate to the same problem:

http://trac.parrot.org/parrot/ticket/344

http://trac.parrot.org/parrot/ticket/1890

kid51

[perl #76828] Rakudo Star 'make' fails on Darwin/PPC

[James Keenan via RT]

Cf. also this ticket reported to Parrot's ticketing system:
http://trac.parrot.org/parrot/ticket/1804

[perl #77464] Rakudo Star: Trim down disk space once installed

[James Keenan via RT]

On Sat Aug 28 12:16:35 2010, pmichaud wrote:
> 
> 1.  Download the Rakudo Star tarball.
> 2.  Unpack the tarball.
> 3.  Run Configure.pl, passing the ultimate install dir to --prefix.
> Since you ultimately want to eliminate the install stuff, make 
> sure the install is somewhere outside of the tarball root:
> (I've used $HOME/install in the example below.)
> 4.  Run "make install".
> 
> $ tar xvfz rakudo-star-2010.08.tar.gz
> $ cd rakudo-star-2010.08
> $ perl Configure.pl --gen-parrot --prefix=$HOME/install
> $ make install
> 
> After the "make install" step, you should be able to remove the
> entire rakudo-star-2010.08 directory -- i.e., all the files needed
> to run Rakudo (and modules) are installed to the appropriate location 
> in the install/ directory.
> 

Patrick,

Thank you very much.  That DWIMmed exactly and got my disk usage down
from >95% to 84%.

> ...removing the rakudo/ directory also removes its tests.  AIUI,
> normally tests aren't installed along with an application;
> they tend to remain with the source files.
> 

Correct.  What I decided to do was to run 'make rakudo-test' as a sanity
check prior to 'make install'.  I then removed the entire
rakudo-star-2010.08/ directory.

Thanks again.

kid51

[perl #77464] Rakudo Star: Trim down disk space once installed

[James Keenan via RT]

On Fri Aug 27 10:16:43 2010, coke wrote:
> On Fri, Aug 27, 2010 at 9:52 AM, Patrick R. Michaud
> >
> > Perhaps a "make clean" target would be sufficient here?
> >

Great minds think alike ;-) !  A 'make' target crossed my mind while
unable to sleep last night.

> 
> I don't think so. that'll still leave the source around, which it
> sounds like Jim doesn't want.
> 

... but I guess great minds don't always think correctly  :-( .  Coke is
correct in thinking that under my top level I don't want either Parrot
or Perl 6 source; I want just what I need to run Perl 6.  (I can -- and
do -- hack on Parrot source elsewhere on the same machine.  And at this
point I want to *learn* and *use* Perl 6, not hack on it.)

Thanks for continuing to look into this.

[perl #77464] Rakudo Star: Trim down disk space once installed

[James Keenan via RT]

Let me describe my first naïve attempt at dealing with this problem. 
Looking at my top-level directory:

> [rakudo-star-2010.08] 502 $ ll
> total 14452
> -rw-r--r--  1 jimk jimk 6633 Aug 25 09:17 Configure.pl
> -rw-r--r--  1 jimk jimk 8902 Aug 25 09:17 LICENSE
> -rw-r--r--  1 jimk jimk   103652 Aug 26 08:45 MANIFEST
> -rw-r--r--  1 jimk jimk 6309 Aug 26 18:47 Makefile
> -rw-r--r--  1 jimk jimk 6607 Aug 25 13:37 README
> drwxr-xr-x  2 jimk jimk 1024 Aug 26 18:43 build
> drwxr-xr-x  3 jimk jimk 1024 Aug 26 18:43 docs
> drwxr-xr-x  8 jimk jimk 1024 Aug 26 18:57 install
> drwxr-xr-x 22 jimk jimk 1024 Aug 26 18:43 modules
> drwxr-xr-x 15 jimk jimk 2048 Aug 26 18:47 parrot-2.7.0
> -rwxr-xr-x  1 jimk jimk 14596343 Aug 26 18:57 perl6
> drwxr-xr-x  8 jimk jimk 1024 Aug 26 18:56 rakudo
> 

... I see 4 plain-text files, 6 directories and 1 perl6 executable. 
Inspection of build/, docs/ and modules/ suggests that (a) the size of
their files is small, or (b) that's where useful libraries live.  Which
leaves the parrot-2.7.0/ and rakudo/ directories as places to trim.

Acting on the belief that "what I really need is install/", I tried
moving the rakudo/ directory out of the way.  But when I then re-ran
'make rakudo-test', I got:

[rakudo-star-2010.08] 514 $ make rakudo-test
cd rakudo && /usr/local/bin/perl Configure.pl
--parrot-config=/home/jimk/work/rstar/rakudo-star-2010.08/install/bin/parrot_config
&& make
/bin/sh: line 0: cd: rakudo: No such file or directory
make: *** [rakudo/perl6] Error 1

Which was not encouraging.  But, then again, I'm just stumbling around here.

kid51

[perl #76828] Rakudo Star 'make' fails on Darwin/PPC

[James Keenan via RT]

On Fri Jul 30 06:20:30 2010, coke wrote:

> 
> How much memory do you have in the box (physical), ...


>From 'top':

PhysMem:  46.3M wired,  137M active, 68.7M inactive,  252M used, 3.68M free

>From System Profiler:  Memory: 256 MB


> and do you have a ulimit set?

Apparently not:

$ ulimit -a 
core file size(blocks, -c) 0
data seg size (kbytes, -d) 6144
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size   (kbytes, -m) unlimited
open files(-n) 256
pipe size  (512 bytes, -p) 1
stack size(kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes(-u) 100
virtual memory(kbytes, -v) unlimited

kid51

[perl #58990] [TODO] Design new spec coverage mechanism

[James Keenan via RT]

On Tue Sep 22 10:39:17 2009, fperrad wrote:
> >
> 
> FYI, some existing tools (but not Perl)
> - FIT : http://fit.c2.com/
> - FitNesse & Slim : http://fitnesse.org/
> 
François,

Thanks for the reference.  If someone wants to examine these links and
open a TT, they are welcome to do so.

In the meantime, resolving this ticket.

[perl #58740] [CAGE] t/configure/*.t and t/steps/*.t: Cleanup test setup/teardown code

[James Keenan via RT]

On Mon Sep 21 15:28:01 2009, jk...@verizon.net wrote:
> 
> So, unless there is some strong objection, I will close this ticket
> within 7 days.
> 

No one spoke up for this; rejecting ticket.

[perl #41500] [TODO] config - lib directory needs to be set appropriately for 32/64 bit archs

[James Keenan via RT]

This ticket has been open for more than two-and-a-half years -- solely
on the basis of an ancient inline comment.  In that time no one has
produced any evidence that we are doing the wrong thing.  Given how many
of our developers are currently working on AMD64, I would have expected
that by now some evidence of doing the wrong thing would have emerged.

I am therefore taking this ticket, removing the inline comment from
config/init/defaults.pm and resolving the ticket.  Wayland, if you get
around to testing the install paths on 64-bit and we're doing the wrong
thing, please open up a Trac ticket with full details.

Thank you very much.
kid51

[perl #53104] [BUG] dyld: lazy symbol binding failed: Symbol not found: _parrot_i386_cmpxchg (icu?)

[James Keenan via RT]

On Wed Sep 16 05:49:12 2009, cognominal wrote:
> the report is not relevant anymore. you can close the ticket. Thx
> 

Closing.

[perl #60048] [BUG] [MMD] CGP Does Not Work with PCC Runcore Reentry

[James Keenan via RT]

On Wed Feb 25 16:08:29 2009, jk...@verizon.net wrote:
> On Thu Jan 29 06:15:28 2009, Whiteknight wrote:
> > 
> > has the remove_pic branch landed yet? 
> 
> 
> Well, it's still an active branch in SVN.  So I would guess not.

Per discussion on the mailing list, we're removing the remove_pic branch
(r41287).   Whiteknight already has this ticket.

kid51

[perl #60312] [BUG] OpenBSD Smolder test failures

[James Keenan via RT]

On Tue May 12 05:18:47 2009, jk...@verizon.net wrote:
> Here's an update based on a recent Smolder report
> 

Thanks to a steady stream of Smolder reports from 'sm...@pc42.my.domain'
-- I don't know who the human there is -- performed on OpenBSD/amd64, we
can see that we are passing all non-SKIPped tests in the 4 files cited.  
Example: 
http://smolder.plusthree.com/app/public_projects/report_details/25466

So I'm resolving this ticket.  Thank you very much.

kid51

[perl #47966] [DOCS] pdd23 doesn't list exception;death as a standard exception

[James Keenan via RT]

On Sun Jul 19 18:27:29 2009, tene wrote:
> Parrot still doesn't have a hierarchy of exception types. 
> exception;death doesn't exist.  This is the same as rt#36261.  I
> recommend that both of these tickets be merged into a single TT.

At Tene's suggestion, I am consolidating this ticket with one another
and moving them to Trac:  https://trac.parrot.org/parrot/ticket/858

Please continue the discussion there.  Thank you very much.

kid51

[perl #36261] [TODO] HLL exception handling

[James Keenan via RT]

On Sun Jul 19 18:22:00 2009, tene wrote:
> This still hasn't been done.  I've been thinking about this again
> recently, and I'll try to move it higher in my TODO list.  I have a lot
> of exceptions cleanups that I still need to document and/or do.


At Tene's suggestion, I am consolidating this ticket with one another
and moving them to Trac:  https://trac.parrot.org/parrot/ticket/858

Please continue the discussion there.  Thank you very much.

kid51

[perl #47966] [DOCS] pdd23 doesn't list exception;death as a standard exception

[James Keenan via RT]

On Mon Dec 01 11:39:33 2008, pmichaud wrote:
> 
> ... how exactly does one use C, C,
> and the other exception types from PIR?  I see them mentioned throughout
> pdd23, but I've never actually seen an example of how these constants
> (are they constants?) might appear in actual code, whether it's PIR, C, 
> or otherwise.
> 
> The only "types" I'm aware of for exceptions are the severity values
> and exception type values in include/parrot/exceptions.h and
> runtime/parrot/include/except_*.pasm, and none of these seem to have
> any real correspondence to the "exception types" given in pdd23.
> 

Patrick,

Are we still lacking the documentation on how to use these exception
types from PIR?

If so, I will transfer this discussion to a TT.  If not, can the ticket
be closed?

Thank you very much.
kid51

[perl #55504] [BUG] Failing test t/op/spawnw.t

[James Keenan via RT]

Although I cannot be sure that the issues which were cited in the
original post to this RT have been cleared up, I note that there has
been no follow-up discussion in eight months.

So I'm going to resolve this ticket and encourage any new LANG-related
failures to be reported in new tickets in our Trac system
(https://trac.parrot.org/parrot/newticket).

Thank you very much.
kid51

[perl #53538] [BUG] Parrot_floatval_time() and Parrot_intval_time() do not match up on Win32

[James Keenan via RT]

This ticket has been moved into the Trac system at
https://trac.parrot.org/parrot/ticket/857.

Please continue the discussion there.  Thank you very much.
kid51

[perl #42699] r18304 Test failures on NexentaOS (GNU/OpenSolaris)

[James Keenan via RT]

There's been a lot of water under the bridge since this test failure
report was originally filed.  So we would undoubtedly need new reports
to go forward.

I'm going to close this ticket and encourage people with access to
NexentaOS (GNU/OpenSolaris) to configure and build Parrot from HEAD and
to file a Smolder report via 'make smoldertest'.

Thank you very much.
kid51

[perl #42901] [RFC] [INSTALL] Solutions for the install target problems

[James Keenan via RT]

This ticket addressed a variety of issues why may or may not still be
apropos.  However, I suspect that the specific approach to
install-related problems suggested in the ticket will be superseded by
the work done on such issues in the last month.

Would it be possible to review this ticket and recommend which parts, if
any, should be moved to Trac?

Thank you very much.
kid51

[perl #43174] [TODO] Figure out why -libpath: needs to be removed from $linkflags and $ldflags (config/inter/progs.pm)

[James Keenan via RT]

This ticket has been moved into the Trac system: 
https://trac.parrot.org/parrot/ticket/854.  Please continue the
discussion there.

Thank you very much.
kid51

[perl #37258] [PATCH] loadlib and libraries with '.' in the name

[James Keenan via RT]

I have moved this ticket to the Trac system: 
https://trac.parrot.org/parrot/ticket/850.  Please continue discussion
there.

Thank you very much.
kid51

[perl #38146] [TODO] OS.pmc - file copy

[James Keenan via RT]

The discussion in this ticket appears to have petered out in June 2006.
  The state of any efforts to work on it is unclear.

This RT was mentioned by Whiteknight on his blog on July 17 2009:

"Likewise, Ticket #38146 discusses the creation of a file copying
utility, although discussion there has since degraded into a general
discussion about what's the best architecture to use for implementing
these kinds of functions. Input on that discussion, or a solution to the
problem, would both be appreciated (and moving the ticket from RT to
Trac where it can be even more visible would be a big plus!)"

Since there may be people who participated in this thread who are not
yet following Trac or parrot-dev, I'm posting this to the old list as
well.  Can anyone summarize where we stand?

Thank you very much.
kid51

[perl #43687] [TODO] combine abstract search with other search in lib/Parrot/Docs/File.pm

[James Keenan via RT]

No objections heard.  Resolving ticket.

[perl #43687] [TODO] combine abstract search with other search in lib/Parrot/Docs/File.pm

[James Keenan via RT]

On Sat May 09 19:40:51 2009, jk...@verizon.net wrote:

> 
> In the course of working on RT 43683, I came across the inline comment
> which was the pretext for creating this ticket in the first place.  It
> was not removed when the ticket was rejected.  And since I was doing
> some refactoring for the other ticket, I decided to deal with the issue
> in this ticket.
> 
> Please see patch attached.  I'll apply it after this month's release
> unless someone objects.

Patch applied in r38998.  Will close ticket in 2-3 days unless someone
objects.

Thank you very much.
kid51

[perl #43709] [TODO] Groups should only contain items or paths

[James Keenan via RT]

Rejected, and ticket resolved, in r38997.

kid51

[perl #43713] [TODO] Items should only contain paths

[James Keenan via RT]

Rejected, and ticket resolved, in r38996.

kid51

[perl #41912] [CAGE] survey tools/ dir for unused, old, or broken code, and remove or fix as necessary

[James Keenan via RT]

On Sun Mar 22 06:09:15 2009, jk...@verizon.net wrote:
> On Mon Mar 19 15:43:27 2007, particle wrote:
> > there's a number of scripts and utilities in the tools/ subtree which
> > i suspect have gone unused for some time now. this ticket is a
> > placeholder to track efforts on surveying and fixing the files under
> > tools/.
> > 

1.  I've been looking at this ticket on and off for two years.  We've
cleared out some programs that clearly were no longer needed.  I've
looked at the remaining programs and am somewhat satisfied that, with
exceptions noted below, the remaining programs are still either
essential or are useful to some Parrot developers somewhere.  So I'm
going to close this ticket, having transferred some remaining questions
to Trac tickets.

> 
> Jerry:
> 
> Do we have a rule as to which programs ought to be under 'tools/build/',
> which under 'tools/dev', and which under, say, 'tools/util/'?
> 
>

2.  I didn't get any response to this question, so I've transferred it
to https://trac.parrot.org/parrot/ticket/677 in the hope that it will
have greater visibility in Trac.

3.  The question I posed about the Valgrind suppression file
'parrot_8.supp' has been transferred to
https://trac.parrot.org/parrot/ticket/678.

Thank you very much.
kid51

[perl #60312] [BUG] OpenBSD Smolder test failures

[James Keenan via RT]

Here's an update based on a recent Smolder report
(http://smolder.plusthree.com/app/public_projects/report_details/21469);

veracity.t:  passing

arithmetics.t:
ok 7 - negate -0.0 # TODO -0.0 not implemented, TT #313 : still not passing
(Why is this showing up yellow rather than green on the Smolder report
if it is 'ok'?)

complex.t:
not ok 380 # TODO sinh of -2-3i
not ok 381 # TODO sinh of -2-3i

float.t:
not ok 23 - neg 0 # TODO -0.0 not implemented, TT #313

#   Failed (TODO) test 'neg 0'
#   at t/pmc/float.t line 512.
#   '0'
# doesn't match '/^-0/
# '

So I would say that only one of the six tests I originally flagged has
been clearly resolved.

[perl #40817] [TODO] track generated files during the configure/make process

[James Keenan via RT]

I've been staring at this ticket for more than a year.  One of my
earlier patches got us part of the way there.  Applying Reini's or
something like that would get us closer.

But the more I look at this problem in light of
https://trac.parrot.org/parrot/ticket/586,
https://trac.parrot.org/parrot/ticket/434 and
https://trac.parrot.org/parrot/ticket/426, the more I believe that the
problem is more complex than we at first thought.

That's because, taking MANIFEST and MANIFEST.generated together, we use
these files for *two* distinct purposes:

1.  Determining what files a developer or user needs to build Parrot
from source.
2.  Determining what files are installed by 'make install' or 'make
install-dev'.

Purpose #1 is fulfilled exclusively by MANIFEST.  Or, to be more
precise, by the *left-hand* column in MANIFEST.  In a MANIFEST entry
like this:

  compilers/imcc/cfg.c[imcc]

... only the left-hand part matters in terms of having the files one
needs for building from source.

Purpose #2, in contrast, requires both files to be fulfilled.  And it
requires *both* columns in each file to be fulfilled, because it's the
*right-hand* column that determines where a file is ultimately installed.

The patches we've applied or submitted so far automate, more or less
successfully, the identification of files *generated* by Configure.pl or
make.  But, AFAICT, so far it takes a human to determine where a file --
source or generated -- must be installed.  In other words, I don't see a
way to automate the assignment of data in the right-hand column.

Some data:

As of last night, a fresh checkout from trunk contains 2142 files.

After Configure.pl on Linux/i386, the total number of files in the build
dir has increased to 2229, an increase of 87.

After make, the total number of files has increased to 2999, an
additional increase of 770.

But if I then call 'make install', I install only 293 files.

What criteria do we have that those 293 files -- and only those 293 --
get installed?  We need to have such criteria if we're to have accurate
information in the right-hand columns of MANIFEST and
MANIFEST.generated.  Accurate information those files, in turn, is the
only way we can write tests to determine whether 'make install' and
'make install-dev' (and the programs underlying them) are doing the
right thing.

Thoughts?

Thank you very much.
kid51

[perl #46821] [RFC] should readonly be deep or shallow?

[James Keenan via RT]

See also discussion in https://trac.parrot.org/parrot/ticket/658.

[perl #43709] [TODO] Groups should only contain items or paths

[James Keenan via RT]

On Tue Jul 10 05:04:48 2007, pcoch wrote:
> In lib/Parrot/Docs/Group.pm there is the todo item:
> 
> # TODO - Groups should only contain items or paths.
> 
> This restriction needs to be implemented.


Why?  Can anyone say?

I doubt it, if only because I doubt that anyone understands the
Parrot::Docs::* packages at this point.

Until such time as we can commission a total rewrite of our docs-to-HTML
code, I think we can safely reject this ticket.

I will delete the comment and reject the ticket after next week's
release unless there is some objection.

Thank you very much.
kid51

[perl #43713] [TODO] Items should only contain paths

[James Keenan via RT]

On Tue Jul 10 05:13:07 2007, pcoch wrote:
> In the file lib/Parrot/Docs/Item.pm there is the todo item:
> 
> # TODO - Items should only contain paths
> 
> This restriction needs to be implemented.


Why?  Can anyone say?

I doubt it, if only because I doubt that anyone understands the
Parrot::Docs::* packages at this point.

Until such time as we can commission a total rewrite of our docs-to-HTML
code, I think we can safely reject this ticket.

I will delete the comment and reject the ticket after next week's
release unless there is some objection.

Thank you very much.
kid51

[perl #43687] [TODO] combine abstract search with other search in lib/Parrot/Docs/File.pm

[James Keenan via RT]

On Fri Apr 17 13:29:57 2009, cotto wrote:
> On Fri Apr 17 13:24:13 2009, julianalbo wrote:
> > > I propose rejecting this ticket as unnecessary.  The code may not be
> > > optimal, but it works fine and isn't even particularly hacky or
broken.
> > 
> > +1
> > 
> > 
> 
> rejected!

In the course of working on RT 43683, I came across the inline comment
which was the pretext for creating this ticket in the first place.  It
was not removed when the ticket was rejected.  And since I was doing
some refactoring for the other ticket, I decided to deal with the issue
in this ticket.

Please see patch attached.  I'll apply it after this month's release
unless someone objects.

Index: lib/Parrot/Docs/File.pm
===
--- lib/Parrot/Docs/File.pm	(revision 38663)
+++ lib/Parrot/Docs/File.pm	(working copy)
@@ -380,45 +380,20 @@
 return '' unless $self->contains_pod;
 
 my @lines = $self->read;
+my $firstline = shift @lines;
+return $self->title unless $firstline =~ /^=head1\s+ABSTRACT/;
 
-while (@lines) {
-my $line = shift @lines;
-
-if ( $line =~ /^=head1\s+ABSTRACT/o ) {
-while (@lines) {
-$line = shift @lines;
-
-last if $line =~ /\S/o;
-}
-
-my @abstract_text = $line;
-
-while (@lines) {
-$line = shift @lines;
-
-last if $line !~ /\S/o;
-
-push @abstract_text, $line;
-}
-
-my $desc = join ' ', @abstract_text;
-
-# Joining lines may have created a bit of extra whitespace.
-$desc =~ s/\s+/ /osg;
-$desc =~ s/^\s+//os;
-$desc =~ s/\s+$//os;
-
-# Remove any POD.
-$desc =~ s/[CFL]<([^>]+)>/$1/osg;
-
-return $desc;
-}
-}
-
-# RT#43687 - The abstract section above was added later. The two searches
-# could be combined.
-
-return $self->title;
+my $all_text = join "\n" => @lines;
+$all_text =~ s/^\s+//;
+my @paragraphs = split /\n{2,}/, $all_text;
+my $desc;
+# For a short description, we take only the first paragraph of any
+# ABSTRACT.
+($desc = $paragraphs[0]) =~ s/\n/ /g; 
+$desc =~ s/\s+/ /sg;
+# We eliminate certain POD formatting characters.
+$desc =~ s/[CFL]<([^>]+)>/$1/sg;
+return $desc;
 }
 
 =back

[perl #43683] [TODO] Remove the pod, or convert to html? (lib/Parrot/Docs/File.pm)

[James Keenan via RT]

On Fri Apr 17 13:27:36 2009, cotto wrote:

> 
> make html works fine, as far as I can tell.  Is there any reason why
> this ticket can't be rejected?

No.  Deleted those two comments in r38663.  Marking ticket rejected.

kid51

[perl #59978] [TODO] Add SVN revision number of reports to Smolder front page

[James Keenan via RT]

In r38498, applied patch supplied by Michael Peters.  See also: 
https://trac.parrot.org/parrot/wiki/SmolderTaskList.

[perl #41893] [BUG] 0.4.9 leaks various .c files into install image, creates PREFIX/config, PREFIX/compiler

[James Keenan via RT]

On Sun Mar 18 08:23:45 2007, codermattie wrote:
> Hello,
> 
> In the course of testing the parrot-0.4.9 release I discovered a
> number of files installed by the "reallyinstall" target that
> don't belong in an install image.
> 
> To understand the output Configure.pl was called with:
>   --prefix=/usr ,
> and make was invoked with:
>   DESTDIR="/var/tmp/portage/dev-lang/parrot-0.4.9/image/"
> 
> in the output everything up to "image/" can be ignored. it's just a
> temporary install location that is copied
> over to the real install tree later.
> 

Although we still have a 'destdir' option to tools/dev/install_files.pl,
we don't have a 'destdir' option to Configure.pl.  So I couldn't find a
way to feed something into $(DESTDIR) in the Makefile.  Instead, I
relied on the procedure I've been using in some Trac tickets:

  perl Configure.pl --prefix=/pseudoinstall


> /var/tmp/portage/dev-lang/parrot-0.4.9/image//usr/include/src
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/include/src/jit_emit.h
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/include/src/string_private_cstring.h
> 
> include/src is a strange place to drop header files. if jit_emit.h
> really needs to be installed
> then I think include/parrot , or even include/parrot/jit makes more
> sense.
> 

Neither jit_emit.h nor string_private_cstring.h appeared under
pseudoinstall/.

> /var/tmp/portage/dev-lang/parrot-0.4.9/image//usr/lib/pkgconfig
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/lib/pkgconfig/parrot.pc
> 
> I am not very familiar with pkgconfig. Are these really supposed to
> install ?
> 

This is still installed:

  ./lib/pkgconfig/parrot/1.1.0-devel/parrot.pc

But it is just packaging information:

prefix=/pseudoinstall
exec_prefix=/pseudoinstall
libdir=/pseudoinstall/lib
includedir=/pseudoinstall/include

Name: parrot
Description: virtual machine to execute bytecode for interpreted languages
Version: 1.1.0
Libs: -L${libdir} -lparrot -lpthread -lm -L/usr/lib  -licuuc -licudata
-lpthread
 -lm -lnsl -ldl -lm -lcrypt -lutil -lpthread -lgmp -lreadline
Cflags: -I${includedir}

> /var/tmp/portage/dev-lang/parrot-0.4.9/image//usr/src
> /var/tmp/portage/dev-lang/parrot-0.4.9/image//usr/src/ops
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/src/ops/core_ops_cgp.c
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/src/ops/core_ops_switch.c
> /var/tmp/portage/dev-lang/parrot-0.4.9/image//usr/src/nci.c
> /var/tmp/portage/dev-lang/parrot-0.4.9/image//usr/src/null_config.c
> /var/tmp/portage/dev-lang/parrot-0.4.9/image//usr/src/parrot_config.c
> 
> This looks like a accident, some random parrot source code installed
> in /usr/src

None of the above .c files could be located under pseudoinstall/

> 
> /var/tmp/portage/dev-lang/parrot-0.4.9/image//usr/compilers
> /var/tmp/portage/dev-lang/parrot-0.4.9/image//usr/compilers/imcc
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/compilers/imcc/imclexer.c
> 
> this is most likely an over-sight of some sort. compilers/ hanging off
> /usr ?
> 

imclexer.c not found under pseudoinstall/

> /var/tmp/portage/dev-lang/parrot-0.4.9/image//usr/config
> /var/tmp/portage/dev-lang/parrot-0.4.9/image//usr/config/gen
> /var/tmp/portage/dev-lang/parrot-0.4.9/image//usr/config/gen/cpu
> /var/tmp/portage/dev-lang/parrot-0.4.9/image//usr/config/gen/cpu/i386
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/config/gen/cpu/i386/memcpy_mmx.c
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/config/gen/cpu/i386/memcpy_sse.c
> /var/tmp/portage/dev-lang/parrot-0.4.9/image//usr/config/gen/platform
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/config/gen/platform/generic
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/config/gen/platform/generic/stat.c
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/config/gen/platform/ansi
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/config/gen/platform/ansi/dl.c
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/config/gen/platform/ansi/time.c
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/config/gen/platform/darwin
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/config/gen/platform/darwin/memalign.c
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/config/gen/platform/win32
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/config/gen/platform/win32/stat.c
> 
> another one, config/ hanging off /usr.

In fact, no '.c' files at all were found under pseudoinstall/.

So I think all the original poster's concerns have been addressed.  I am
re-closing the ticket.

Thank you very much.
kid51

[perl #52346] [TODO] avoid deprecated functions in config/gen/platform/darwin/dl.c

[James Keenan via RT]

On Fri May 01 13:16:13 2009, coke wrote:
> 
> What I meant was, I'll apply this in a few days (sometime this weekend) 
> UNLESS I hear back from other darwin developers with complaints.

I tried the suggested deletion.  It caused no problems for me on
Darwin/PPC.  So +1 on the change.

kid51

[perl #41893] [BUG] 0.4.9 leaks various .c files into install image, creates PREFIX/config, PREFIX/compiler

[James Keenan via RT]

The 'reallyinstall' target is gone, so we can resolve this ticket.

[perl #53976] [PATCH] Remove tools/dev/ops_renum.mak

[James Keenan via RT]

On Tue Apr 21 05:36:53 2009, bacek wrote:
> On Sun Aug 24 08:06:29 2008, jk...@verizon.net wrote:
> 
> There is no more tools/dev/ops_renum.mak. Can we close this ticket?
> 


The only reason I did not previously close it was Coke's expression of a
desire to pull this into the main Makefile.  But I'll let him open a TT
for that.  Marking ticket resolved.

bacek, thanks for poking on this.

kid51

[perl #41912] [CAGE] survey tools/ dir for unused, old, or broken code, and remove or fix as necessary

[James Keenan via RT]

On Sat Dec 27 20:56:38 2008, rgrjr wrote:
> 
> When updating an old working copy, I just happened to notice that
> "parrot-config" was deleted since June.  So was able to find this:
> 
> r28977 | chromatic | 2008-07-02 21:42:27 -0400 (Wed, 02 Jul 2008)
> | 2 lines
> 
> [parrot-config] Turned parrot-config into a fakecutable; this
> allows programs
> to query Parrot's configuration.  See RT #32365.
> 

Well, I have to admit I don't know what a fakecutable would be.  In any
event, my main concern right now is to see if someone deems this program
valuable enough to take it over and get it working.  Otherwise, per
Jerry's original post in this ticket, it should be deleted.

Thank you very much.
kid51

[perl #61044] [BUG] r33477 fails t/compilers/imcc/syn/macro.t on OS X

[James Keenan via RT]

Ovid:

I'm going to merge this RT into the one we already have open reporting
the same failure on Darwin/PPC.  I believe the problem occurred in
r33324.  I think chromatic is looking into this.

Thank you for your report.
kid51

[perl #55386] [TODO] Remove Configure.pl -miniparrot option

[James Keenan via RT]

On Wed Nov 26 13:18:57 2008, coke wrote:
> 
> 
> The only remaining instance in branch that I'm not sure how to resolve  
> is 
> 
> t/configure/034-step.t
> 
> Jim - if you could take a look at that usage of miniparrot and either 
> bless it or remove it, that'd be very helpful. (I can't tell if it's 
> referencing the executable or the config option.)
> 

It was just dummy copy.  The point of that particular test was to see if
genfile() caught the Perl error found in 'sprint' in the next line.  But
I changed it anyway so that grep wouldn't find it -- and added a test
for the captured error message while I was stopping by.

I was mistakenly working in trunk rather than branch today when I
updated 5 t/steps/*.t test files.  I then subsequently discovered that
you worked on those files yourself today in branch.  So you might get
some trivial conflicts when you do the merge.

Coverage analysis for configure and build tools in the rm_miniparrot
branch can be seen at
http://thenceforward.net/parrot/coverage/configure-build/coverage.html.

AFAICT you can do the merge back into trunk whenever you're ready. 
Thank you very much.

kid51

[perl #60068] [BUG] t/pmc/packfile.t: set_integer_keyed_str test failing on Darwin PPC

[James Keenan via RT]

Test continues to pass, so I'm resolving ticket.

[perl #46893] [TODO] [Perl] Complete test coverage of Parrot::Test

[James Keenan via RT]

On Thu Oct 25 08:20:10 2007, pcoch wrote:
> In t/perl/Parrot_Test.t there are the todo item comments:
> 
> # TODO test write_code_to_file(), plan(), skip(), slurp_file()
> 
> # test the test functions from Parrot::Test
> # TODO: test the untested test functions
> 
> This is all (realistically speaking) todo item.  That is: test all
> functions contained within the Parrot::Test module.

I am developing an approach to doing this which will apply to all the
files in t/perl/*.t.  I will post details soon.

kid51

[perl #46891] [TODO] [Perl] Test Parrot::Test::run_command

[James Keenan via RT]

On Thu Oct 25 08:18:13 2007, pcoch wrote:
> In t/perl/Parrot_Test.t there is the todo item:
> 
> # TODO test run_command()
> 
> Do this please :-)

Since RT 46893 calls for testing Parrot::Test in general, I'm going to
merge this ticket into that one.

kid51

[perl #60622] [BUG] t/pmc/pmc.t failing on Darwin

[James Keenan via RT]

Moritz confirmed that a related ticket is passing for him, so I'm
stealing this ticket and marking it Resolved.

kid51

[perl #41168] [CAGE] graceful "no compiler" error message?

[James Keenan via RT]

On Mon Nov 24 13:45:03 2008, coke wrote:

> 
> I'm satisfied that the original request is resolved. There's a lot of 
> discussion further down in the ticket which I /think/ can be shelved 
> until  whenever config is looked at down the road.
> 

Agreed.  I will take the ticket now and close it in a few days unless
someone registers strong objection.

kid51

[perl #57492] [CAGE] Explore possible speedups of t/configure/*.t tests

[James Keenan via RT]

Done in r33127.  Other suggestions?

[perl #57492] [CAGE] Explore possible speedups of t/configure/*.t tests

[James Keenan via RT]

On Sun Nov 23 17:48:48 2008, particle wrote:

> >
> the use_ok tests can all go in one file, so they're only run once.
> ~jerry

Reviewing them, I think we can probably eliminate them as 'use_ok' tests
and simply 'use' the modules.  I think I'll do that with all except the
config step classes, which are eval-ed in.

kid51

[perl #46803] [TODO] [Perl] Improve the GC eagerness test in t/stm/basic.t

[James Keenan via RT]

Why is this test labelled [Perl] rather than [PIR]?

[perl #46807] [TODO] [Perl] Thread types tests need rework

[James Keenan via RT]

On Wed Oct 24 13:06:54 2007, pcoch wrote:
> In t/pmc/threads.t there is the todo item:
> 
> # XXX FIXME rework tests since we don't really have thread types?
> 
> I hope this comment is fairly self-explanatory.

Well, I, for one, don't know what it means.

Also, shouldn't this be classified as a [PIR] ticket rather than a
[Perl] ticket?

kid51

[perl #46865] [TODO] [Perl] Capture STDOUT when running BigNum tests

[James Keenan via RT]

On Wed Oct 24 14:56:32 2007, pcoch wrote:
> In t/pmc/bignum.t there is the todo item:
> 
> # XXX Capture STDOUT
> runtest( $_[0], $_[1], $ops{ $ARGV[2] }, $_[3], $round{ $_[4] }, $_[5] );
> 
> Which means that the output from stdout needs to be captured (and
> supposedly used) when running individual BigNum tests.

Am stalling this for same reason as RT 46863:  there's no sense
fine-tuning the test if there's nothing yet we can test.

When we *do* have something to test, we can use IO::CaptureOutput to
capture the STDOUT.

Thank you very much.
kid51

[perl #49832] [BUG] Storable error during build (0.5.2) in MacosX

[James Keenan via RT]

On Wed Jun 18 07:43:59 2008, packy wrote:
> Minor note:
> 
> Darwin Kernel Version 7.9.0  =>  OSX 10.3.9

I believe we recently made Storable v2.12 the minimum version for
configuration of Parrot.  Have you tried configuring recently?  Any
different results?

Thank you very much.
kid51

[perl #49912] [BUG] Unable to Configure using Borland C

[James Keenan via RT]

On Tue Jan 22 16:14:47 2008, [EMAIL PROTECTED] wrote:
> On Tue Jan 22 14:02:30 2008, ajr wrote:
> 
> > 
> > Any suggestions for further floundering would be welcome.
> > 
> 
> Well, here's one thought.  You could try running Configure.pl with the
> addition of the --configure_trace option.  Read the POD for
> Parrot::Configure::Trace to see how you would then be able to trace the
> evolution of specific values inside the Parrot::Configure object as you
> go through the 60+ config steps.
> 


Alan:  Any update on this?

Question for any Win32 expert:  Is the Borland C compiler worth
expending Parrot tuits on?

kid51

[perl #50518] [RFC] Is the "rpms" target dead?

[James Keenan via RT]

Is there someone on RedHat or Fedora who could take a whack at this?

[perl #55386] [RFC] Remove Configure.pl -miniparrot option

[James Keenan via RT]

Coke, notfound:

Did we reach any resolution on these questions?

Thank you very much.

kid51

[perl #55504] [BUG] Failing test t/op/spawnw.t

[James Keenan via RT]

On Wed Sep 10 19:48:04 2008, [EMAIL PROTECTED] wrote:
> Can someone evaluate where we stand with respect to the issues in this RT?
> 
> Thank you very much.
> 
> kid51

Still hoping for feedback on these issues.

[perl #56032] YAPC::NA 2008 Chicago Buildfest Results

[James Keenan via RT]

Jeff,

Have you tried out the patch, or otherwise tried to build Parrot recently?

Thank you very much.
kid51

[perl #56206] [TODO] Modify the smoke server to accept smokes from releases, not just svn

[James Keenan via RT]

We're in the beginning stages of deprecating smoke.parrotcode.org in
favor of our Smolder report system.  So it would probably not be worth
our effort to modify the smoke system to accept smoke test reports from
new sources, such as proposed here for releases.

I would like to encourage you to try out the Smolder server by saying:

make && make smoldertest.

It's as simple as that.

I will close this ticket in 7 days if no one objects.

Thank you very much.
kid51

[perl #57286] t/examples/library.t fails during make test on OS X 10.5.4

[James Keenan via RT]

This appears to be the same issue as reported in RT 59112, so I am going
to merge this ticket into that.

kid51

[perl #57492] [CAGE] Explore possible speedups of t/configure/*.t tests

[James Keenan via RT]

On Mon Sep 08 18:43:49 2008, [EMAIL PROTECTED] wrote:
> On Tue Aug 19 19:28:43 2008, [EMAIL PROTECTED] wrote:
> > A net total of 5 t/configure/*.t files were eliminated tonight as part
> > of r30368 (RT 57780).
> 
> And I've been able to consolidate a few more over the past few weeks. 
> We now have 47 tests, down from a high of about 61.

If anyone wants to suggest specific t/configure/*.t tests which could be
merged (in the sense that their individual tests could logically sit
within the same file), please speak up.  Otherwise, I will resolve this
ticket within 7 days.

thanks.

kid51

[perl #58726] [PATCH] add the option "encoding" to Configure.pl

[James Keenan via RT]

On Fri Sep 19 07:32:09 2008, pgerd wrote:
> On Do. 18. Sep. 2008, 10:52:32, julianalbo wrote:
> > Is not good that pir or pasm code meaning be dependent of locale
> > specifics of the system.
> > 
> > Also in several operating systems is not the computer who is working
> > with some charset and encoding or other, is each process (depending of
> > user settings on locale env vars, for example). So establishing an
> > immutable global default is not a good idea.
> > 
> 
> I think Parrot use a global default (fixed_8) which should be
> configurable at least. I think it would be nice to have a changeable
> default as an Opcode.


I think that this is a question which will call for a ruling from the
architect and core developers.  Allison, care to weigh in?

Thank you very much.
kid51

[perl #58760] [BUG] perl-5.8.3 fails in dynpmc.pl with Cannot restore overloading on HASH(0x...) at Storable

[James Keenan via RT]

I believe that since this RT was first posted we have upped our
requirement for Storable.pm to v2.12 (without upping our requirement for
Perl).

Reini, are you still experiencing these problems?

Thank you very much.
kid51

[perl #58958] Build of 0.7.1 fails with Intel compiler on Linux

[James Keenan via RT]

Would it be possible to re-run these attempts to build Parrot using the
latest available version (0.8.1, I believe) and report continuing problems?

Thank you very much.
kid51

[perl #59112] Failing test in t/examples/library.t

[James Keenan via RT]

On Wed Oct 22 12:52:39 2008, masak wrote:
> Just wanted to note that the reported problem does not occur for me
> anymore. In fact, I don't see the file t/examples/library.t among the
> tested files in the `make test` output. Neither does grep.

Unfortunately, all that demonstrates is that we changed the list of
tests run during 'make test' to exclude t/examples/*.t.  The test file
itself is still very much there.

$ ls -l t/examples/library.t 
-rw-r--r-- 1 jimk jimk 2108 Jul  2 20:26 t/examples/library.t

Can you report what results you are currently getting when you run:
prove -v t/examples/library.t ?

Thank you very much.
kid51

[perl #60474] Configure.pl doesn't properly detect osname

[James Keenan via RT]

On Mon Nov 10 22:04:35 2008, pioto wrote:
> 
> Sorry, I don't have a patch yet, I'm still figuring out how
>Configure.pl
> works.
> 
> 

To debug this, you may find it helpful to call:  perl Configure.pl
--test=configure.

This will run the tests in t/configure and t/steps.  Of particular
interest will be t/steps/auto_arch-01.t.

kid51

[perl #52196] [TODO] Secure F2F user feedback for configure-build-test cycle for Parrot and languages

[James Keenan via RT]

We should continue to do these build fests -- invite me to your .pm
meeting and I'll lead the fest -- but we don't need to keep an RT open
to do it.  So I'm resolving this ticket.  Some issues discovered at
individual build fests remain open, but they have their own RTs.

Thank you very much.
kid51

[perl #59924] [BUG] t/examples/library.t: new failure

[James Keenan via RT]

On Sat Oct 18 09:39:52 2008, [EMAIL PROTECTED] wrote:

> 
> 
> Here is more data concerning the above test failure.
> 
> Between r31872 (Oct 10) and r31967 (Oct 14), I used 'apt-get' to install
> 4 additional Debian packages on the Linux box on which these tests were
> run.  The packages were:
> 
> ii  libgmp3-dev4.2.1+dfsg-4   Multiprecision arithmetic library
> developers
> ii  libgmp3-doc4.2.1+dfsg-4   Multiprecision arithmetic library
> example co
> ii  libgmp3c2  4.2.1+dfsg-4   Multiprecision arithmetic library
> ii  libgmpxx4  4.2.1+dfsg-4   Multiprecision arithmetic library (C++
> bindi
> 
> I installed these packages because on Linux, Configure.pl was telling me
> in step auto::gmp that it could not locate GMP.  So I was never building
> Parrot with GMP.  After installing these four packages, Configure.pl
> told me it was now locating GMP.
> 
> But it was after this install that the test in t/examples/library.t
> began to fail.  So I called 'apt-get remove' to remove the 4 packages
> above.  At this point the test began to pass in both r31967 and HEAD.
> 
> So, can anyone speculate as to why installation of these 4 packages
> would cause a failure in a test of PCRE?
> 

This morning I found time to reinstall the 3 libgmp3 packages -- but I
did not reinstall the libgmp4 package.  All tests passed on Linux.

So perhaps it was a problem between gmp3 and gmp4.  Closing ticket.

kid51

[perl #50920] [BUG]: t/compilers/imcc/syn/macro.t failing

[James Keenan via RT]

On Sun Jul 20 18:55:22 2008, [EMAIL PROTECTED] wrote:

> 
> This patch isn't ideal, but it gets us closer (and avoiding SIGABRT is
> good).
> 

Reviewing old tickets today.  I applied this patch on my Linux/i386, but
got no improvement.  Test #36, which has been TODO-ed, still fails:

not ok 36 - invalid label syntax # TODO RT #47978, RT #51104

#   Failed (TODO) test 'invalid label syntax'
#   at t/compilers/imcc/syn/macro.t line 469.
#   'compilers/imcc/imcc.l:1004: failed assertion 'valp->s'
# Backtrace - Obtained 10 stack frames (max trace depth is 32).
#   (unknown)
# Parrot_confess
#   (unknown)
# yylex
#   yyparse
# (unknown)
#   imcc_run
# (unknown)
#   __libc_start_main
# (unknown)
# '
# doesn't match '/Syntax error in macro at: \('\$iter_loop:'\)/
# '
# './parrot   "t/compilers/imcc/syn/macro_36.pir"' failed with exit code
[SIGNAL 6]


Here's the result of gdb:

(gdb) run t/compilers/imcc/syn/macro_36.pir
Starting program:  t/compilers/imcc/syn/macro_36.pir
[Thread debugging using libthread_db enabled]
[New Thread 1098391040 (LWP 14520)]
warning: Lowest section in /usr/lib/libicudata.so.36 is .hash at 00b4
compilers/imcc/imcc.l:1004: failed assertion 'valp->s'
Backtrace - Obtained 10 stack frames (max trace depth is 32).
  (unknown)
Parrot_confess
  (unknown)
yylex
  yyparse
(unknown)
  imcc_run
(unknown)
  __libc_start_main
(unknown)

Program received signal SIGABRT, Aborted.
[Switching to Thread 1098391040 (LWP 14520)]
0x41422947 in raise () from /lib/tls/libc.so.6
(gdb) bt
#0  0x41422947 in raise () from /lib/tls/libc.so.6
#1  0x414240c9 in abort () from /lib/tls/libc.so.6
#2  0x401dcd6b in Parrot_confess (cond=0x405a0438 "valp->s", 
file=0x405a0422 "compilers/imcc/imcc.l", line=1004) at
src/exceptions.c:506
#3  0x404d3d31 in read_macro (valp=0xbf8e6d0c, interp=0x804f048, 
yyscanner=0x81178d8) at compilers/imcc/imcc.l:1004
#4  0x404cfea2 in yylex (valp=0xbf8e6d0c, yyscanner=0x81178d8, 
interp=0x804f048) at compilers/imcc/imcc.l:455
#5  0x404c944d in yyparse (yyscanner=0x81178d8, interp=0x804f048)
at compilers/imcc/imcparser.c:2781
#6  0x404d6bad in compile_to_bytecode (interp=0x804f048, 
sourcefile=0xbf8e7b74 "t/compilers/imcc/syn/macro_36.pir",
output_file=0x0)
at compilers/imcc/main.c:950
#7  0x404d6f92 in imcc_run (interp=0x804f048, 
sourcefile=0xbf8e7b74 "t/compilers/imcc/syn/macro_36.pir", argc=1, 
argv=0xbf8e6f48) at compilers/imcc/main.c:1053
#8  0x08048938 in main (argc=1, argv=0xbf8e6f48) at src/main.c:61

[perl #46519] [BUG] t/stm/runtime.t test failures

[James Keenan via RT]

No complaints since July, so I'm closing the ticket.

[perl #59638] [BUG] [MMD] t/pmc/bigint.t intermittently failing on various OSes

[James Keenan via RT]

On Sun Oct 19 18:34:40 2008, [EMAIL PROTECTED] wrote:
> I probably spoke too soon.  We have a Smolder failure report for this
> test on AIX.  So I'm going to reopen the ticket and rename it "failing
> intermittently on various OSes."

The only data I have available on this is from our Smolder reports.  It
appears that this test has been passing on AIX since Nov 4:

http://smolder.plusthree.com/app/public_projects/report_details/8093

So, keeping fingers crossed, I'm re-closing the ticket.

kid51

[perl #59636] [BUG] t/op/bitwise.t fails on Darwin

[James Keenan via RT]

On Tue Oct 28 20:03:36 2008, [EMAIL PROTECTED] wrote:
> 
> This has continued to pass for me on 10.4/PPC.  Coke, if it's passing
> for you as well (which, from Smolder reports, appears to be the case),
> then can you close the ticket?
> 

No feedback from Coke, so I'm closing the ticket.

[perl #60642] [CAGE] add a codingstd test to ensure TODOed tests have an RT ticket number

[James Keenan via RT]

On Wed Nov 19 23:13:27 2008, [EMAIL PROTECTED] wrote:
> James Keenan via RT wrote:
> > On Tue Nov 18 10:22:25 2008, [EMAIL PROTECTED] wrote:
> > 
> > This will probably be quite challenging.  Let's assume that all tests
> > are found in files with names ending in '.t'.  Those .t files can be
> > written in any language, which probably have different ways of
> > classifying a test as TODO.
> > 
> > My count tonight is that 1384 .t files in the distribution.  Of these
> > 524 are *not* found under ./languages/.
> > 
> > I wonder if we could formulate the specification in this ticket a bit
> > more precisely before someone embarks on coding.
> 
> Yes, absolutely.  I just added the basic ticket on the spur of the 
> moment, to make sure I didn't forget about it.
> 
> I've been thinking about this.  A few things come to mind, for instance 
> detecting the language based on the hashbang (if any) or subdirectory 
> it's in, and invoking a language-specific parser.  And detecting the 
> cases we can't handle, and skipping those.
> 
> But to me that sounds like way too much work.  It doesn't really matter 
> to me whether the ticket number occurs within the TODO output string, a 
> nearby comment is good enough for me.  So how about skipping all the 
> above nonsense and just ignoring the test language entirely?  How about 
> a simple regex-based test that tallies all instances of /TODO/ in the 
> set of test files, skipping the lines that start with obvious comment 
> characters, and for each instance, looks for a match of /#\d+/?  It can 
> even expand the search to also look a couple lines above and below the 
> TODO line, for additional flexibility.  I think that should be 
> reasonable for most, if not all, possible test languages.
> 
> Do you think that would catch all the cases?  


Two thoughts:

1.  We already have code that can detect the existence of TODO in
certain kinds of files.  Cf. t/codingstd/fixme.t.  Paul Cochrane used
that a couple of years back to generate hundreds of RTs -- most of which
are probably still outstanding.  Can we leverage that
Parrot::Distribution-based code?

2.  I've heard a lot of talk lately about languages moving into their
own repositories.  If so, then we have to ask whether we should be
instituting new coding standards for .t files under ./languages/.  At
what point do we say:  You (languages) are responsible for setting and
enforcing your own coding standards.  That would reduce the scope of
this ticket to files that are intrinsically related to Parrot.

Feedback welcome.  I'm not wedded to any approach and am not committing
myself to any.

kid51

[perl #60622] [BUG] t/pmc/pmc.t failing on Darwin

[James Keenan via RT]

This passed tonight on Darwin/PPC, r32919.  I can't tell which commit
fixed the problem.  Cf.: 
http://smolder.plusthree.com/app/public_projects/tap_stream/8270/270

If it continues to pass over the next week, I will close the ticket.

Thank you very much.
kid51

[perl #60068] [BUG] t/pmc/packfile.t: set_integer_keyed_str test failing on Darwin PPC

[James Keenan via RT]

Tonight, for the first time in four weeks, this test (#6) passed on
Darwin/PPC.  Cf.:
http://smolder.plusthree.com/app/public_projects/tap_stream/8270/260

I can't really tell which commit fixed this failure.  Given the fact
that several files with 'pack' in their names were changed in r32888
(particle changing PARROT_API -> PARROT_EXPORT), that commit is a
possibility.

Assuming it continues to pass over the next week, I will close the ticket.

[perl #60068] [BUG] t/pmc/packfile.t: set_integer_keyed_str test failing on Darwin PPC

[James Keenan via RT]

On Sat Nov 08 00:06:50 2008, [EMAIL PROTECTED] wrote:
> 
> Can you post a backtrace?
> 

Attached.



backtrace.packfile_6.pir
Description: Binary data

[perl #49276] [TODO] Refactor tools/util/smokeserv-server.pl

[James Keenan via RT]

On Fri Nov 14 11:42:02 2008, bernhard wrote:
> On Mo. 16. Jun. 2008, 16:50:13, coke wrote:
> > On Wed Jan 16 03:41:56 2008, [EMAIL PROTECTED] wrote:
> > > While the fix to my particular problem is simple enough, it is
> > apparent
> > > that there's enough bit rot in tools/util/smokeserv-server.pl that
> > it
> > > needs a refactoring.  And since there are no unit/regression tests
> > for
> > > this program, it's going to need a good phalanxing.
> 
> > We should probably defer this until post-smolder; we may be able to
> > just drop smoke at that
> > point.
> 
> Is the smoke server still used?

Yes.  A crude search indicates 83 submissions so far this month.

> Can support for the smoke server be dropped?

Yes, but we need to put it through some kind of deprecation cycle before
dropping it entirely.

On the one hand:  I had hoped to refactor the smokeserver code to make
it more user-friendly and to keep it from rejecting perfectly valid
reports.  But coke encouraged me to defer that until after the Smolder
server was established.  We've had Smolder for 6+ months now and, while
it doesn't satisfy my every wish and need, it doesn't reject my reports.
 So I find that I haven't looked at smoke.parrotcode.org for months.

On the other hand:  (a) People are still submitting smoke reports; and
(b) AFAICT the smolder server only reports results of Parrot's 'make
test', where as the smoke server can report tests of languages.  So an
immediate switch to smolder-only would cause a loss in functionality.

Hence the need for a deprecation plan and cycle.  Suggestions?

Thank you very much.
kid51

[perl #60312] [BUG] OpenBSD Smolder test failures

[James Keenan via RT]

I understand that some of the Parrot developers will be having a confab
at Google the weekend after this.  Perhaps they could devote some time
to discussing the question of how we can recruit to the project some
people who are *really* knowledgeable about particular OSes, i.e.,
porters.  I definitely would welcome that for Darwin and OpenBSD, and
I'm sure Win32 and other systems as well could use that level of expertise.

[perl #60312] [BUG] OpenBSD Smolder test failures

[James Keenan via RT]

On Mon Nov 03 09:38:38 2008, doughera wrote:
> On Sun, 2 Nov 2008, James Keenan wrote:
> 
> 
> > Observations:
> > 1.  All 6 of these tests are marked to be skipped on Win32.  So  
> > perhaps the reason they're failing on OpenBSD is the same as that for  
> > Win32.  If so, then we could add 'OpenBSD' to the SKIP messages for  
> > each.
> 
> I have never liked that plan -- skipping tests simply because they fail 
> just hides the problem.  As a short-term step to keep from being 
> distracted, sure, it's a good strategy.  But such sort term "fixes" tend 
> to become very long-lived, leading folks to forget there even was a 
> problem.

Agreed.

  If the failing tests themselves are the problem, they should 
> just be deleted.
> 
> > 2.  4 of the tests appear to fail depending on how the OS 'spells'  
> > the negation of zero.  Could we address this in a hints file?
> 
> This is a long-standing problem:  See [perl #28170] and [perl #30737]. 

Will add links to those tickets from this RT.

> Are the underlying machines and 
> perl5 configurations the same for the NetBSD and OpenBSD tests?  

I believe so.  I think magnachef has them set up as virtual machines on
the same underlying box.  He's working on getting me accounts on them
and, if that comes through, I'll be able to post Configure.pl and make
output.

kid51

[perl #60068] [BUG] t/pmc/packfile.t: set_integer_keyed_str test failing on Darwin PPC

[James Keenan via RT]

Still failing as of r32225; cf
http://smolder.plusthree.com/app/public_projects/tap_stream/7437/260

not ok 6 - set_integer_keyed_str

#   Failed test 'set_integer_keyed_str'
#   at t/pmc/packfile.t line 140.
# Exited with error code: [SIGNAL 11]
# Received:
# 
# Expected:
# not equal
# 

[perl #60178] Commit r32189 breaks Parrot on Mac OS X 10.5.4

[James Keenan via RT]

On Tue Oct 28 12:08:05 2008, masak wrote:

> Good suggestions. Here we go: .
> 

As a (probably misleading) point of reference, here's what I got on Mac
OS X 10.4 PPC in the same vicinity (95% of the way thru 'make') in a
recent build:

make -C compilers/pge
/usr/local/bin/perl -MExtUtils::Command -e rm_f PGE.pbc
../../runtime/parrot/library/PGE.pbc
/usr/local/bin/perl -e "" >PGE/builtins_gen.pir
../../parrot -o PGE.pbc --output-pbc PGE.pir
../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir 
--output=PGE/builtins_gen.pir PGE/builtins.pg

# The next line is where things go wrong for you:

/usr/local/bin/perl -MExtUtils::Command -e rm_f PGE.pbc
../../parrot -o PGE.pbc --output-pbc PGE.pir
/usr/local/bin/perl -MExtUtils::Command -e cp PGE.pbc
../../runtime/parrot/library
make -C compilers/tge
../../parrot -o TGE/Rule.pbc --output-pbc TGE/Rule.pir
...

I have no good insight into why this is happening.

[perl #59636] [BUG] t/op/bitwise.t fails on Darwin

[James Keenan via RT]

On Wed Oct 22 19:03:27 2008, [EMAIL PROTECTED] wrote:
> After yesterday's release, this passed for me on Darwin PPC 10.4 at
> r32119.  I'll keep my fingers crossed and keep watching the Smolder
reports.
> 

This has continued to pass for me on 10.4/PPC.  Coke, if it's passing
for you as well (which, from Smolder reports, appears to be the case),
then can you close the ticket?

thanks.

kid51

[perl #60178] Commit r32189 breaks Parrot on Mac OS X 10.5.4

[James Keenan via RT]

On Tue Oct 28 12:08:05 2008, masak wrote:

> Good suggestions. Here we go: .
> 

As a (probably misleading) point of reference, here's what I got on Mac
OS X 10.4 PPC in the same vicinity (95% of the way thru 'make') in a
recent build:

make -C compilers/pge
/usr/local/bin/perl -MExtUtils::Command -e rm_f PGE.pbc
../../runtime/parrot/library/PGE.pbc
/usr/local/bin/perl -e "" >PGE/builtins_gen.pir
../../parrot -o PGE.pbc --output-pbc PGE.pir
../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir 
--output=PGE/builtins_gen.pir PGE/builtins.pg

# The next line is where things go wrong for you:

/usr/local/bin/perl -MExtUtils::Command -e rm_f PGE.pbc
../../parrot -o PGE.pbc --output-pbc PGE.pir
/usr/local/bin/perl -MExtUtils::Command -e cp PGE.pbc
../../runtime/parrot/library
make -C compilers/tge
../../parrot -o TGE/Rule.pbc --output-pbc TGE/Rule.pir
...

I have no good insight into why this is happening.

[perl #59924] [BUG] t/examples/library.t: new failure

[James Keenan via RT]

On Sat Oct 18 09:39:52 2008, [EMAIL PROTECTED] wrote:
> On Thu Oct 16 04:39:06 2008, [EMAIL PROTECTED] wrote:
> [snip]
> 
> Here is more data concerning the above test failure.
> 
> Between r31872 (Oct 10) and r31967 (Oct 14), I used 'apt-get' to install
> 4 additional Debian packages on the Linux box on which these tests were
> run.  The packages were:
> 
> ii  libgmp3-dev4.2.1+dfsg-4   Multiprecision arithmetic library
> developers
> ii  libgmp3-doc4.2.1+dfsg-4   Multiprecision arithmetic library
> example co
> ii  libgmp3c2  4.2.1+dfsg-4   Multiprecision arithmetic library
> ii  libgmpxx4  4.2.1+dfsg-4   Multiprecision arithmetic library (C++
> bindi
> 
> I installed these packages because on Linux, Configure.pl was telling me
> in step auto::gmp that it could not locate GMP.  So I was never building
> Parrot with GMP.  After installing these four packages, Configure.pl
> told me it was now locating GMP.
> 
> But it was after this install that the test in t/examples/library.t
> began to fail.  So I called 'apt-get remove' to remove the 4 packages
> above.  At this point the test began to pass in both r31967 and HEAD.
> 
> So, can anyone speculate as to why installation of these 4 packages
> would cause a failure in a test of PCRE?
> 


Any thoughts on this?

[perl #60178] Commit r32189 breaks Parrot on Mac OS X 10.5.4

[James Keenan via RT]

This will be difficult to diagnose unless we do see 'make' output, so
please attach a file.  Alternative, go to IRC #parrot and use 'nopaste'
to post.

[perl #60134] [TODO] Add tests for file-based interface to Configure.pl

[James Keenan via RT]

No complaints.  No failures in Smolder tests.  Resolving ticket.

[perl #60134] [TODO] Add tests for file-based interface to Configure.pl

[James Keenan via RT]

Work completed and merged into trunk in r32182.

[perl #59636] [BUG] t/op/bitwise.t fails on Darwin

[James Keenan via RT]

After yesterday's release, this passed for me on Darwin PPC 10.4 at
r32119.  I'll keep my fingers crossed and keep watching the Smolder reports.

kid51

[perl #59880] DOD crash in r31926, t/op/bitwise.t #27 on linux/x86_64

[James Keenan via RT]

Anyone taking a look at this test should take note of the fact that the
immediately preceding test in this file is also experiencing failures on
certain platforms:  http://rt.perl.org/rt3/Ticket/Display.html?id=59638

[perl #60016] [PATCH] Make basic Perl 6 tests pass

[James Keenan via RT]

On Mon Oct 20 09:46:08 2008, [EMAIL PROTECTED] wrote:
\> This basic test suite will fail.  That's because of this test program:
> 
>   t/00-parrot/06-op-inplace.t
> 

I've reported this a couple of times in
http://rt.perl.org/rt3/Ticket/Display.html?id=59634 -- but no one paid
attention.

Since you're proposing a patch, I'll merge 59634 into this one.

kid51

[perl #59638] [BUG] t/pmc/bigint.t fails on Darwin

[James Keenan via RT]

I should have included the failure report:

http://smolder.plusthree.com/app/public_projects/tap_stream/6324/202

This was at r32032.

[perl #59638] [BUG] t/pmc/bigint.t fails on Darwin

[James Keenan via RT]

I probably spoke too soon.  We have a Smolder failure report for this
test on AIX.  So I'm going to reopen the ticket and rename it "failing
intermittently on various OSes."

[perl #59634] [BUG] languages/perl6/t/00-parrot/06-op-inplace.t failure

[James Keenan via RT]

Tonight I got this:

t/00-parrot/06-op-inplace.. All 11 subtests passed 

... but then I subsequently got this:

Test Summary Report
---
t/00-parrot/06-op-inplace  (Wstat: 0 Tests: 11 Failed: 0)
  Parse errors: Tests out of sequence.  Found (3) but expected (9)
Tests out of sequence.  Found (8) but expected (10)
Tests out of sequence.  Found (12) but expected (11)

I've never seen a test report like this, i.e., one which reports when
tests were run out of sequence.  Granted, having tests run out of
sequence doesn't sound good.  But what exactly is the problem here?

kid51

[perl #59636] [BUG] t/op/bitwise.t fails on Darwin

[James Keenan via RT]

On Sat Oct 18 16:28:22 2008, coke wrote:

> 
> I'm submitting some every night at midnight on my osx/x86 box; if it's
> obviously a temp directory and the right time frame, it's probably me.
> 
> 

So it seems to be failing consistently on Darwin regardless of platform.

Also, tonight I confirmed that the failure began at the recent merge in
r31668.  For the record, the svn diff of the test file at that point was:

$ svn diff -r 31667:31668 t/op/bitwise.t
Index: t/op/bitwise.t
===
--- t/op/bitwise.t  (revision 31667)
+++ t/op/bitwise.t  (revision 31668)
@@ -552,11 +552,11 @@
 loop:
 if $P1 > 100 goto done
 ## shift number and i_number into $P2 and $I2.
-n_shl $P2, number, $P1
+shl $P2, number, $P1
 $I1 = $P1
 shl $I2, i_number, $I1
 ## compare in I registers.
-$P3 = n_mod $P2, integer_modulus
+$P3 = mod $P2, integer_modulus
 $I3 = $P3
 if $I2 >= 0 goto pos_check
 ## The register op gave a negative result, but the modulus will
always be


However, as this test is passing on many other platforms, it's quite
possible that the failure is due to something that happened elsewhere in
r31668.

kid51

[perl #59636] [BUG] t/op/bitwise.t fails on Darwin

[James Keenan via RT]

On Sat Oct 18 12:01:13 2008, [EMAIL PROTECTED] wrote:
> James Keenan via RT wrote:
> > Still failing on Darwin/PPC as of r32014:
> > 
> > http://smolder.plusthree.com/app/public_projects/tap_stream/6320/163
> 
> Looking at the specific test in question, this may be an integer size 
> problem.
> 
> > And I should note that it's also been failing on Darwin/i386:
> > 
> > http://smolder.plusthree.com/app/public_projects/tap_stream/6316/163
> 
> What version of Darwin and what x86 hardware?

The tests with this tag are from my 10.4 iBook (which many Parrot
developers have seen and even worked on!):
Tags(/usr/bin/gcc, 0.7.1, Perl 5.10.0 darwin-2level, darwin, ppc)

I don't know who is submitting the Darwin x86 tests.

Tags(0.7.1, Perl 5.8.8 darwin-2level, cc, darwin, i386)

Smolder, FBOW, does not indicate who submitted reports.

kid51

[perl #59636] [BUG] t/op/bitwise.t fails on Darwin

[James Keenan via RT]

Still failing on Darwin/PPC as of r32014:

http://smolder.plusthree.com/app/public_projects/tap_stream/6320/163

And I should note that it's also been failing on Darwin/i386:

http://smolder.plusthree.com/app/public_projects/tap_stream/6316/163

[perl #59638] [BUG] t/pmc/bigint.t fails on Darwin

[James Keenan via RT]

On Sun Oct 05 17:58:03 2008, [EMAIL PROTECTED] wrote:
> Full report:  http://smolder.plusthree.com/app/public_projects/ 
> report_details/5872
> 
> Platform: darwin
> Architecture: ppc
> Compiler: /usr/bin/gcc
> DEVEL: -devel
> Optimize: none
> Perl Version: 5.10.0 darwin-2level
> SVN Revision: 31687
> Version: 0.7.1
> 
> GMP version 4.1.3
> 
> t/pmc/bigint.t
> 
> not ok 26 - pi() generator
> 
> #   Failed test 'pi() generator'
> #   at t/pmc/bigint.t line 579.
> # Exited with error code: [SIGNAL 11]
> # Received:
> # 31415926535897932384626433832795028841971693993751
> # 05820974944592307816406286208998628034825342117067
> # 98214808651328230664709384460955058223172535940812
> # 84811174502841027019385211055596446229489549303819
> # 64428810975665933446128475648233786783165271201909
> # 14564856692346034861045432664821339360726024914127
> # 37245870066063155881748815209209628292540917153643
> # 67892590360011330530548820466521384146951941511609
> # 43305727036575959195309218611738193261179310511854
> # 80744623799627495673518857527248912279381830119491
> # 29833673362440656643086021394946395224737190702179
> # 86094370277053921717629317675238467481846766940513
> # 20005681271452635608277857713427577896091736371787
> #
> # Expected:
> # 31415926535897932384626433832795028841971693993751
> # 05820974944592307816406286208998628034825342117067
> # 98214808651328230664709384460955058223172535940812
> # 84811174502841027019385211055596446229489549303819
> # 64428810975665933446128475648233786783165271201909
> # 14564856692346034861045432664821339360726024914127
> # 37245870066063155881748815209209628292540917153643
> # 67892590360011330530548820466521384146951941511609
> # 43305727036575959195309218611738193261179310511854
> # 80744623799627495673518857527248912279381830119491
> # 29833673362440656643086021394946395224737190702179
> # 86094370277053921717629317675238467481846766940513
> # 20005681271452635608277857713427577896091736371787
> # 21468440901224953430146549585371050792279689258923
> # 54201995611212902196086403441815981362977477130996
> # 0518707211349983729780499510597317328160963185
> # 95024459455346908302642522308253344685035261931188
> # 17101000313783875288658753320838142061717766914730
> # 35982534904287554687311595628638823537875937519577
> # 81857780532171226806613001927876611195909216420198
> #
> #
> 
> Note:  This test, same revision, passed on Linux.


This test failure appears to have cleared up:
http://smolder.plusthree.com/app/public_projects/report_details/6320

I can't really say what fixed it or what caused it in the first place. 
But I'm marking the ticket resolved.

[perl #59924] [BUG] t/examples/library.t: new failure

[James Keenan via RT]

On Thu Oct 16 04:39:06 2008, [EMAIL PROTECTED] wrote:
[snip]
> not ok 3 - examples/library/pcre.pir
> 
> #   Failed test 'examples/library/pcre.pir'
> #   at t/examples/library.t line 67.
> #  got: 'asdf =~ /as/
> # 1 match(es):
> # '
> # expected: 'asdf =~ /as/
> # 1 match(es):
> # as
> # '
[snip]
> 
> So far I have not been able to identify any files which changed  
> during this interval and which are obvious candidates for causing  
> this bug.


Here is more data concerning the above test failure.

Between r31872 (Oct 10) and r31967 (Oct 14), I used 'apt-get' to install
4 additional Debian packages on the Linux box on which these tests were
run.  The packages were:

ii  libgmp3-dev4.2.1+dfsg-4   Multiprecision arithmetic library
developers
ii  libgmp3-doc4.2.1+dfsg-4   Multiprecision arithmetic library
example co
ii  libgmp3c2  4.2.1+dfsg-4   Multiprecision arithmetic library
ii  libgmpxx4  4.2.1+dfsg-4   Multiprecision arithmetic library (C++
bindi

I installed these packages because on Linux, Configure.pl was telling me
in step auto::gmp that it could not locate GMP.  So I was never building
Parrot with GMP.  After installing these four packages, Configure.pl
told me it was now locating GMP.

But it was after this install that the test in t/examples/library.t
began to fail.  So I called 'apt-get remove' to remove the 4 packages
above.  At this point the test began to pass in both r31967 and HEAD.

So, can anyone speculate as to why installation of these 4 packages
would cause a failure in a test of PCRE?

Thank you very much.
kid51

[perl #59638] [BUG] t/pmc/bigint.t fails on Darwin

[James Keenan via RT]

Still failing as of r31872.