[perl #52506] [CAGE] Refactor ops2c
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
[perl #56052] Storable issue
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 blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/_retrieve.al) line 323, at /home/phoebus3/ANJ/work/parrot/tools/build/dynpmc.pl line 200 gmake[1]: *** [all] Error 255 gmake[1]: Leaving directory `/home/phoebus3/ANJ/work/parrot/src/dynpmc' make: *** [dynpmc.dummy] Error 2 Hi, Do you happen to know whether this recently started occurring, or whether it has been the case for a while? Mark
[perl #44009] [CAGE] src/dynext.c casting warnings
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 * (*)(Interp *))D2FPTR(Parrot_dlsym(handle, cload_func_name)); 322:init_func = (void (*)(Interp *, PMC *))D2FPTR(Parrot_dlsym(handle, cinit_func_name)); Update: these warnings are gone, looks like D2FPTR has been removed from the above lines (which are now lines 361 and 370 of dynext.c). Mark
[perl #54602] [PATCH] Several changes to allow C++ compiling
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
[perl #54734] make perl6 failing on Revision: 27774 (Ubuntu 8.06)
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.
[perl #50212] Configure step fails on Windows
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 built and sent an updated libgmp.a to the Strawberry Perl maintainer (Adam Kennedy). You should see the updated library in the next release of Strawberry Perl. If that doesn't happen in a timely fashion, ask me for a copy of the updated library, and I'll forward you what I sent Adam. Well, Adam released strawberry perl 5.10.0.1 last month (April). I just tried it, and it still contains this issue. I've just sent him another ping, and I'm re-opening this ticket so I won't forget about it again. Mark
[perl #53128] PDD13PBC branch work: M2 Bytecode format milestone
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. That should, of course, read pdd13pbc. Mark
[perl #53072] [PATCH] Fix crashes in Lua, free()ing an invalid pointer
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 r27042, closing ticket. Mark
[perl #52874] Re: [bug] Build failure with G++
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 g++ case too? r27028 adds some infrastructure to allow us to constify vtable methods, and does so for the isa method. This makes the src/key.c portion of this patch unnecessary. There's a few other vtable methods that need to be consted, I will fix those up too. But this solves all the issues addressed by your patch; closing the ticket.
[perl #52988] [PATCH] OpenGL binding, part 1
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 your platform supports OpenGL...yes, GLUT 4.
...
[EMAIL PROTECTED] parrot-trunk % ./parrot examples/opengl/triangle.pir
error:imcc:Constant 'GL_MANGLE_C1' value must be a number, stringliteral
or register
in file 'opengl_defines.pasm' line 1394
included from 'examples/opengl/triangle.pir' line 1
The relevant portion of opengl_defines.pasm:
.macro_const GL_MAD_ATI 0x8968
.macro_const GL_MAGNITUDE_BIAS_NV0x8718
.macro_const GL_MAGNITUDE_SCALE_NV 0x8712
.macro_const GL_MANGLE_C1DO
.macro_const GL_MANGLE_C2This
.macro_const GL_MANGLE_C3get
.macro_const GL_MANGLE_C4get
.macro_const GL_MAP1_BINORMAL_EXT0x8446
.macro_const GL_MAP1_COLOR_4 0x0D90
.macro_const GL_MAP1_GRID_DOMAIN 0x0DD0
It looks like this is a parsing bug, caused by some weird stuff in one
of my header files. The top of my /usr/include/GL/gl_mangle.h looks
like this:
#if 0
#define GL_MANGLE_C1 DO NOT EDIT!!! - TO REGENERATE from gl.h, EXECUTE
THIS FILE IN SHELL (/bin/sh) and save the output
#define GL_MANGLE_C2 This file is used to create GL function protypes
and aliases for the function names
files=gl.h glext.h
#define GL_MANGLE_C3 get regeneration header - copy everything in this
file above the 'REGENERATE_TO_END' line
awk '!done; /^\/\*REGENERATE_TO_END/ {done=1}' $0
echo
#define GL_MANGLE_C4 get aliases
grep '^GLAPI' $files | sed -e 's/.*ENTRY gl\([^( ]*\).*$/#define
gl\1 MANGLE(\1)/' | sort | uniq
echo
echo #endif /* GL_MANGLE_H */
exit
#endif /* REGENERATION */
Pretty, huh.
Mark
[perl #52988] [PATCH] OpenGL binding, part 1
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 config/gen/opengl.pm a bit, so that the POD snippets occur in the same order as it will occur in the output, to pass perlcritic.t and pod.t. Mark
[perl #50068] [BUG] Configure doesn't detect backtrace* on ubuntu gutsy
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() just fine: (12:25:12 PM) Senaka: Determining whether libc has the backtrace* functions (glibc only).yes.
[perl #52874] Re: [bug] Build failure with G++
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 after this patch: src/key.c:448: warning: cast discards qualifiers from pointer target type src/key.c:448: warning: cast discards qualifiers from pointer target type 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 g++ case too? Mark
[perl #47011] [DEPRECATED] VTABLE entry 'new_from_string'
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 forget it ever existed. Correct. Perhaps this ticket should be merged with RT#47011 , which talks about new_from_string() being deprecated? (Or at least link to that ticket.) Ok, I've merged #52462 (regarding brokenness in the implementation of new_from_string) into #47011 (regarding deprecation of new_from_string). Note the brokenness is still causing the testsuite to hang for me when I configure Parrot with --gc=libc. Mark
[perl #52680] [BUG]: 'make' failure on Linux; possibly TGE-related
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 Make was ignoring the .pir.pbc rule (regardless of whether it was in a subdir or not) because it didn't recognise those file suffixes. With an added .SUFFIXES line, all works fine. So, fixed in r26901. Mark
[perl #52712] Build broken
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. So, uh, fixed in r26916 and r26914. Though I have no idea why r26916 fixed it and r26914 didn't. Mark
[perl #52506] [PATCH] Refactor ops2c
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
[perl #51980] [PATCH] fixed multiple redefines of snprintf macro
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 config/auto/snprintf/test.in - this is a C program built and run by Configure.pl, to determine which flavor of snprintf exists on a platform. The semantics of the return value differ. So I don't think we should unite those two definitions. Were there some warnings you were trying to fix? If so, what were the warnings? We can try to find another way to fix them; please reopen the ticket if this is the case. Mark
[perl #52506] [PATCH] Refactor ops2c
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 https://svn.perl.org/parrot/branches/ops2c In that branch, I have applied Infinoid's patch to lib/Parrot/Ops2c/Utils.pm. On Debian Linux, I have configured, built and tested through 'make test' and everything is passing. So, so far, everything is cool. More to come. Ok. The branch is now at r26827, and I feel like I've run out of hammers to hit this code with. Here's what I've done: * Move all the filehandling/opening/closing/renaming nonsense into a new function, print_c_source_file(). This complements print_c_header_file, and removes all the weird filehandle juggling stuff. * Update t/tools/ops2cutils/ accordingly. * Reorganize the file so public methods are on top. * Fix a few things in the POD. I think a TODO list would help at this point. Here are some possibilities I can think of (but don't necessarily feel very strongly about): * Honestly, I'm not really sure print_c_source_top and print_c_source_bottom need to be public methods any more. In fact, they could be merged into print_c_source_file entirely. But separating the filehandling from the printing is useful for testing... maybe they should be merged into a print_c_source_contents, or some such. * We ought to reduce the amount of boilerplate in t/tools/ops2cutils/. I changed the API of 2 functions, and had to update 5 or 6 places in the test suite. * Speaking of the test suite, is execution between Configure.pl and make really necessary? Some of the errors I was getting seemed to indicate it was generating temporary directories, so the documentation in these tests might be misleading. * So far I've been ignoring the private methods as much as possible. But they could probably use a once-over. * Even though new() delegates a lot of the work to _iterate_over_ops, it is still ginormous. Maybe it should delegate more? Its length is not necessarily a bad thing, but it makes it harder for me to understand what's going on. * Should probably get someone to test it on win32/msvc. Is there anything else that's been bugging people about this code? Mark
[perl #47289] [PATCH] Move executable code out of jit/i386/exec_dep.h
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 Makefile dependency for $(SRC_DIR)/exec_dep.c on *ALL* platforms, and that file doesn't exist anywhere except for x86. So, tetragon is now reporting on IRC that builds fail on ppc. Sounds like reverting r26636 will result in a successful build... testing that now. Mark
[perl #51988] [PATCH] file descriptor duplication updates
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 4) Added a typecast from an integer to a PIOHANDLE to help alleviate a warning about a comparison. I've committed a patch similar to this as 26548. The macro is called Parrot_dup, and src/io/io.c and src/io/io_unix.c call that. The main difference is, it's only defined to _dup on Win32/MSVC; all other platforms still just call dup(). Hope it works. Feel free to reopen this ticket if it doesn't get all the warnings.
[perl #51790] Segfaults for GDBMHash and MD5 in -C and -S runcores
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 most runcores, but it is *not* being called when run under the -C or -S runcore. That seems like a Bad Thing. Mark
[perl #51790] Segfaults for GDBMHash and MD5 in -C and -S runcores
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 PROTECTED]:~/devel/Parrot/trunk$ uname -a
Linux heist 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686
GNU/Linux
The same symptoms show with
./parrot -C t/dynpmc/digest_9.pir
and
./parrot -S t/dynpmc/digest_9.pir
I am seeing this with GDBMHash and MD5 too, on both x86 and x86-64
platforms.
% gdb parrot
[snip]
(gdb) run -C t/dynpmc/digest_9.pir
Starting program: /home/paranoid/parrot/parrot -C t/dynpmc/digest_9.pir
[Thread debugging using libthread_db enabled]
[New process 25304]
warning: Lowest section in /usr/lib64/libicudata.so.38 is .hash at
0190
[New Thread 47559694358496 (LWP 25304)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47559694358496 (LWP 25304)]
0x2b4159e44b20 in MD5_Init () from /usr/lib/libcrypto.so.0.9.8
(gdb) bt
#0 0x2b4159e44b20 in MD5_Init () from /usr/lib/libcrypto.so.0.9.8
#1 0x2b415ab61ad4 in Parrot_MD5_nci_MD5_Init (interp=0x60a010,
pmc=0x9885c0) at ./md5.pmc:114
#2 0x2b415760bf75 in Parrot_NCI_invoke (interp=0x60a010,
pmc=0x9885c0, next=0x9a97c0) at ./src/pmc/nci.pmc:203
#3 0x2b41575afa81 in cgp_core (cur_op=0x9a8100, interp=0x60a010) at
src/ops/object.ops:78
#4 0x2b4157515222 in runops_cgp (interp=0x60a010, pc=0x9a9750) at
src/interpreter.c:776
#5 0x2b41575154fd in runops_int (interp=0x60a010, offset=0) at
src/interpreter.c:916
#6 0x2b4157515f80 in runops (interp=0x60a010, offs=0) at
src/inter_run.c:104
#7 0x2b4157516218 in runops_args (interp=0x60a010, sub=0x988eb8,
obj=0x654fa0, meth_unused=0x0, sig=0x2b41576f7e4b vP,
ap=0x7fff539bfaf0) at src/inter_run.c:230
#8 0x2b415751640b in Parrot_runops_fromc_args (interp=0x60a010,
sub=0x988eb8, sig=0x2b41576f7e4b vP) at src/inter_run.c:299
#9 0x2b41574fb93e in Parrot_runcode (interp=0x60a010, argc=1,
argv=0x7fff539bfde8) at src/embed.c:941
#10 0x2b41576d2658 in imcc_run_pbc (interp=0x60a010, obj_file=0,
output_file=0x0, argc=1, argv=0x7fff539bfde8) at compilers/imcc/main.c:794
#11 0x2b41576d2f57 in imcc_run (interp=0x60a010,
sourcefile=0x7fff539c074a t/dynpmc/digest_9.pir, argc=1,
argv=0x7fff539bfde8) at compilers/imcc/main.c:1080
#12 0x00400b45 in main (argc=1, argv=0x7fff539bfde8) at
src/main.c:56
(gdb) up
#1 0x2b415ab61ad4 in Parrot_MD5_nci_MD5_Init (interp=0x60a010,
pmc=0x9885c0) at ./md5.pmc:114
114 (void)MD5_Init(c);
(gdb) print c
$1 = (MD5_CTX *) 0x0
(gdb)
When run without -C or -S, the c pointer is non-null and execution
proceeds normally.
For the gdbmhash_3.pir test, the pointer is not null (otherwise the
null-check in the pmc sources would catch it), but it seems to point to
corrupt data. gdbm.h takes measures to prevent introspection , but the
first integer in the fake array is a pointer to the filename, which is
what I'm testing below.
Here's what it looks like with the default runcore:
149 for (key = gdbm_firstkey(dbf); key.dptr; key =
nextkey) {
(gdb) print *dbf
$2 = {dummy = {136637904, 3, 1, 0, 0, 1, 0, 6, 136580112, 136584216}}
(gdb) print (char*)136637904
$3 = 0x824edd0 gdbm_hash_1
And here's what it looks like with the CGP runcore:
149 for (key = gdbm_firstkey(dbf); key.dptr; key =
nextkey) {
(gdb) print *dbf
$5 = {dummy = {136521688, 0, 524288, 0, 0, 0, 0, 136521716, 0, 512}}
(gdb) print (char*)136521688
$6 = 0x82327d8 '#\b
Mark
[perl #37287] [TODO] pdb - don't die on exceptions
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 still valid, but my patch from last year does not help much to solve it. You can reproduce the bug with the test.pir I attached last August, and by running the following commands: $ make pdb $ ./pdb test.pir (pdb) r The issue is that pdb does not catch an exception. Instead, the exception crashes pdb. Fixing pdb to catch exceptions cleanly would make pdb significantly more useful as a debugger, I think. Mark
[perl #50212] Configure step fails on Windows
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 maintainer (Adam Kennedy). GMP lets you specify (via the --enable-fat ./configure option) that it should build for all possible processor types, and choose the right set of functions at runtime. But it sounds like this didn't actually work in versions older than 4.2.2, or maybe they just didn't build it this way last time. You should see the updated library in the next release of Strawberry Perl. If that doesn't happen in a timely fashion, ask me for a copy of the updated library, and I'll forward you what I sent Adam. Whatever happened, GMP is now detected successfully and parrot configures for me without incident. (And it wasn't Parrot's fault to begin with.) So I am marking this ticket as resolved.
[perl #44809] [PATCH] use Storable instead of Data::Dumper for PMC .dump files
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 agree with me. Applied in r20809. I will happily fix any problems that come up; please let me know if my assumptions are invalid, or if it breaks anywhere.
[perl #44865] [BUG] t/stm/basic_mt.t fails on x86_64
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 specific to x86_64. t/stm/basic_mtNOK 3/4 # Failed test (t/stm/basic_mt.t at line 161) # Exited with error code: [SIGNAL 6] # Received: # src/stm/backend.c:608: failed assertion 'successp' # Backtrace - Obtained 13 stack frames (max trace depth is 32). # Parrot_print_backtrace # Parrot_confess # (unknown) # Parrot_STM_commit # Parrot_stm_commit_ic # runops_slow_core # runops_int # runops # (unknown) # Parrot_runops_fromc_args # (unknown) # (unknown) # __clone # # Expected: # /okay/ # # Looks like you failed 1 test of 4.
[perl #42795] [PATCH] NULL function pointer should be a pointer
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: src/ops/core_ops.c:14190: warning: initialization from incompatible pointer type The line in question is trying to NULL-terminate an array of op_func_t's. The issue is that op_func_t is *already* a pointer type, and this patch changed a function pointer into a pointer to a function pointer. Here's how op_func_t is declared: typedef opcode_t *(*op_func_t)(opcode_t *, Interp *); Steve, does the patch you submitted fix anything for you? (In other words, will it break anything to revert this?) Mark
[perl #42883] [PATCH] Fix up headerfile guards
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... compilers/imcc/pirlexer.h is a *generated* header file. yeah, I patched compilers/pirc/src/pirlexer.h, not compilers/imcc/pirlexer.h. In fact, I'm having difficulty finding a compilers/imcc/pirlexer.h file, even after a fresh build, so I'm confused. Mark
