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.
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.
No complaints since July, so I'm closing the ticket.
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 -
On Thu, Nov 20, 2008 at 11:38:11AM -0500, Will Coleda wrote:
On Thu, Nov 20, 2008 at 11:36 AM, Klaas-Jan Stol [EMAIL PROTECTED] wrote:
I'm not entirely sure whether it was *just* a rename... ISTR there was also
something to do with a look-up of names. Pm knows more about it :-)
(admittedly,
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
Will Coleda via RT wrote:
* Parrot_mmd_add_function
- src/inter_create.c //make_interpreter
Delete that line from src/inter_create.c. Also delete the line before
which initializes 'interp-binop_mmd_funcs' to NULL.
These two lines are initializing the storage for the old MMD subsystem,
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.
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
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
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
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
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
This appears to be the same issue as reported in RT 59112, so I am going
to merge this ticket into that.
kid51
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
Jeff,
Have you tried out the patch, or otherwise tried to build Parrot recently?
Thank you very much.
kid51
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.
Coke, notfound:
Did we reach any resolution on these questions?
Thank you very much.
kid51
Klaas-Jan Stol via RT wrote:
On Thu Dec 13 04:35:13 2007, pmichaud wrote:
On Sat Sep 29 08:57:28 2007, kjs wrote:
A few months ago, the #line directive was implemented.
I'm wondering what the reason was why it looks like a comment (as #
will
start a comment).
Is there any
On Sun, Nov 23, 2008 at 10:08 PM, Jonathan Worthington
[EMAIL PROTECTED]wrote:
Klaas-Jan Stol via RT wrote:
On Thu Dec 13 04:35:13 2007, pmichaud wrote:
On Sat Sep 29 08:57:28 2007, kjs wrote:
A few months ago, the #line directive was implemented.
I'm wondering what the reason was why
Is there someone on RedHat or Fedora who could take a whack at this?
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
Klaas-Jan Stol wrote:
Minor detail:
.file does not actually exist, except in PIRC.
Well, I guess we can add it...
I do not have a strong preference for adding it. Pro: it's a bit clearer than .line, as
.line indicates, ehm, the line :-) Specifying a filename by .line is a bit
weird. Con:
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
On Sun, Nov 23, 2008 at 13:26, James Keenan via RT
[EMAIL PROTECTED] wrote:
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
On Mon, Nov 24, 2008 at 02:31:58AM +0100, Jonathan Worthington wrote:
Oh, argh, so .line now carries the file *and* the line number?.I wanted
it to just carry the line number (the clue's in the name... ;-)) and
have .file carry the filename. Then the source you compiled from one
file has
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
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]
Patrick R. Michaud wrote:
Either way works for me -- PCT can generate either without much
difficulty. It probably makes more sense to have separate .file
and .line directives. In particular, I wouldn't want to be
repeating the .file annotation information throughout the bytecode! :-)
Just a
Why is this test labelled [Perl] rather than [PIR]?
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
Done in r33127. Other suggestions?
On Mon, Nov 24, 2008 at 03:10:47AM +0100, Jonathan Worthington wrote:
Patrick R. Michaud wrote:
Just a reminder that the central issue for PCT and other HLL's
is that the current #line, setline, setfile, etc. instructions
are currently intimately tied to lines of PIR source (RT #43269),
and
33 matches
Mail list logo
