On Sat Jun 21 07:33:57 2008, [EMAIL PROTECTED] wrote:
Mark: Do you have any objection to closing this RT?
No objection here, my needs regarding g++ builds have been satisfied.
Thanks!
Mark
On Wed Jun 18 10:57:05 2008, [EMAIL PROTECTED] wrote:
On Solaris10 with sparc, during the make process I get this:
perl /home/phoebus3/ANJ/work/parrot/tools/build/pmc2c.pl --c
subproxy.pmc
Cannot restore overloading on HASH(0x286dc8) (package
Parrot::Pmc2c::Emitter) at
On Tue Jul 17 11:53:30 2007, [EMAIL PROTECTED] wrote:
src/dynext.c: In function `run_init_lib':
src/dynext.c:315: warning: cast does not match function type
src/dynext.c:322: warning: cast does not match function type
The code looks nasty, but innocent:
315:load_func = (PMC *
On Fri May 23 07:57:11 2008, julianalbo wrote:
Reopened waiting for testing and commiting the patch to sove the problems.
All tests successful on linux/amd64.
Mark
On Fri May 23 15:30:15 2008, [EMAIL PROTECTED] wrote:
Thanks for reporting, attached patch (+ 'make Makefile') fixes this
for me.
Thanks, applied in r27775.
On Mon Jan 28 18:20:11 2008, infinoid wrote:
On Fri Jan 25 15:10:50 2008, ajr wrote:
Hi, Alan! What kind of CPU do you have? If you have an AMD Athlon XP
(or something of similar lineage), I think I know what the problem is.
I think you've nailed it: Athlon XP-M.
Hi,
I have
On Sat Apr 19 11:08:47 2008, [EMAIL PROTECTED] wrote:
On Saturday 19 April 2008 09:31:12 Mark Glines wrote:
I'm hoping someone familiar with
the internals can review this, to make sure I haven't just created a
memory leak.
The patch is correct.
Thanks for the review. Checked in as
On Mon Apr 14 21:50:00 2008, infinoid wrote:
At first glance, the only difference I can see is that your cast removes
the const attribute. But instead of doing that, I'm wondering if
maybe the second argument of VTABLE_isa(interp, pmc, name) should be
made const, instead. Would that help the
On Wed Apr 16 14:34:05 2008, geoff wrote:
Now that 0.6.1 is out, please consider adding the attached patch to the
Parrot trunk ... I'd like help with platform porting concerns, and I'd
really like to reduce the size of my local diffs. :-)
Here's what I get on linux/amd64:
Determining if
On Thu Apr 17 21:14:44 2008, geoff wrote:
OK, try the attached version of the patch.
Works For Me. So now lets see how much it breaks for everyone else. :)
Applied in r27022, with the following modifications:
* Removed trailing whitespace to pass codingstd test.
* Rearranged
On Mon Apr 14 12:20:52 2008, infinoid wrote:
Issue resolved due to closure request from submitter. Thanks!
Sorry, I should turn my brain on. Ticket reopened pending confirmation.
tewk: does this issue still exist for you? I've confirmed that Senaka's
Ubuntu Gutsy machine detects backtrace()
On Mon Apr 14 04:50:02 2008, [EMAIL PROTECTED] wrote:
Attaching patch No. 2 for C++ Build Issue.
Using a normal C compiler (gcc), I get this warning before this patch:
src/key.c:448: warning: passing argument 2 of 'key-vtable-isa'
discards qualifiers from pointer target type
And these warnings
On Fri Apr 04 10:50:53 2008, pmichaud wrote:
On Fri, Apr 04, 2008 at 10:06:39AM -0700, chromatic wrote:
Using CONST_STRING to build the null STRING will hurt performance
less, but
the right solution is to excise all traces of new_from_string()
throughout
the system, and then completely
On Wed Apr 09 20:52:37 2008, infinoid wrote:
I've implemented a workaround (manually specifying build rules for the
subdir files) in r26899, to keep us rolling in the meantime. Please
revert that when a real fix comes around.
And after a little more research, I've found the proper fix. GNU
On Thu Apr 10 14:16:58 2008, infinoid wrote:
Oddly, adding config/auto/macports.pm to MANIFEST didn't help. It is
copied, but I don't think this module is getting use'd, for whatever
reason.
What the heck? When I added t/steps/auto_macports-*.t to MANIFEST (in
r26916), it started working.
Additional testing note. If you try out this patch, you will need to
remove src/ops/*.c before doing a make. Otherwise ops2c won't be
re-run, and you won't actually be testing the patch.
Extra points for anyone who tests it on something other than gcc. :)
Mark
On Fri Mar 21 09:03:08 2008, [EMAIL PROTECTED] wrote:
there is a definition on my system for PARROT_HAS_SNPRINTF, but not a
definition for PARROT_HAS_C99_SNPRINTF. I assume, on first glance that
these two macros are one in the same and should be united.
They are not. Please see the code in
On Sun Apr 06 07:39:09 2008, [EMAIL PROTECTED] wrote:
Following discussion on #parrot with Infinoid, I created the 'ops2c'
branch in our SVN repository to handle refactoring of this area of the
build system. You can follow developments there with:
svn co
On Sat Mar 29 15:54:09 2008, [EMAIL PROTECTED] wrote:
I ran a fulltest with this patch applied, and everything's fine on x86
(where it matters).
Hi,
The root.in portion of this patch breaks non-i386, JIT capable
platforms. Problem is, the patch created an exec_dep.c for i386, but
added a
On Fri Mar 21 11:15:51 2008, [EMAIL PROTECTED] wrote:
1) Calling _dup() instead of the deprecated dup() in src/io/io.c, and
src/io/io_unix.c
2) Created macro PIO_DUP_FD(x) to handle duplication and typecasting
(may be overkill)
3) Used PIO_DUP_FD(x) in src/io/io.c to help alleviate warnings
On Mon Mar 17 15:55:32 2008, infinoid wrote:
114 (void)MD5_Init(c);
(gdb) print c
$1 = (MD5_CTX *) 0x0
(gdb)
PMC_data(SELF) is set by md5.pmc's init() function. I have verified
(with gdb breakpoints) that Parrot_MD5_init() is being called when
running t/dynpmc/digest_9.pir with
On Mon Mar 17 14:56:26 2008, bernhard wrote:
On So. 16. Mär. 2008, 06:57:31, bernhard wrote:
Hi,
running 'make fulltest' under Linux leaves me with segfaults for
gdbmhast.t.
This happens only for the computed-goto and for the switched runcore.
[EMAIL
On Sun Mar 16 10:17:09 2008, [EMAIL PROTECTED] wrote:
Friends,
Doing cage cleaning today, I noticed that there has been no activity in
this thread since last August. Are the issues that were under
discussion still live? Should we still be considering the various
patches?
The issue is
On Fri Jan 25 15:10:50 2008, ajr wrote:
Hi, Alan! What kind of CPU do you have? If you have an AMD Athlon XP
(or something of similar lineage), I think I know what the problem is.
I think you've nailed it: Athlon XP-M.
Hi,
I have built and sent an updated libgmp.a to the Strawberry Perl
I didn't hear back from kid51. I believe data portability doesn't
matter in this case; all that matters is that Storable at the current
rev on the current platform is able to read it's own data for the next
10 seconds or so, which seems like a valid assumption. Pmichaud and
chromatic seem to
On Wed Aug 22 09:49:20 2007, pmichaud wrote:
# Failed test (t/stm/basic_mt.t at line 168)
# Exited with error code: 134
# Received:
# src/stm/backend.c:608: failed assertion 'successp'
I get the same failure, intermittently, on dual-CPU x86. It looks like
a thread race condition, not
Hi,
Some warnings are being emitted by both msvc and gcc, which I think were
caused by this patch.
msvc:
[10:15] particle src\ops\core_ops.c(14190) : warning C4047:
'initializing' : 'op_func_t' differs
[10:15] particle in levels of indirection from 'op_func_t * '
gcc:
On Sat May 05 09:37:44 2007, particle wrote:
On 5/4/07, via RT Mark Glines parrotbug-followup !-- x -- at
parrotcode.org wrote:
* Standardize on PARROT_*_GUARD style names for these lines (some
headers used a style that looks like __PIRLEXER_H instead)
there's a problem here...
28 matches
Mail list logo
