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),
Done in r33127. Other suggestions?
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
Why is this test labelled [Perl] rather than [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 r
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
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 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 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 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
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 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
Is there someone on RedHat or Fedora who could take a whack at this?
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
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
Coke, notfound:
Did we reach any resolution on these questions?
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.
Jeff,
Have you tried out the patch, or otherwise tried to build Parrot recently?
Thank you very much.
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
This appears to be the same issue as reported in RT 59112, so I am going
to merge this ticket into that.
kid51
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
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
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
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
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
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
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
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
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:
>
>
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 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
No complaints since July, 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
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.
34 matches
Mail list logo