chromatic wrote:
That C string leaks. We should have a diagnostic printf which supports
the %Ss format we use in exception formatting strings.
We have one, it's called PIO_fprintf. But, it's only used once in the
repository, in an STM macro.
Added to the I/O milestone tasklist.
Allison
On Wed, Sep 10, 2008 at 9:21 AM, Allison Randal [EMAIL PROTECTED] wrote:
chromatic wrote:
That C string leaks. We should have a diagnostic printf which supports
the %Ss format we use in exception formatting strings.
We have one, it's called PIO_fprintf. But, it's only used once in the
On Mon Aug 06 06:08:54 2007, pcoch wrote:
In the file t/distro/test_file_coverage.t there is the todo item:
# TODO: DYNPMC, DYNOPS, etc
This is in the context of making sure that the files match the test
files. This needs to be implemented.
Is this as simple as writing a test to make
sorry, documentation and source should be reorganized at some point. For
now, please check out compilers/pirc/README.pod.
sorry for the confusion,
kjs
On Tue, Sep 9, 2008 at 5:31 PM, NotFound [EMAIL PROTECTED] wrote:
I put the commands that I'm using in the README file (but that's for MSVC
on
On Sat, Aug 30, 2008 at 10:40 AM, Allison Randal [EMAIL PROTECTED] wrote:
Klaas-Jan Stol wrote:
On Sat, Aug 30, 2008 at 11:04 AM, Allison Randal [EMAIL PROTECTED]
wrote:
Yes, it will be deprecated, or at least renamed. The C.return
directive
without parentheses is an old convention for
NotFound wrote:
On Wed, Sep 10, 2008 at 9:21 AM, Allison Randal [EMAIL PROTECTED] wrote:
chromatic wrote:
That C string leaks. We should have a diagnostic printf which supports
the %Ss format we use in exception formatting strings.
We have one, it's called PIO_fprintf. But, it's only used
We have more: PIO_printf, PIO_eprintf, Parrot_printf, Parrot_eprintf
and Parrot_fprintf. The Parrot_ ones are a wrapper around the PIO_s,
with added check for extern usage, and that does not need #include io
files.
Yes, to be more accurate, we have a whole range of PIO functions. But, the
I've recently commited a fix on null string constants. I think it was
the same problem described here. I compiled the pir file and pdumped
without a problem, it shows the DATA = NULL my fix introduced.
Can you verify the problem is gone?
I assume you are referring to r30756 of
On Tue, 9 Sep 2008, James Keenan via RT wrote:
On Tue Sep 09 15:14:36 2008, [EMAIL PROTECTED] wrote:
Generally agreed. In this case, hold this ticket for the I/O milestone,
which is next (sometime in the next few days). I've added it to the I/O
tasklist.
In the meantime, let's
I tried to build parrot with the clang, an llvm frontend. It provides a
script called 'ccc', which accepts the same options as gcc.
Configure works fine (perl Configure.pl --verbose --cc=ccc --link=ccc).
The build starts fine, but fails while compiling the first pmc:
clang -emit-llvm-bc -x c
On Wednesday 10 September 2008 10:45:12 Moritz Lenz wrote:
I tried to build parrot with the clang, an llvm frontend. It provides a
script called 'ccc', which accepts the same options as gcc.
Configure works fine (perl Configure.pl --verbose --cc=ccc --link=ccc).
src/pmc/default.c:65:36:
chromatic wrote:
On Wednesday 10 September 2008 10:45:12 Moritz Lenz wrote:
I tried to build parrot with the clang, an llvm frontend. It provides a
script called 'ccc', which accepts the same options as gcc.
Configure works fine (perl Configure.pl --verbose --cc=ccc --link=ccc).
On Wednesday 10 September 2008 11:07:41 Moritz Lenz wrote:
That doesn't the seem to be case here. I tried with a small sample
script that include a .str file, and it works fine.
A
ack -a '_CONST_STRING_65\b'
didn't find anything; so is this a broken macro expansion somewhere?
The line
On Wed, Sep 10, 2008 at 8:12 PM, chromatic [EMAIL PROTECTED] wrote:
The line numbers reported by clang seem sensible enough, but do they match
values in src/pmc/default.str? Mine contains:
#define _CONST_STRING_45 80
#define _CONST_STRING_103 534
#define _CONST_STRING_144 _CONST_STRING_103
# from Will Coleda
# on Monday 28 July 2008 07:31:
I presume Eric noticed this as he was working on his patch to enable a
parallel make test; Now that his patch is applied, fixing these tests
should have a higher priority; If two tests that are trying to
create/use the same directory run at the
On Wed Sep 10 09:30:37 2008, doughera wrote:
That's another easy one. The test assumes that all platforms have -lrt
and that all platforms have to link with it for this test. Your system
clearly doesn't have -lrt, so the link fails. If you just delete the
line
that adds in -lrt, I'll
Generating a CC to the list:
On Wed Sep 10 16:07:58 2008, szbalint wrote:
This TODO doesn't really make sense because the tests which would need
to create proper temporary files do not actually create any files, they
just read some and parse.
Therefor I think this ticket can be resolved
On Wed Sep 10 16:07:58 2008, szbalint wrote:
This TODO doesn't really make sense because the tests which would need
to create proper temporary files do not actually create any files, they
just read some and parse.
Therefor I think this ticket can be resolved simply by removing the text
from
Michael, Coke: Has this problem been fixed? If so, Coke, can you close
the ticket?
thanks.
kid51
Ovid: Are you still experiencing these failures?
Jonathan: Are you still tracking this ticket?
thanks.
kid51
Can someone evaluate where we stand with respect to the issues in this
ticket?
Thank you very much.
kid51
Can someone evaluate where we stand with respect to the issues in this RT?
Thank you very much.
kid51
Clark,
We're now at Parrot 0.7. Are you still getting these test failures with
that version (or with HEAD from svn)?
Can anyone else reproduce these errors?
Thank you very much.
kid51
Coke, particle: Where do we stand on this ticket?
thank you very much.
kid51
Patrick:
Where do we stand in the deprecation cycle re these three methods?
Thank you very much.
kid51
Coke, particle: Can we get an update on the issues raised in this RT?
Thank you very much.
kid51
Clark,
Are you still getting these failures in the latest version/revision of
Parrot?
Thank you very much.
kid51
On Sun Apr 20 18:38:22 2008, [EMAIL PROTECTED] wrote:
This ticket exists to track progress on the M2 Bytecode format
milestone. Work on this milestone is occurring in the pdd13pmc
branch.
I am using RT to track progress on this milestone. I will break down
the task into smaller pieces, so
On Wed, 10 Sep 2008, James Keenan via RT wrote:
On Wed Sep 10 09:30:37 2008, doughera wrote:
That's another easy one. The test assumes that all platforms have -lrt
and that all platforms have to link with it for this test. Your system
clearly doesn't have -lrt, so the link fails.
Any update on the status of issues in this ticket?
Thank you very much.
kid51
On Mon Apr 07 21:31:15 2008, coke wrote:
This has been removed in the type_ids branch.
Coke,
Can you provide any update on this deprecation and/or the type_ids branch?
Thank you very much.
kid51
31 matches
Mail list logo
