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 repor
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 - i
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 :-)
> > (adm
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:
>
>
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,
w
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
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
inter
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 chang
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 enc
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 hav
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 an
* dpuu <[EMAIL PROTECTED]> [2008-11-21 19:00]:
> The definition of C includes the statement that it's not
> available on most system unless you're superuser; and this can
> be checked using a POSIX incantation. I was wondering if it
> would be reasonable to provide this as a method on the chown
> f
* Larry Wall <[EMAIL PROTECTED]> [2008-11-21 23:55]:
> Any you could even do it in parallel:
>
> my @status = hyper map { .io.chmod($mode) }, @files
>
> though it's possible your sysadmin will complain about what
> you're doing with the disk drive heads. :)
Actually I/O subsystems are smart e
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 wo
On Nov 23, 2:33 pm, [EMAIL PROTECTED] (Aristotle Pagaltzis) wrote:
> The API you propose does not seem to me to shorten code at all
> and is likely to lead to problematic code, so it seems like a
> bad idea. Interfaces should be designed to encourage people to
> do things correctly and to make it h
On 2008 Nov 23, at 18:35, dpuu wrote:
On Nov 23, 2:33 pm, [EMAIL PROTECTED] (Aristotle Pagaltzis) wrote:
The API you propose does not seem to me to shorten code at all
and is likely to lead to problematic code, so it seems like a
bad idea. Interfaces should be designed to encourage people to
do
* dpuu <[EMAIL PROTECTED]> [2008-11-24 00:40]:
> I agree that the specific example of &chown.is_restricted is a
> bad idea, but only because the POSIX API I was wrapping is
> itself flawed.
It is not flawed in the least, as far as the aspect we are
talking about is concerned. (It is generally sane
Is there someone on RedHat or Fedora who could take a whack at this?
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 th
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 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).
>>
>>
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
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 individu
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 [P
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 r
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, whic
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),
39 matches
Mail list logo
