Parrot 1.2.0 Bird Brain released!
On behalf of the Parrot team, I'm proud to announce Parrot 1.2.0 Bird Brain. Parrot (http://parrot.org/) is a virtual machine aimed at running all dynamic languages. Parrot 1.2.0 is available on Parrot's FTP site, or follow the download instructions at http://parrot.org/download. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on the source code repository to get the latest and best Parrot code. Parrot 1.2.0 News: - Core + Fixes for pir classes inheriting from core pmcs. + Cleaned up headers and reorganized some sources into subsystem directories. + Clean up PMCs so libparrot.so exports far fewer vtable/method symbols. + Clean up the GC API. + Several unicode identifier improvements in IMCC. - Deprecations + Protoobject stringification is gone. - Documentation + Rewrite several core documents. + Many reworks, improvements additions to the Parrot Book. + Installation PDD is launched out of draft. - Tools + Fixes for running the language shell generator outside the parrot tree. + Several fixes for developing and building HLLs from an installed parrot. + Configure.pl now has a --no-line-directives option to ease source level debugging. - Miscellaneous + Portability updates for macports, netbsd, mingw32, hpux. + Several (build time, runtime) performance improvements. + Lots of updates to examples and tests. + Various bugfixes, code cleanups, and coding standard fixes. Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 16 June 2009. Enjoy!
Re: Parrot_str_find_cclass() Slowness (and a possible solution)
chromatic wrote: We'd have to add a function to the encoding API and change Parrot_str_find_cclass() to perform this, but that should be an hour of work for an enterprising hacker for a surprising performance improvement. It's relatively low-risk as well, so if someone can do it in the next 12 hours, it may be worth including in Tuesday's release. Implemented as r38853. Looks like it shaved about 8 seconds off the time it takes to build rakudo on my laptop. Mark
Re: [perl #63626] Re: bouncing parrot...@parrotcode.org
Geoffrey Broadwell wrote: Out of curiosity, why don't we allow emails to create tickets in Trac? There's a plugin to do this, called email2trac. It's being set up, but doesn't work yet. See TT #49. Mark
Re: [perl #62202] Problem with Configure.PL under Windows
Alan Rocker (via RT) wrote: auto::gmp - Does your platform support GMP...Can't spawn .\test_616.exe: Bad file descriptor at lib/Parrot/Configure/Utils.pm line 86. Thanks, this is a known issue with the libgmp.dll built with strawberry perl. (It was built with SSE2 instructions that aren't supported by several classes of x86 processor, including my AMD Athlon XP.) I bugged Alias about this a couple of times and even built and sent him a known good library to replace it with, but the issue is still present in strawberry perl. Merging #62202 into #50212. Mark
Re: [perl #62010] [PATCH] fix PARROT_EXPORT visibility=default for gcc other than 4.x
donald.hun...@gmail.com wrote: I was pretty averse to adding an additional configure step myself. The problem is that warnings.pm checks specifically for supported compiler flags and I didn't want to include other things there. The bug is that gcc.pm is hardcoded for version 4.x rather than checking. I didn't want to add a duplicate check for -fvisibility=hidden in this file. As I understand it, -fvisibility=hidden goes hand in hand with __attribute__((visibility(default) so a single check covers both. If you want to implement the fix as an explicit check for __attribute__((visibility(default) in gcc.pm then that would work. Perhaps the simplest thing to do is just move my check into warnings.pm after all. My guess is that it's never right to use -fvisibility=hidden without also using __attribute__ ... so if one is used then the other needs to be as well. That seems to be the best argument for keeping them in the same place. Is there any version of gcc which accepts -fvisibility=hidden but not __attribute__((visibility(default)))? If not, then I'm worrying about nothing, and we can probably just use the existing check for both. But I agree, neither of these features makes much sense without the other. Mark
Re: fudging the headerizer
Andy Lester wrote: This patch http://www.parrotvm.org/svn/parrot/revision?rev=34423 is not a long-term solution. The headerizer has to get run at will. Infinoid, can you tell me more about those ifdefs so I can make the headerizer happy? Happy to. The functions in question (is_ins_save and _is_ins_save) are declared as static, but conditionally defined inside of an #ifdef. If the prototypes are not put in the same #ifdefs, the following warnings result: compilers/imcc/optimizer.c:87: warning: '_is_ins_save' declared 'static' but never defined compilers/imcc/optimizer.c:153: warning: 'is_ins_save' declared 'static' but never defined This has shown up a couple of times in RT, most recently as #53990. Mark
Re: [perl #59680] Build error: tools/build/ops2pm.pl: Could not mkdir /home/moritz/src/parrot/lib/Parrot/OpLib: File exists!
Will Coleda wrote: On Tue, Nov 25, 2008 at 2:18 PM, Mark Glines via RT [EMAIL PROTECTED] wrote: On Sat Oct 18 12:13:51 2008, [EMAIL PROTECTED] wrote: There's a race condition, if that directory doesn't exist and multiple processes execute that code simultaneously. Fortunately, Parrot::Ops2pm::print_module() creates that directly when it writes Parrot::OpLib::core -- the only file in that directory. Fixed in r32016. Hi, I'm still seeing this race occur, about once every hundred builds. r33196 contains a simple workaround (if mkpath failed, but the directory now exists, someone else created it, so silently continue). Mark Can we avoid this issue by just shipping an empty svn directory? That's one possibility, maybe with a .keep file or whatever to keep git happy. Another solution I considered is to make the ops rules in the Makefile depend on some make-the-directory rule, to keep the ordering straight. However, r33196 seemed like the simplest possible solution, and it won't have any effect at all when the race condition didn't occur (which seems like about 99% of the time), so that's the one I checked in. Feel free to revert it if a different solution is preferred. Mark
Re: [perl #60642] [CAGE] add a codingstd test to ensure TODOed tests have an RT ticket number
James Keenan via RT wrote: On Wed Nov 19 23:13:27 2008, [EMAIL PROTECTED] wrote: James Keenan via RT wrote: On Tue Nov 18 10:22:25 2008, [EMAIL PROTECTED] wrote: This will probably be quite challenging. Let's assume that all tests are found in files with names ending in '.t'. Those .t files can be written in any language, which probably have different ways of classifying a test as TODO. My count tonight is that 1384 .t files in the distribution. Of these 524 are *not* found under ./languages/. I wonder if we could formulate the specification in this ticket a bit more precisely before someone embarks on coding. Yes, absolutely. I just added the basic ticket on the spur of the moment, to make sure I didn't forget about it. I've been thinking about this. A few things come to mind, for instance detecting the language based on the hashbang (if any) or subdirectory it's in, and invoking a language-specific parser. And detecting the cases we can't handle, and skipping those. But to me that sounds like way too much work. It doesn't really matter to me whether the ticket number occurs within the TODO output string, a nearby comment is good enough for me. So how about skipping all the above nonsense and just ignoring the test language entirely? How about a simple regex-based test that tallies all instances of /TODO/ in the set of test files, skipping the lines that start with obvious comment characters, and for each instance, looks for a match of /#\d+/? It can even expand the search to also look a couple lines above and below the TODO line, for additional flexibility. I think that should be reasonable for most, if not all, possible test languages. Do you think that would catch all the cases? Two thoughts: 1. We already have code that can detect the existence of TODO in certain kinds of files. Cf. t/codingstd/fixme.t. Paul Cochrane used that a couple of years back to generate hundreds of RTs -- most of which are probably still outstanding. Can we leverage that Parrot::Distribution-based code? I'm sure we can. Though I'm not really sure why the test you mention is limited to only checking C sources. In fact, PDD07 says: If a bug must be fixed soon, use XXX and put a ticket in the bug tracking system. This means that each XXX should have an RT ticket number next to it. As such, we might just extend fixme.t to look for a nearby ticket number, and fail if it can't find one. And do this everywhere, not just C sources or tests. (PDD07 doesn't seem to be talking about code written in a particular language, here.) This sounds quite doable to me, and if it sounds reasonable to everyone else, I'll take a shot at it this evening just to see how badly it breaks. It does also raise the question of how to disambiguate between RT and trac tickets mentioned within the parrot sources. We could just use /#\d+/ for both, which makes the test happy, but then humans won't know where to go find the ticket. Mark
Re: [perl #60642] [CAGE] add a codingstd test to ensure TODOed tests have an RT ticket number
James Keenan via RT wrote: On Tue Nov 18 10:22:25 2008, [EMAIL PROTECTED] wrote: This will probably be quite challenging. Let's assume that all tests are found in files with names ending in '.t'. Those .t files can be written in any language, which probably have different ways of classifying a test as TODO. My count tonight is that 1384 .t files in the distribution. Of these 524 are *not* found under ./languages/. I wonder if we could formulate the specification in this ticket a bit more precisely before someone embarks on coding. Yes, absolutely. I just added the basic ticket on the spur of the moment, to make sure I didn't forget about it. I've been thinking about this. A few things come to mind, for instance detecting the language based on the hashbang (if any) or subdirectory it's in, and invoking a language-specific parser. And detecting the cases we can't handle, and skipping those. But to me that sounds like way too much work. It doesn't really matter to me whether the ticket number occurs within the TODO output string, a nearby comment is good enough for me. So how about skipping all the above nonsense and just ignoring the test language entirely? How about a simple regex-based test that tallies all instances of /TODO/ in the set of test files, skipping the lines that start with obvious comment characters, and for each instance, looks for a match of /#\d+/? It can even expand the search to also look a couple lines above and below the TODO line, for additional flexibility. I think that should be reasonable for most, if not all, possible test languages. Do you think that would catch all the cases? It's a heck of a lot more feasable, it would work in every example I can think of (except maybe Befunge), and it seems flexible enough to deal with languages we haven't thought up yet. So I guess I'm seriously proposing this. Looking forward to your opinion, Mark
Re: [perl #60068] [BUG] t/pmc/packfile.t: set_integer_keyed_str test failing on Darwin PPC
[oops, forgot to copy the list.] If darwin has gdb, you can do the following to get a backtrace: $ gdb parrot gdb run t/pmc/packfile_6.pir [segfault should occur here] gdb bt Mark
Re: [perl #59880] DOD crash in r31926, t/op/bitwise.t #27 on linux/x86_64
chromatic wrote:
2) What's setting an invalid pointer-to-a-PMC here?
This question is answered at the end of the following dump. (This is
one of the things I nopasted during our IRC discussion last week, thanks
for your guidance in producing it.)
One interesting question: the pointer-to-a-PMC is written a couple times
by the CPointer class, and then written by BigInt once. Was that expected?
(By the way, I've also reproduced this on one of the x86-32 gentoo boxes
I tried it on, so it is not x86-64 specific. It is also not specific to
one version of gcc.)
(gdb) break src/headers.c:324 if ((long)pmc 0xfff) == 0xde8
No source file named src/headers.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (src/headers.c:324 if ((long)pmc 0xfff) == 0xde8) pending.
(gdb) run t/op/bitwise_27.pir
Starting program: /work/parrot-dev/parrot-trunk/parrot t/op/bitwise_27.pir
[Thread debugging using libthread_db enabled]
warning: Lowest section in /usr/lib64/libicudata.so.38 is .hash at
0190
[New Thread 0x7f3245daf710 (LWP 1013)]
[Switching to Thread 0x7f3245daf710 (LWP 1013)]
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=1024)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=1024)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=5120)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=5120)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=0) at
src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=1024)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=1024)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=0) at
src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=1024)
at src/headers.c:324
324 if (!pmc)
(gdb) bt
#0 new_pmc_header (interp=0x13bd080, flags=1024) at src/headers.c:324
#1 0x7f3245753f78 in get_new_pmc_header (interp=0x13bd080,
base_type=52,
flags=1024) at src/pmc.c:267
#2 0x7f3245753bc3 in pmc_new (interp=0x13bd080, base_type=52)
at src/pmc.c:92
#3 0x7f324571ce74 in Parrot_build_sig_object_from_varargs (
interp=0x13bd080, sig=0x7f3245988b33 PPP-P, args=0x7fff4df4d770)
at src/multidispatch.c:477
#4 0x7f324571d5c6 in Parrot_mmd_multi_dispatch_from_c_args (
interp=0x13bd080, name=0x7f3245989310 modulus,
sig=0x7f3245988b33 PPP-P) at src/multidispatch.c:574
#5 0x7f32457fe59f in Parrot_default_modulus (interp=0x13bd080,
pmc=0x1517f00, value=0x1496a08, dest=0x1495e70)
at ./src/pmc/default.pmc:1673
#6 0x7f32456afaf8 in Parrot_mod_p_p_p (cur_opcode=0x15176a0,
interp=0x13bd080) at src/ops/math.ops:760
#7 0x7f3245754c2f in runops_slow_core (interp=0x13bd080, pc=0x15176a0)
at src/runops_cores.c:222
#8 0x7f3245714ed4 in runops_int (interp=0x13bd080, offset=0)
at src/interpreter.c:937
#9 0x7f32457158c3 in runops (interp=0x13bd080, offs=0)
at src/inter_run.c:101
#10 0x7f3245715b7a in runops_args (interp=0x13bd080, sub=0x14978b0,
obj=0x144a020, meth_unused=0x0, sig=0x7f324597fcfb vP,
ap=0x7fff4df4da40)
at src/inter_run.c:236
#11 0x7f3245715d6b in Parrot_runops_fromc_args (interp=0x13bd080,
sub=0x14978b0, sig=0x7f324597fcfb vP) at src/inter_run.c:300
#12 0x7f32456f781e in Parrot_runcode (interp=0x13bd080, argc=1,
argv=0x7fff4df4dd20) at src/embed.c:951
#13 0x7f3245958f38 in imcc_run_pbc (interp=0x13bd080, obj_file=0,
output_file=0x0, argc=1, argv=0x7fff4df4dd20) at
compilers/imcc/main.c:791
#14 0x7f3245959837 in imcc_run (interp=0x13bd080,
sourcefile=0x7fff4df4e165 t/op/bitwise_27.pir, argc=1,
argv=0x7fff4df4dd20) at compilers/imcc/main.c:1079
#15 0x00400c64 in main (argc=1, argv=0x7fff4df4dd20) at
src/main.c:61
(gdb) step
329 if (flags PObj_is_PMC_EXT_FLAG) {
(gdb)
330 flags |= PObj_is_special_PMC_FLAG;
(gdb)
331 pmc-pmc_ext = new_pmc_ext(interp);
(gdb)
new_pmc_ext (interp=0x13bd080) at src/headers.c:363
363 Small_Object_Pool * const pool =
interp-arena_base-pmc_ext_pool;
(gdb)
366 return (PMC_EXT *)pool-get_free_object(interp, pool);
(gdb)
gc_ms_get_free_pmc_ext (interp=0x13bd080, pool=0x13be7e0)
at src/gc/smallobject.c:275
275 PMC_EXT *free_list = (PMC_EXT *)pool-free_list;
(gdb)
278 if (!free_list) {
(gdb)
283 ptr = free_list;
(gdb)
284 pool-free_list = ptr-_next_for_GC;
(gdb)
285 ptr-_next_for_GC = NULL;
(gdb)
287
Re: [perl #59880] DOD crash in r31926, t/op/bitwise.t #27 on linux/x86_64
On Tuesday 14 October 2008 07:14:51 Mark Glines wrote: On Monday 13 October 2008 16:15:54 chromatic wrote: That's pretty clearly not a PMC. Can you use the breakpoint technique to figure out 1) What creates this CPointer PMC and In the following dump, the offending PMC ix 0x1731de8. The arena's base pointer varies every time, but I seem to be able to catch it with a pointer suffix check. Yes, I'm an idiot. I meant 0x20f3de8 of course. I've run through this several times, and like I said, it keeps changing... Breakpoint 3, Parrot_CPointer_init (interp=0x1f99080, pmc=0x20f3de8) -- Mark
Re: [perl #57608] [PATCH] add ports/cygwin
On Tuesday 05 August 2008 20:57:53 chromatic wrote: On Tuesday 05 August 2008 01:35:48 Reini Urban wrote: Attached patch adds the directory ports/cygwin with the most recent cygports file, the most recent src patch and the sources for the CYGWIN patches. (the contents of parrot-0.6.4-2.cygwin.patch which creates those files in CYGWIN-PATCHES/) Thanks, applied as r30048. This patch causes t/codingstd/filenames.t to fail (because the filename has multiple dots). Perhaps an exception should be made in this case? Mark
Re: [perl #57358] Enable parallel testing
On Monday 28 July 2008 09:52:36 Moritz Lenz wrote: t/steps/auto_attributes-01.t (Wstat: 65280 Tests: 9 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 12 tests but ran 9. t/steps/auto_headers-03.t (Wstat: 65280 Tests: 8 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 12 tests but ran 8. If there are interdependencies (or setup/teardown constraints) between those series of tests, maybe we could just merge each series into a single test script? Mark
Re: [perl #57188] [PATCH] pbc_to_exe --install
On Tuesday 22 July 2008 04:56:53 Reini Urban wrote: Attached patch adds --install to pbc_to_exe, adds a basic pod to pbc_to_exe, and applies --install to perl6. link against install_config.o and add installable prefix. Limitation: With --install the first arg infile must have no directory part! Now we can generate make install for the languages. Hi! When I try to apply your patch, I get: [EMAIL PROTECTED] parrot-trunk % patch -p0 ~/Desktop/installable_pbc_to_exe.patch patching file languages/perl6/config/makefiles/root.in patching file tools/dev/pbc_to_exe_gen.pl misordered hunks! output would be garbled Hunk #4 FAILED at 11. misordered hunks! output would be garbled Hunk #5 FAILED at 70. misordered hunks! output would be garbled Hunk #6 FAILED at 318. 3 out of 10 hunks FAILED -- saving rejects to file tools/dev/pbc_to_exe_gen.pl.rej Any chance of getting an in-order diff? If not, could you just attach your pbc_to_exe_gen.pl? Thanks, Mark
Re: Inter-HLL Mapping Notes
On Tuesday 22 July 2008 15:37:33 chromatic wrote: The wiki page at: http://www.perlfoundation.org/parrot/index.cgi?inter_hll_mapping_not es seems to be missing the rationale for *why* it's necessary to map types between languages? (Also see If Perl 6 has to care about the internal storage format of an Integer PMC, it's doing something very wrong.) Integer is a good example of the problem, actually. The internal storage format doesn't change, but the methods you can call on it definitely will. HLLs wrap the Integer class with their own subclasses, so that they have methods they can call on integers, which are expected by the HLL. But when your perl6 function passes a Perl6Int to a TCL function, TCL HLL code code will try to access the integer, but it's not a TclInt, its a Perl6Int! The value itself is fine, but the methods it expects to find will not be there. Hence the need for conversion/mapping. -- Mark
Re: [svn:parrot] r29610 - in branches/pdd13pbc: src/pmc t/pmc
On Saturday 19 July 2008 11:19:27 chromatic wrote: Poking at strings directly seems unclean; do we need to add another function to src/packfile.c to return a packed packfile as a C string, and then create the string directly here in get_string()? I agree, poking around in STRING internals isn't clean, or fun. (Also, the quoted code gets a nice segfault later on because the encoding and charset weren't initialized.) I don't know that a separate function is necessary... I could just allocate the buffer and then wrap a STRING around that afterwards. I will make that change once I've sorted out a couple of other issues, probably later today. As an aside, what's with PARROT_BINARY_CHARSET? It sounds like that's what my strings need to be using for holding binary data, but the comparison function always returns 0. Am I misunderstanding what the binary charset plugin is for? It doesn't look like it's used very often. -- Mark
[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
Re: [perl #56052] Storable issue
On Thursday 19 June 2008 16:46:23 chromatic wrote: On Thursday 19 June 2008 12:40:49 Andrew Johnson wrote: No, sorry. I first saw the problem a couple of weeks ago, but that was my first attempt to build on this platform. The simplest solution is probably to raise the minimum required version of Perl from 5.8.0 (as listed in README) to whichever version has Storable fixed (certainly on Solaris 10 with Perl 5.8.8 it works fine). I think 5.8.1 is okay (and certainly a five year old version of Perl isn't too onerous a burden, especially given some of our other dependencies). I haven't had a chance to install the various revs of perl and try them yet, but ... Looking at Storable.xs in the various perl revs, it looks like 5.8.4 is the earliest version of perl which won't have this issue. If that isn't an acceptable requirement for parrot, I can try to figure out how to make the pmc2c data structures more compatible, so the older versions of Storable can serialize them properly. 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
Re: [perl #55530] OpenGL configure step emits a large number of warnings
On Monday 09 June 2008 22:26:10 Geoffrey Broadwell wrote: This is on a Gentoo linux amd64 machine, with Parrot trunk r28204, and an unstable (git) version of mesa built from the x11 overlay. Is this normal? Nope, not normal. Try the attached patch. It's an update of the patch in #55228; I'll update that RT in a moment. Looks good. Opengl now configures, builds and runs cleanly. 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.
Re: [perl #54602] [PATCH] Several changes to allow C++ compiling
On Wednesday 21 May 2008 13:04:29 NotFound wrote: Changed several casts and removed 'extern' is several places in congruence with the changed meaning of the macros. Hi, Sounds like this part of the patch has some portability problems. [20:19] @tetragon Hrm... exec.c lost the extern on char **Parrot_exec_rel_addr; (line 64 of exec.c) since my last successful build (I think it was r27690) [20:52] @tetragon So, r27736 broke building on my box Tetragon's platform is Mac OS X. -- Mark
[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
Re: [svn:parrot] r27314 - in branches/pdd13pbc: include/parrot src/pmc
On Sat, 3 May 2008 21:07:56 -0700 chromatic [EMAIL PROTECTED] wrote: These are Python-style exceptions, and they're going away in the concurrency branch. I suggest EXCEPTION_MALFORMED_PACKFILE instead. [snip] I'd use PMC_data() for storage instead. I'd love to see the PObj cache struct member go away. You can also use PMC_data_typed() to avoid the cast yourself. Thanks for the advice, I've made the above changes in r27315. Mark
Re: [perl #53496] Re: [bug] Build failure with G++
On Tue, 29 Apr 2008 23:05:04 -0700 chromatic [EMAIL PROTECTED] wrote: On Monday 28 April 2008 23:52:44 Senaka Fernando wrote: Attaching patch No. 2 for C++ Build Issue. I still need to resolve this bigint.c issue. This is something caused by the GMP includes I suspect. This patch didn't apply cleanly as of r27247; is it still an issue for you? This is the issue we fixed in #53112. It's weird - the timestamp on Senaka's email (according to RT) is April 14, Senaka and I are wondering if the email got stuck in a queue somewhere for 2 weeks. I've verified with him that the issue is fixed, and merged the ticket with #53112. Mark
Re: [PATCH] Rearrange PObj Struct Members
On Mon, 28 Apr 2008 10:41:27 -0700 Mark Glines [EMAIL PROTECTED] wrote: On Sun, 27 Apr 2008 17:24:53 -0700 chromatic [EMAIL PROTECTED] wrote: Here's another proposed patch for testing on various platforms. I'm trying to get rid of some dodgy casts (which likely don't help C++ and processors with stricter alignment than 32-bit x86). I'd also like to remove unnecessary members from a few structs. This is the next step. Are there any weird errors or unexpected crashes on anything more exotic than 32-bit x86 GNU/Linux? This seems to cause memory corruption on linux/amd64. Only two tests fail, the rest pass, but those are failing pretty gloriously. See attached log. gdb's backtrace is a bit easier to read. (gdb) bt #0 0x2b16911a2185 in raise () from /lib/libc.so.6 #1 0x2b16911a3630 in abort () from /lib/libc.so.6 #2 0x2b16911db96b in __libc_message () from /lib/libc.so.6 #3 0x2b16911e0b9d in malloc_printerr () from /lib/libc.so.6 #4 0x2b16911e2575 in _int_free () from /lib/libc.so.6 #5 0x2b16911e28a6 in free () from /lib/libc.so.6 #6 0x2b168ddebf6c in mem_sys_free (from=0x95d960) at src/gc/memory.c:251 #7 0x2b168ddef475 in parrot_hash_destroy (interp_unused=0x60a080, hash=0x95d960) at src/hash.c:778 #8 0x2b168df2a441 in Parrot_Hash_destroy (interp=0x60a080, pmc=0x981238) at ./src/pmc/hash.pmc:121 #9 0x2b168ddea44d in Parrot_dod_free_pmc (interp=0x60a080, pool_unused=0x60b750, p=0x981238) at src/gc/dod.c:674 #10 0x2b168ddea36b in Parrot_dod_sweep (interp=0x60a080, pool=0x60b750) at src/gc/dod.c:640 #11 0x2b168ddead53 in Parrot_dod_ms_run (interp=0x60a080, flags=4) at src/gc/dod.c:1103 #12 0x2b168ddeaec8 in Parrot_do_dod_run (interp=0x60a080, flags=4) at src/gc/dod.c:1169 #13 0x2b168ddf6cd2 in Parrot_really_destroy (interp=0x60a080, exit_code_unused=0, arg_unused=0x0) at src/inter_create.c:346 #14 0x2b168dde31e1 in Parrot_exit (interp=0x60a080, status=0) at src/exit.c:89 #15 0x00400c3e in main (argc=1, argv=0x7fff1d0d70c0) at src/main.c:66 Mark
Re: [PATCH] Rearrange PObj Struct Members
On Mon, 28 Apr 2008 11:05:45 -0700 chromatic [EMAIL PROTECTED] wrote: I had a similar problem on my 32-bit Linux system, until I added this part of the patch: === src/gc/smallobject.c == --- src/gc/smallobject.c. (revision 27223) +++ src/gc/smallobject.c. (local) @@ -523,9 +517,9 @@ free_list_end = dest-free_list; - while (*free_list_end) -free_list_end = (void **)*free_list_end; +free_list_end = PMC_struct_val((PObj *)free_list_end); - -*free_list_end = source-free_list; +PMC_struct_val((PObj *)free_list_end) = source-free_list; - /* now append source arenas */ cur_arena = source-last_Arena; So far as I can tell, your previously posted patch contains the above code changes, the only difference I can see is that this one also removes a few blank lines. So I guess the error is still in there on amd64... Mark
Re: [perl #53422] [BUG] pdump crash on intel macosx
On Mon, 28 Apr 2008 21:35:03 +0300 Laimonas Vėbra [EMAIL PROTECTED] wrote: Stephane Payrard wrote: # New Ticket Created by Stephane Payrard # Please include the string: [perl #53422] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53422 This is #53422: http://rt.perl.org/rt3/Ticket/Display.html?id=51262 You're right. Tickets merged, thanks. Mark
Re: M2 Bytecode format
On Thu, 17 Apr 2008 21:33:50 -0400 Bob Rogers [EMAIL PROTECTED] wrote: From: Mark Glines [EMAIL PROTECTED] Date: Thu, 17 Apr 2008 07:59:03 -0700 . . . Should this PMC implement the pdump functionality (src/packdump.c) as well as packfile.c/packout.c? I find pdump somewhat useful. Ok. How do you actually *build* that? There doesn't seem to be a Makefile rule for it, or maybe I just haven't found it yet. Mark
Re: M2 Bytecode format
On Sun, 27 Apr 2008 09:51:43 -0700 Mark Glines [EMAIL PROTECTED] wrote: I find pdump somewhat useful. Ok. How do you actually *build* that? There doesn't seem to be a Makefile rule for it, or maybe I just haven't found it yet. Oh, nevermind. It's there, I'm just braindead. Thanks! Mark
Re: Please check out ticket RT#39845
On Sun, 27 Apr 2008 19:25:55 +0100 Klaas-Jan Stol [EMAIL PROTECTED] wrote: Hi, Could anybody check out ticket #39845? I replied on it multiple times, but somehow the reply button is not visible anymore when I log in. http://rt.perl.org/rt3/Ticket/Display.html?id=39845 has Reply buttons. http://rt.perl.org/rt3/Public/Bug/Display.html?id=39845 doesn't. Fun, huh. I think the ticket can be closed. Looks like it... I'll close it. Thanks! Mark
Re: [perl #53406] [TODO] Add 'long long' to types supported by NCI
On Sat, 26 Apr 2008 19:18:21 -0700
Geoffrey Broadwell (via RT) [EMAIL PROTECTED] wrote:
# New Ticket Created by Geoffrey Broadwell
# Please include the string: [perl #53406]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53406
(I wish we could just insist that INTVAL be 64 bits everywhere, but
alas that doesn't make a lot of sense for very memory-constrained
environments. Though those do get rarer by the day )
In the future, INTVAL will probably be 128 bits for some platforms.
I'd really like to see a set of fixed-width types (similar to what p5
has for pack and unpack), so you have the option of native int or
exactly 32 bits or whatever you need.
HUGEINTVAL is 64 bits on both linux-x86 and linux-amd64, so it
seems like a good start. Here's an ugly patch that attempts to add it.
Problems with this patch:
1. It probably won't work on win32-x64... I seem to recall someone
mentioning HUGEINTVAL is just 32 bits there.
2. The patch adds a HUGEINTVAL to the PObj union, and would probably
require additional fixups all over parrot to be able to access the
resulting object.
The above makes me think we might be better off using a BigInt object
for this data. But anyway, here's what I got.
Mark
Index: src/call_list.txt
===
--- src/call_list.txt (revision 27216)
+++ src/call_list.txt (working copy)
@@ -13,6 +13,7 @@
# s - short
# i - int
# l - long
+# L - long long
# NUM register stuff
# N - FLOATVAL
@@ -34,6 +35,7 @@
# 2 - pointer to short
# 3 - pointer to int
# 4 - pointer to long
+# 5 - pointer to long long
# void stuff
# v - void
Index: tools/build/nativecall.pl
===
--- tools/build/nativecall.pl (revision 27216)
+++ tools/build/nativecall.pl (working copy)
@@ -43,6 +43,8 @@
3 = int *,
l = long,
4 = long *,
+L = long long,
+5 = long long *,
c = char,
s = short,
2 = short *,
@@ -65,6 +67,8 @@
3 = int *,
l = long,
4 = long *,
+L = long long,
+5 = long long *,
c = char,
s = short,
2 = short *,
@@ -105,6 +109,8 @@
3 = int *,
l = long,
4 = long *,
+L = long long,
+5 = long long *,
c = char,
s = short,
2 = short *,
@@ -126,8 +132,10 @@
i = set_nci_I(interp, st, return_data);,
I = set_nci_I(interp, st, return_data);,
l = set_nci_I(interp, st, return_data);,
+L = set_nci_L(interp, st, return_data);,
s = set_nci_I(interp, st, return_data);,
c = set_nci_I(interp, st, return_data);,
+5 = set_nci_L(interp, st, *return_data);,
4 = set_nci_I(interp, st, *return_data);,
3 = set_nci_I(interp, st, *return_data);,
2 = set_nci_I(interp, st, *return_data);,
@@ -147,10 +155,12 @@
my %func_call_assign = (
p = return_data = ,
i = return_data = ,
+2 = return_data = ,
3 = return_data = ,
-2 = return_data = ,
4 = return_data = ,
+5 = return_data = ,
l = return_data = ,
+L = return_data = ,
c = return_data = ,
s = return_data = ,
f = return_data = ,
@@ -173,6 +183,7 @@
2 = P,
4 = P,
l = I,
+L = L,
c = I,
s = I,
f = N,
@@ -320,6 +331,18 @@
return UVal_int(st-val);
}
+static HUGEINTVAL
+get_nci_L(PARROT_INTERP, ARGMOD(call_state *st), int n)
+{
+if (n = st-src.n) {
+real_exception(interp, NULL, E_ValueError,
+too few arguments passed to NCI function);
+}
+Parrot_fetch_arg_nci(interp, st);
+
+return UVal_hugeint(st-val);
+}
+
static FLOATVAL
get_nci_N(PARROT_INTERP, ARGMOD(call_state *st), int n)
{
@@ -367,6 +390,7 @@
#define GET_NCI_I(n) get_nci_I(interp, st, n)
#define GET_NCI_S(n) get_nci_S(interp, st, n)
#define GET_NCI_N(n) get_nci_N(interp, st, n)
+#define GET_NCI_L(n) get_nci_L(interp, st, n)
#define GET_NCI_P(n) get_nci_P(interp, st, n)
/*
@@ -384,6 +408,17 @@
}
static void
+set_nci_L(PARROT_INTERP, ARGOUT(call_state *st), HUGEINTVAL val)
+{
+Parrot_init_ret_nci(interp, st, L);
+if (st-dest.i st-dest.n) {
+UVal_hugeint(st-val) = val;
+Parrot_convert_arg(interp, st);
+Parrot_store_arg(interp, st);
+}
+}
+
+static void
set_nci_N(PARROT_INTERP, ARGOUT(call_state *st), FLOATVAL val)
{
Parrot_init_ret_nci(interp, st, N);
@@ -454,6 +489,11 @@
push @{$extra_preamble_ref}, t_$temp_num =
(long)GET_NCI_I($reg_num);;
return t_$temp_num;
};
+/L/ do {
+push @{$temps_ref}, long long t_$temp_num;;
+push @{$extra_preamble_ref}, t_$temp_num = (long
long)GET_NCI_I($reg_num);;
+return t_$temp_num;
+};
/I/ do {
push @{$temps_ref}, INTVAL t_$temp_num;;
push @{$extra_preamble_ref}, t_$temp_num = GET_NCI_I($reg_num);;
@@
Re: [perl #53390] [BUG] t/op/sysinfo.t reports INTVAL size mismatch on linux/amd64
On Sat, 26 Apr 2008 11:40:43 -0700
Mark Glines (via RT) [EMAIL PROTECTED] wrote:
# at t/op/sysinfo.t line 53.
# got: '8'
# expected: '4'
Found it. The test was checking the op's report of sizeof(INTVAL)
against $PConfig{intsize}, but INTVAL isn't necessarily defined to
int. On linux/amd64, INTVAL is typedeffed to long (via Parrot_Int).
PConfig{intsize} is sizeof(int).
PConfig{intvalsize} is sizeof(INTVAL). That's the one we want.
Fixed in r27196.
There's an XXX comment in this test for a good reason: We probably also
want a PConfig{floatvalsize}, distinct from PConfig{doublesize}.
Probably not a big deal if Parrot_Float is always declared as a
double.
Mark
Re: [perl #53270] [TODO] Rename/refactor _handle_mswin32()
On Thu, 24 Apr 2008 20:48:34 -0700
Geoffrey Broadwell [EMAIL PROTECTED] wrote:
Also, the implementation of C_add_to_libs is a little wordy. How's
this?
sub _add_to_libs {
my ($self, $args) = @_;
croak _add_to_libs() takes hashref unless ref($args) eq 'HASH';
my $os = $args-{osname};
my $cc = $args-{cc};
my $platform = $os =~ /mswin32/i $cc =~ /^gcc/i ? 'win32_gcc' :
$os =~ /mswin32/i ? 'win32_other' :
$os =~ /darwin/i? 'darwin' :
? 'default' ;
my $libs = $args-{$platform} || $args-{default};
$args-{conf}-data-add(' ', libs = $libs);
return 1;
}
Pretty. Easy to read, easy to maintain. And +1 for using Carp,
too.
Mark
Re: [perl #53126] [TODO] config/auto/digest.pm: New config step needs rationale, lacks tests
On Tue, 22 Apr 2008 13:37:16 +0200 François Perrad [EMAIL PROTECTED] wrote: Applied in r27116. François Unfortunately, your subsequent r27117 patch (to work with openssl 0.9.8) causes failures in t/steps/auto_crypto-03.t. t/steps/auto_crypto-03..1/17 # Failed test ''has_crypto' set as expected' # at t/steps/auto_crypto-03.t line 49. # got: undef # expected: '1' # Failed test 'Expected result was set' # at t/steps/auto_crypto-03.t line 50. # got: '' # expected: 'yes, 0.9.9z' # Failed test ''has_crypto' set as expected' # at t/steps/auto_crypto-03.t line 58. # got: undef # expected: '0' # Failed test 'Expected result was set' # at t/steps/auto_crypto-03.t line 72. # got: undef # expected: 'yes, 0.9.9z' # Failed test 'Got expected verbose output' # at t/steps/auto_crypto-03.t line 73. # '' # doesn't match '(?-xism:\(yes\))' # Looks like you failed 5 tests of 17. t/steps/auto_crypto-03.. Dubious, test returned 5 (wstat 1280, 0x500) Failed 5/17 subtests Test Summary Report --- t/steps/auto_crypto-03.t (Wstat: 1280 Tests: 17 Failed: 5) Failed tests: 10-12, 15-16 Non-zero exit status: 5 Files=1, Tests=17, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.24 cusr 0.02 csys = 0.29 CPU) Result: FAIL Mark
Re: [perl #53142] [TODO] Cage-cleaner's request: PDD for configuration; Create RTs for new or heavily modified config steps
On Mon, 21 Apr 2008 17:58:52 -0700 chromatic [EMAIL PROTECTED] wrote: On Monday 21 April 2008 17:02:27 Mark Glines wrote: Another note, slightly off-topic: does OpenGL actually need a configuration/detection step at all? I notice neither SDL or PostgreSQL seem to have one. Maybe they're detecting everything at runtime, or maybe their generated stuff runs from make instead of from configure? On the other hand, the config system is modularized into nice neat little steps, which makes them terribly easy to write and maintain, so it seems a shame not to use them. :) PostgreSQL and SDL use NCI to link against existing shared libraries. As I understand the OpenGL code (and the crypto code), they actually build C code, which is a little more involved. Ok. So if the OpenGL and crypto code didn't have to generate custom C files, they wouldn't have to have all the extra infrastructure, right? Just a test that gets skip_alled if the library can't be loaded at runtime, like pgsql has, no detection nonsense, no generation nonsense, no config-script testing nonsense. So is that the preferred method of implementing bindings for C libraries? Or is there such a thing as a preferred method, to begin with? Mark
Re: [perl #53142] [TODO] Cage-cleaner's request: PDD for configuration; Create RTs for new or heavily modified config steps
On Sun, 20 Apr 2008 19:01:44 -0700 James Keenan (via RT) [EMAIL PROTECTED] wrote: Hi! As one of the guilty parties, I'm not sure whether I get a vote, but... * Is new configuration step X::X *necessary* for the functioning of the Parrot virtual machine? Frankly, probably nothing but the basic does the compiler exist, and is it sane type of tests meet that qualification. * If new step X::X is not necessary for Parrot, what makes it *desirable*? Why should it be included at the cost of increased complexity in configuration, build and testing? When I checked in Opengl, it did seem like something that wasn't absolutely necessary. But I have to admit, I checked it in for other reasons. My reasoning was as follows: 1. It seemed more relevant than some stuff that's already in parrot. (I have more machines with OpenGL installed than have postgresql, for example.) 2. The author (Geoff) was responsive, willing and able to fix issues as they arose. Thus, if someone had a problem, we also had someone motivated to fix it. (Your process of silently writing tests, while very helpful and appreciated, negated this effect somewhat.) 3. We didn't have a release pending, thus we are not in feature freeze. I would like to propose both short-term and long-term remedies. Short-term: If you are proposing a new configuration step, or doing a significant overhaul of any existing step, please post an RT with the code and with a [TODO] tag several days ahead of time. This will give people a chance to run it on different OSes right away, without compromising trunk. And if I get advance notice of any new config step, I pledge to work with you to develop tests for that step. Long-term: We need a Parrot design document on configuration. Such a document should cover what configuration is, why we have decided to include the configuration steps already there, what we need and what we don't need. Such a document should distinguish between what we need between now and 1.0 OTOH and post-1.0 OTO. And we also need a document defining what steps an implementer should follow when adding or modifying configuration steps. You are right, the process for OpenGL was a bit rocky, but in my defense, I didn't know any better. Actually, I don't really know much at all about the config system, or the testing thereof. docs/configuration.pod doesn't seem to mention tests at all. Maybe if it did, then the next time someone like me comes along and breaks everything, then you'll have something to whack them over the head with. All this feature detection stuff is very interdependent, and when a new feature comes along without sufficient testing, there is a chance that it will get in everyone else's way. So in the short term, where each such feature incurs some maintenance overhead and breakage affects people working on unrelated things, you are making a very valid point. In the longer term, I am hoping that we end up with a sort of CPAN for Parrot. Specifically, for all of: Parrot applications, Parrot language modules, and Parrot library-wrapper plugins, like opengl. (And gettext. And readline. And sdl. And postgresql. And bigint.) And they can all do whatever system detection they need, and they can all depend on each other as needed. But the core of that strategy is, if these things have their own detection/generation process which isn't always run for everybody, they don't get in the way of people who don't care about them. So I guess my idea of the the status quo is, until we can split our thousands of obscure features into separate packages, we sorta just have to live with them. But maybe we could have a happy medium: suppose you only get opengl when you specify --enable-opengl on the command line? Or it could be generated from make opengl or by running make in a special directory or some such? This kind of mechanism might not be good in the long term, but in the short term, it should prevent people from stomping on each other so much. Another note, slightly off-topic: does OpenGL actually need a configuration/detection step at all? I notice neither SDL or PostgreSQL seem to have one. Maybe they're detecting everything at runtime, or maybe their generated stuff runs from make instead of from configure? On the other hand, the config system is modularized into nice neat little steps, which makes them terribly easy to write and maintain, so it seems a shame not to use them. :) Mark
Re: [perl #53094] [TODO] config/auto/perldoc.pm: Recent change needs discussion
On Sun, 20 Apr 2008 05:36:44 -0700
James Keenan (via RT) [EMAIL PROTECTED] wrote:
-my $cmd = $conf-data-get_p5('scriptdirexp') . q{/perldoc};
+my $cmd = q{perldoc};
Mark, can you evaluate impact?
Well, it looks to me like it'll just run perldoc from the user's
$PATH, rather than trying to find the one that installed with the
currently running perl. So it might lead to a different perldoc being
used, if the user has more than one rev of perl installed (and ran
Configure.pl with the non-default one). Whether that actually matters
or not... I dunno.
Mark
Re: [perl #53066] consting vtable methods
On Sun, 20 Apr 2008 21:01:01 +0200 NotFound [EMAIL PROTECTED] wrote: On Sun, Apr 20, 2008 at 12:17 AM, Andy Lester [EMAIL PROTECTED] wrote: Just popping in to say that we cannot const any parms to vtable methods. Parrot can't impose promises on the called code. Hi Andy! Sure we can. A :const attribute on an entry in vtable.tbl results in a const added to the PMC *pmc argument in the generated vtable struct. And on the implementation side, everything matches up when you add a :const attribute to your PMC VTABLE method. Failure to do so results in an incompatible pointer warning, just like any other kind of prototype mismatch. (Of course, the writer of the vtable method can cheat and cast around it, but that's no different from any other const function in parrot.) The question isn't whether we *can* enforce a consted invocant constraint, because we certainly can. It's a question of whether we *should*. Frankly, I don't see any compelling reason to allow VTABLE_isa() or VTABLE_get_class() or VTABLE_type() to modify anything in SELF. But whether it's worth the extra constraint placed on pmc authors... I dunno. I just know the current situation is broken. Right now there is quite a bit of consting in the middle of the parrot call stack, and that's the wrong place for it. To fix this, we either need more consting in the backend (starting with some of the vtable methods), or less consting in the frontend (starting with any functions that call vtable methods). I will happily fix up all the method implementations, or all of the callers, depending on what people think about it here. So it looks like if vtable methods can't be const, then pmc methods can't be const at the C level without a nightmare of casts adding and removing constness. Agreed. And since I don't think casts are ever the right answer for this, that would mean backing out a lot of consting. (And probably, quite a bit of work to detect existing casts that hide other consting issues.) Mark
Re: [perl #53108] [BUG]
On Sun, 20 Apr 2008 11:20:08 -0700 [EMAIL PROTECTED] (via RT) [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:~$ perl6 -e 'say 1.1*10' 11 [EMAIL PROTECTED]:~$ perl6 -e 'say 10*1.2' 1.66058e+08 pmichaud nopasted some simple PIR code which reproduces the issue, and pinpoints things pretty well: [EMAIL PROTECTED]:~/parrot/trunk$ cat x.pir .sub main :main $P0 = subclass 'Integer', 'Int' $P1 = subclass 'Float', 'Num' $P0 = new 'Int' assign $P0, 1 $P1 = new 'Num' assign $P1, 1.1 $P2 = n_mul $P0, $P1 say $P2 .end [EMAIL PROTECTED]:~/parrot/trunk$ ./parrot x.pir 1.50133e+08 [EMAIL PROTECTED]:~/parrot/trunk$
Re: [perl #53112] [PATCH] Fixing C++ build break issue when using GMP
On Sun, 20 Apr 2008 15:08:12 -0700 chromatic [EMAIL PROTECTED] wrote: Is this really correct? My gmp.h file has: No, it's a workaround for an issue that isn't really gmp's fault. Building with g++ barfs when parsing libintl.h, included by gmp.h. Here's what happens: libintl.h defines the following two function prototypes: extern char *textdomain (__const char *__domainname) __THROW; extern char *bindtextdomain (__const char *__domainname, __const char *__dirname) __THROW; Unfortunately, PARROT_HAS_GEXTTEXT (see the typo in that?) isn't defined, so include/parrot/parrot.h does: # define textdomain(d) # define bindtextdomain(p, d) So the compiler actually sees: extern char * throw (); extern char * throw (); And barfs: src/pmc/bigint.c /usr/include/libintl.h:83: error: expected unqualified-id before 'throw' /usr/include/libintl.h:83: error: expected initializer before 'throw' /usr/include/libintl.h:87: error: expected unqualified-id before 'throw' /usr/include/libintl.h:87: error: expected initializer before 'throw' make: *** [src/pmc/bigint.o] Error 1 Fixing the typo fixes the bug. Fixed in r27065. (Still debatable whether the rest of that #else clause in parrot.h is valid, if it's causing issues like this one.) 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
Re: [perl #52916] [PATCH] Making NCI test C++ compatible
On Sat, 19 Apr 2008 11:26:13 +0530 Senaka Fernando [EMAIL PROTECTED] wrote: Hi Mark, What does the fix to 't/codingstd/c_indent.t' do? Does it ignore anything inside #ifdef __cplusplus blocks? Yes. This lets us add any g++-specific stuff without throwing off the indentation. 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
Re: [perl #53066] consting vtable methods
On Sat, 19 Apr 2008 21:45:49 +0200 NotFound [EMAIL PROTECTED] wrote: Hi! I faced the same problem when trying to get rid of some warnings in order to help cage cleaning. Adding or removing a const in the parameters of many functions becomes a design change, not a simple code cleaning. If you add a cast to remove a warning, when the called function get fixed a new warning appears about the now unnecessary cast. In a perfect world, de-constification casts would never be necessary. They just hide the problem, they don't solve anything. So I try to avoid them. Unless I've seriously misunderstood things, const is a contract saying, I will not modify the data you give me. The compiler takes that and says oh, if the data won't be modified, that means I don't have to check it afterward, so I can merge conditionals and optimize things a little bit more. But when you pass that data (with or without a cast) to something else which modifies it, you've broken the contract. Seems like this problem typically crops up when a function in the middle of the call stack has a const parameter, but then tries to pass it to another, non-const function. So as a general rule of thumb, whenever one function calls another, the constness of a variable should *never* decrease. Over each function boundary, constness should always either stay the same, or increase. Caller Called normal normal = ok constconst= ok normal const= ok constnormal = problem The correct solution is either to make the Called function const, or to un-const the Caller. The same applies to some parameters attributed as non null, and explicitly called with NULL argument in several locations. How can a cleaner figure what is the desired correction? Yeah, that's the same kind of issue. Well, you could force the issue: throw an exception whenever the pointer is NULL, and then watch to see who complains. :) Blindly changing atributes attributes just to pass test looks to me like a problem, not a solution. I agree. So I'm not blindly consting get_string() and hoping nothing breaks. Instead, I'm whining about it on RT and p2, and hoping the designers will say something useful. :) (Hopefully either: * rip it all out, no vtable methods can have const invocants, and therefore, neither can any function that calls a vtable method. or * vtable functions M and N have const invocants, so they aren't allowed to call anything which could modify the invocant. ... I'd be happy either way.) Mark P.S. I don't actually feel very strongly about consting... I just think broken consting is worse than no consting at all, and I don't like papering over things that could lead to weird bugs later on.
[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
M2 Bytecode format
: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, Jonathan (and everyone else)! Wednesday on IRC, we discussed the M2 Bytecode format milestone. This email is my attempt to formalize a plan for this work. I am hoping you will read through it and tell me how wrong I am. :) First off, I've created a branch (named pdd13pbc) for this. So that's where all this work is going to go. As we discussed, there are two top level goals here: 1. Update the disk format and/or interface to match the PDD13 spec. 2. Move all of the .pbc-handling code into a PackFile.pmc class. At your suggestion, I'm going to be focusing on the second option. It seems to me that I should tackle this in the following order: 2.1. Create some simple PMC classes named as specified in PDD13. 2.2. Toss together some methods which wrap around the existing src/packfile.c, src/packdump.c and src/packout.c functions. 2.3. Write a bunch of tests, test the hell out of it. 2.4. Start moving everything in parrot over to use the new PMC-based packfile API. 2.5. Copypaste pieces of packfile.c, packout.c, packdump.c code into the PMCs, to make them self-reliant. 2.6. Test the hell out of it. (Again.) 2.7. Rip out src/pack*.c and make sure nothing breaks. Questions: Does this plan sound reasonable? Should this PMC implement the pdump functionality (src/packdump.c) as well as packfile.c/packout.c? Speaking of pdump, it seems to be mentioned in various places, mostly documentation and scripts, but it does not actually seem to be buildable. Judging from the documentation, there used to be a make pdump, but not any more. What's up with that? Should I be tracking these subtasks in RT, or just keeping track of things on my own? Mark
Re: [perl #52988] [PATCH] OpenGL binding, part 1
On Thu, 17 Apr 2008 08:16:23 -0700 Geoffrey Broadwell [EMAIL PROTECTED] wrote: 3. Parse the define *values*, and toss any that don't look right. I'm thinking #3, since it's probably best to have that safety check anyway, and it's probably the easiest. I'll work on that one. Sounds good to me. Clearly those values weren't meant to actually be used anywhere. 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
Re: working out kinks in the parrot release process
On Wed, 16 Apr 2008 13:45:22 -0700 jerry gay [EMAIL PROTECTED] wrote: also, i'd like to automate more of the release process. currently, we have a period of time where the link on the website for the most recent parrot will point to the previous release of parrot, until the new distro propagates to the cpan mirrors. in order to overcome this problem, and to automate one more release step, i propose the following: write a piece of code that watches http://svn.perl.org/parrot/tags/ for a new tag that matches /RELEASE_.*/, and when that occurs, run 'make release VERSION=`cat version`', and updates a link on the website to point to that tarball. we can then use that tarball to do a final test, and upload it to cpan. comments welcome. Does this mean dalek needs a CPAN account now? 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
Re: [perl #52710] key.c and missing default in key_integer switch
On Thu, 10 Apr 2008 10:53:31 -0700
[EMAIL PROTECTED] (via RT)
[EMAIL PROTECTED] wrote:
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #52710]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=52710
Hey,
I *thought* I'd try and clean up an easy one, so I took
src/key.c
src/key.c: In function `key_integer':
src/key.c:368: warning: switch missing default case
After a little poking I tracked the rest of the Key__FLAG s down
to include/parrot/key.h (and pobj.h) [1] and so I rearrainged the
case stmt to cover them all (noting the TODO on slices, I separated
those), putting in the current default behavior for everything that
wasn't already covered and then adding a default branch w/ an
exception (taken from the next sub ... ). This broke iterator.t tests
and it appears to be due to a missing (?) flag value of '8' for
switch test switch (PObj_get_FLAGS(key) KEY_type_FLAGS) {
So ... either there's a missing KEY__FLAG or something. One hint
is in src/packdump.c [3] which would say the '8' is an 'is_string'
flag? I've not yet been able to track backwards (my debugging is
painfully slow w/ printf's and re-makes) to see who's calling w/ the
funny flag value but I thought I'd ask here to see if anybody had an
answer.
Thanks.
Hi,
Here's the code you posted in [2], in unified diff format, without the
C++-style comments and white space changes. It looks like your mail
client screwed up the white space, which made it pretty hard to
see what was changed... please read docs/submissions.pod when you have a
chance, the tips contained within make this kind of thing a lot easier.
Thanks!
Mark
Index: src/key.c
===
--- src/key.c (revision 26901)
+++ src/key.c (working copy)
@@ -322,7 +322,18 @@
return string_to_int(interp, s_reg);
}
/* TODO check for slice_FLAGs */
+case KEY_start_slice_FLAG:
+case KEY_end_slice_FLAG:
+case KEY_inf_slice_FLAG:
+return VTABLE_get_integer(interp, key);
+case KEY_number_FLAG:
+return VTABLE_get_integer(interp, key);
+default:
+real_exception(interp, NULL, INVALID_OPERATION,
+Key_integer %d %d %d not a valid flag!\n,
VTABLE_get_integer(interp,
+key), PObj_get_FLAGS(key), PObj_get_FLAGS(key)
KEY_type_FLAGS);
}
+
}
return VTABLE_get_integer(interp, key);
Re: [perl #52710] key.c and missing default in key_integer switch
On Thu, 10 Apr 2008 13:21:23 -0700 Mark Glines [EMAIL PROTECTED] wrote: } + } Okay, without *most* of the white space changes. Oh well, I tried. 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
Re: [perl #51980] [PATCH] fixed multiple redefines of snprintf macro
On Sun, 06 Apr 2008 17:50:27 -0700 Andrew Whitworth via RT [EMAIL PROTECTED] wrote: Just warnings about redefining the snprintf macro. It was defined in two different places, and it's definition was based on both of those two flags above. I was looking for a way to unify the definitions for snprintf, and I wanted to know if a unification could go further then that as well. Ok, thanks for the clarification. How do you think we should fix it? Mark
Re: Need info on Stack Enumeration
On Sun, 6 Apr 2008 01:39:31 +0530 Senaka Fernando [EMAIL PROTECTED] wrote: Hi Chromatic, do you trace the PMC object roots on the Stack within the GC? or in other words is there any Stack enumeration? Some clarification: I think the question under discussion here is, how does the GC subsystem gain access to the various thread stacks, in order to add those memory chunks to the root set that gets swept? Seems to me that it would either need to get a list of threads and enumerate them somehow, or newly created threads would have to register themselves with the GC subsystem. But we can't find either of these things occurring. Thanks, Mark
Re: [perl #52462] [PATCH] [UGLY] FixedIntegerArray-new_from_string() needs cleanup
On Fri, 4 Apr 2008 12:50:27 -0500 Patrick R. Michaud [EMAIL PROTECTED] wrote: On Fri, Apr 04, 2008 at 10:06:39AM -0700, chromatic wrote: On Thursday 03 April 2008 15:47:12 Mark Glines wrote: When doing a test for --gc=libc, I noticed test 10 of t/op/calling.t was hanging. The test creates a FixedIntegerArray from the string 0, 0x20, 0x20, 0. The new_from_string() constructor relies on STRING* buffers containing a trailing NULL (which isn't counted in the strlen tally). The existence of that NULL is not a valid assumption in the gc=libc case. [...] I've attached a fix. It isn't very pretty, and it probably really hurts performance. But it fixes the hang, and allows the test script to complete successfully. I am submitting it to RT in the hopes that someone with better knowledge of parrot internals can come up with a Better Way (tm). 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.) If it's going to stay around, it should be fixed. But removing it entirely works for me too. Mark
Re: [perl #51464] [TODO] [PDD] add date stamps to PDD's
On Thu, 03 Apr 2008 12:18:47 -0700 James Keenan via RT [EMAIL PROTECTED] wrote: Datestamps in the filename (e.g., MMDD)? Or somewhere inside the file? Wouldn't the former create repository problems? Couldn't the latter be done automatically with an $Id$ tag? Mark
Re: [perl #43102] t/pmc/threads.t tests 5,7 fail with --gc=libc
On Thu, 03 Apr 2008 13:40:20 -0700 Bernhard Schmalhofer via RT [EMAIL PROTECTED] wrote: On Fr. 01. Jun. 2007, 08:42:43, [EMAIL PROTECTED] wrote: While testing/trying to fix RT #42938, I noticed an additional test failure in t/pmc/threads.t. Test 7 crashes with a signal 11 (segmentation fault), on my Gentoo Linux-x86 box. This is with svn r18722. Hi Mark, is this still an issue? Test 7 still crashes with a signal 11, yes. Tested with r26715 built with --gc=libc on a Linux-amd64 box. 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
Re: [perl #52224] Parrot::Test calls parrot with a bogus optimization values when run in /opt
On Sat, 29 Mar 2008 07:03:17 -0700
James Keenan via RT [EMAIL PROTECTED] wrote:
If we simply add a forward slash after 'opt', does that solve the
problem? (see attached)
Should this code really be checking the absolute pathname? We don't
have any control over where a user places a parrot checkout, and
honestly, I think we should be ignoring that as much as possible. I
think a safer solution is to chuck the filename through basename()
before doing the match.
This changes Parrot::Test's behavior: an alternate -O option will only
be used if the *filename* contains optN, not if a leading directory
name contains it. I don't see any uses of optN in directory names
in the parrot tree, so I think it's ok. And it fixes the bug for me.
See attached.
Mark
Index: lib/Parrot/Test.pm
===
--- lib/Parrot/Test.pm (revision 26625)
+++ lib/Parrot/Test.pm (working copy)
@@ -263,6 +263,7 @@
use Cwd;
use File::Spec;
+use File::Basename;
use Memoize ();
use Parrot::Config;
@@ -766,11 +767,12 @@
# Name of the file with test code.
my $code_f = File::Spec-rel2abs( per_test( '.pir', $test_no ) );
+my $code_basef = basename($code_f);
# output file
my $out_f = per_test( '.pasm', $test_no );
-my $opt = $code_f =~ m!opt(.)! ? -O$1 : -O1;
+my $opt = $code_basef =~ m!opt(.)! ? -O$1 : -O1;
my $args = $ENV{TEST_PROG_ARGS} || '';
$args .= $opt --output=$out_f;
$args =~ s/--run-exec//;
Re: [perl #52224] Parrot::Test calls parrot with a bogus optimization values when run in /opt
On Sat, 29 Mar 2008 11:59:25 -0700
Mark Glines [EMAIL PROTECTED] wrote:
This changes Parrot::Test's behavior: an alternate -O option will
only be used if the *filename* contains optN, not if a leading
directory name contains it. I don't see any uses of optN in
directory names in the parrot tree, so I think it's ok. And it fixes
the bug for me. See attached.
Found a second place in Parrot::Test which was doing the same thing,
causing a failure in t/pmc/sub.t. Fixed in the same way, new diff
is attached. Now everything in make test passes for me.
Mark
Index: lib/Parrot/Test.pm
===
--- lib/Parrot/Test.pm (revision 26625)
+++ lib/Parrot/Test.pm (working copy)
@@ -263,6 +263,7 @@
use Cwd;
use File::Spec;
+use File::Basename;
use Memoize ();
use Parrot::Config;
@@ -575,6 +576,7 @@
die Unknown test function: $func;
}
$code_f = File::Spec-rel2abs($code_f);
+my $code_basef = basename($code_f);
# native tests are just run, others need to write code first
if ( $code_f !~ /\.pbc$/ ) {
@@ -583,7 +585,7 @@
# honor opt* filename to actually run code with -Ox
my $args = $ENV{TEST_PROG_ARGS} || '';
-my $opt = $code_f =~ m!opt(.)! ? -O$1 : ;
+my $opt = $code_basef =~ m!opt(.)! ? -O$1 : ;
$args .= $opt;
my $run_exec = 0;
@@ -766,11 +768,12 @@
# Name of the file with test code.
my $code_f = File::Spec-rel2abs( per_test( '.pir', $test_no ) );
+my $code_basef = basename($code_f);
# output file
my $out_f = per_test( '.pasm', $test_no );
-my $opt = $code_f =~ m!opt(.)! ? -O$1 : -O1;
+my $opt = $code_basef =~ m!opt(.)! ? -O$1 : -O1;
my $args = $ENV{TEST_PROG_ARGS} || '';
$args .= $opt --output=$out_f;
$args =~ s/--run-exec//;
[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.
Re: [perl #51916] Error in tests after build
On Fri, 21 Mar 2008 07:16:07 -0400 James E Keenan [EMAIL PROTECTED] wrote: Ted Neward wrote: BTW, I didn't want to file a bug, but the Lua compiler in the latest bits uses a tool yapp that doesn't appear to be a part of the bundle--is it supposed to be? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com I don't think so ... but can our Lua experts respond to this? I am not a Lua expert, but that sounds an awful lot like Lua has a build-dependency on Parse::Yapp from CPAN. Mark
Re: [perl #51976] [PATCH] fixed uninitialized variable warning in dynext.c:Parrot_init_lib()
On Fri, 21 Mar 2008 08:21:44 -0700 Andrew Whitworth (via RT) [EMAIL PROTECTED] wrote: # New Ticket Created by Andrew Whitworth # Please include the string: [perl #51976] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=51976 I'm fixing a compile error that's generated (at least) on Win32 using cl.exe. In dynext.c, the function Parrot_init_lib(), the variable lib_pmc is, possibly, left undefined before it is used in a conditional statement. I assume, from looking at the context of the code, that the variable should be initialized to NULL included is a simple patch that corrects this issue, and should suppress one compile-time warning. Thanks, applied in r26510. Mark
Re: [perl #51980] [PATCH] fixed multiple redefines of snprintf macro
On Fri, 21 Mar 2008 09:03:08 -0700 Andrew Whitworth (via RT) [EMAIL PROTECTED] wrote: # New Ticket Created by Andrew Whitworth # Please include the string: [perl #51980] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=51980 the snprintf macro was defined in Parrot/misc.h and src/spf_render.c. I moved both definitions into the misc.h file and used conditionals to determine which one to activate. The current definition goes like this: 1) if the _MSC_VER macro is defined, use _snprintf 2) if the PARROT_HAS_C99_SNPRINTF macro is not defined, use Parrot_secret_snprintf instead 3) otherwise, don't define the snprintf macro at all. In Parrot/has_header.h (which is, I know, automatically generated), 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. I'm not so sure of this - my Linux box, for instance, has both defined. On first glance, it sounds like your system has an snprintf(), but Configure.pl has decided your snprintf() is not C99-compatible. Mark
Re: [perl #51982] [PATCH] fixed signed/unsigned typecast in string_primitives.c
On Fri, 21 Mar 2008 09:06:59 -0700
Andrew Whitworth (via RT) [EMAIL PROTECTED] wrote:
# New Ticket Created by Andrew Whitworth
# Please include the string: [perl #51982]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=51982
src/string_primitives.c:Parrot_char_digit_value was producing a
compile-time warning because the function is supposed to be returning
a UINTVAL, and is returning -1 on error. I applied a simple typecast
to make this warning go away.
As discussed on IRC, I think the correct fix for this is to change the
return type of Parrot_char_digit_value(). This function will return 0
through 9 given a character in ('0'..'9'), and will return -1
otherwise. The unsignedness of the return type is just silly.
Mark
Re: [perl #51984] [PATCH] fixed const int to unsigned char conversion warnings
On Fri, 21 Mar 2008 09:26:42 -0700 Andrew Whitworth (via RT) [EMAIL PROTECTED] wrote: # New Ticket Created by Andrew Whitworth # Please include the string: [perl #51984] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=51984 The file src/utils.c was producing a number of compile-time warnings involving possible loss of data in conversions from const int to unsigned char. This stemmed from the macro move_reg, which passed integer values to a function of type reg_move_func, which takes only unsigned char parameters. To remove the warnings, I added explicit typecasts to unsigned char for the parameters. Thanks, applied (with minor modifications) as r26511. Mark
Re: [perl #51982] [PATCH] fixed signed/unsigned typecast in string_primitives.c
On Fri, 21 Mar 2008 13:19:09 -0400 Andrew Whitworth [EMAIL PROTECTED] wrote: Okay, i changed the function declaration in src/string_primitives.c and include/Parrot/string_primitives.h. After a search, I couldn't find any other files where the function Parrot_char_digit_value was used, so I don't think anything else needed to be changed. Thanks, applied in r26512. Mark
Re: [perl #51988] [PATCH] file descriptor duplication updates
On Fri, 21 Mar 2008 11:15:51 -0700 Andrew Whitworth (via RT) [EMAIL PROTECTED] wrote: # New Ticket Created by Andrew Whitworth # Please include the string: [perl #51988] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=51988 A number of small updates to file descriptor duplication functions: 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. These fixes should quiet a number of compile warnings, and shouldn't affect the operation of the code at all. The new macro may be overkill since It's only used in one place, but I'm assuming that it might be useful elsewhere. If not, we can easily remove it and substitute the guts of it into the body of the function. Your patch does not build for me on Linux, sorry. _dup is not a valid symbol on my architecture, so your patch causes compiler warnings and a linker error. Mark
[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
Re: [perl #51718] Consolidate test infrastructure in t/codingstd and t/distro
On Fri, 14 Mar 2008 17:01:39 -0700 Mark Glines [EMAIL PROTECTED] wrote: I'm going to hold off until after Tuesday's release, in any case, just to make sure I don't break anything else. I committed my previous patch (after some merging) as r26480. But I think this ticket should stay open, as there are still more codingstd tests to convert, and I haven't even looked at t/distro yet. 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
Re: [perl #51718] Consolidate test infrastructure in t/codingstd and t/distro
On Fri, 14 Mar 2008 16:19:48 -0700 James Keenan via RT [EMAIL PROTECTED] wrote: Mark: This looks good to me. However, one of the tests being revised is currently failing, probably for different reasons. See: http://rt.perl.org/rt3/Ticket/Display.html?id=51750. Thanks for the code review! Yep, that's a preexisting failure. The recent changes to that file are the reason I started looking at the codingstd tests to begin with. On Wednesday morning, it was failing 3 of the codingstd tests, one of which (trailing_spaces.t) didn't even give line numbers. I recommend holding off applying it to trunk until after that bug is resolved -- which I suspect means holding off until after this coming Tuesday's release as well. I'm going to hold off until after Tuesday's release, in any case, just to make sure I don't break anything else. Mark
Re: minimal Parrot for small (embedded) system
On Tue, 11 Mar 2008 20:02:25 + Wim Vanderbauwhede [EMAIL PROTECTED] wrote: I've read Parrot for small platforms in pdd01_overview, it says For small platforms, any parser, compiler, and optimizer modules are replaced with a small bytecode loader module which reads in Parrot bytecode and passes it to the interpreter for execution. I guess that's what I need; but I have no idea how to compile parrot this way. Any pointers would be much appreciated. Hi Wim, I don't think that feature is implemented yet. I don't see any Configure.pl options for this mode of operation, and the PDD says its not a requirement of the 1.0 release. So I'm afraid the answer is not yet, sorry. 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.
Re: [perl #50212] Configure step fails on Windows
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. On Thu, 24 Jan 2008 12:52:35 -0800 Alan Rocker (via RT) [EMAIL PROTECTED] wrote: Determining if your platform supports GMP...Can't spawn .\test.exe: Bad file descriptor at lib/Parrot/Configure/Utils.pm line 85. no. (Windows wanted to 'phone home about test.exe too.) Yeah, I get that on Strawberry Perl too. It surprised me, and it pauses the configure process until you click Don't send report. Might there be some obscure connection with [perl #41508] [BUG] Configure losing flags... ? Nah, I think the test app just broke for whatever reason. The mingw32 environment packaged with Strawberry Perl does include a libgmp.a and libgmp.la, so the test app was built properly, but failed to run. I reproduced it by copying config/auto/gmp/gmp.in to gmp.c, and compiling with: gcc -O2 -Wall -g -ggdb -o gmp.exe gmp.c -lgmp The resulting gmp.exe crashes and Windows prompts if I want to send an error report to microsoft.com. I poked around a bit with gdb, and discovered its barfing on an SSE2 instruction (pmuludq) in libgmp.a (at __gmpn_divrem_1+266), which my CPU (an athlon XP) can't handle. So I'm going to ask the Strawberry Perl guy about this. For the record, here's what GDB says: Program received signal SIGILL, Illegal instruction. 0x00405aaa in __gmpn_divrem_1 () (gdb) bt #0 0x00405aaa in __gmpn_divrem_1 () #1 0x00401ae8 in mpn_sb_get_str () #2 0x0001 in ?? () #3 0x003d2680 in ?? () #4 0x0022fc1b in ?? () #5 0x0011 in ?? () #6 0x12e0be82 in ?? () #7 0x0002 in ?? () #8 0x003d in ?? () #9 0x4161 in ?? () #10 0x7c91056d in ntdll!RtlFreeThreadActivationContextStack () from C:\WINDOWS\system32\ntdll.dll #11 0x in ?? () And the relevant disassembly: 0x00405aa4 __gmpn_divrem_1+260: paddd %mm0,%mm2 0x00405aa7 __gmpn_divrem_1+263: punpckldq %mm0,%mm1 0x00405aaa __gmpn_divrem_1+266: pmuludq %mm4,%mm2 0x00405aad __gmpn_divrem_1+269: paddq %mm2,%mm1 0x00405ab0 __gmpn_divrem_1+272: pxor %mm2,%mm2 Mark
Re: [perl #47704] [BUG]Memory leak with STRING's
On Thu, 22 Nov 2007 10:35:21 -0800
Mehmet Yavuz Selim Soyturk (via RT)
[EMAIL PROTECTED] wrote:
# New Ticket Created by Mehmet Yavuz Selim Soyturk
# Please include the string: [perl #47704]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47704
There is a memory leak with the STRING's. Next C code consumes more
and more memory, but does not free it:
for(i=0;i2000;i++) {
string_from_literal(INTERP, nothing);
}
Hi,
Unless I'm mistaken, string_from_literal() is an allocation function.
The string it returns needs to be freed again, with a call to
string_cstring_free(). I think this is true for all of the
string_from_* functions.
If there's a memory leak here, it is not in string_from_literal(), but
rather, in the code that calls it. I think the code you mentioned
in your previous ticket ([perl #47572]) is a good example of that.
Mark
[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.
Re: Current win32 linking issues: Summary
On Wed, 22 Aug 2007 11:16:12 +0200 Ron Blaschke [EMAIL PROTECTED] wrote: Don't know if its a problem if they fail. I don't have a problem with failures as they tell me there's something that needs attention. True. Well, these issues do need attention, so maybe they *should* fail. :) Jerry mentioned yesterday that there shouldn't be any failures for a release, which makes sense as it would only upset users. Maybe there should be a ticket for the failures then? Or an environment variable like PARROT_PORTER which makes all tests fail that are skipped because they are broken, not because the feature is not supported on the platform? Or maybe we should wait until the release, then stop skipping the error, which should help ensure it gets fixed before the next release. (It is a pretty important issue, I think, so I don't want to mask it any longer than absolutely necessary. Embeddability is important to me.) Many thanks for helping with the t/src issues, I'm glad you jumped on the Windows train. Some things work differently on Windows and Visual C++, especially the linking and loading part, with symbol exports/imports on the very top. One great way to find out about compiled objects, libraries and executables is the COFF/PE Dumper (dumpbin), which shows details about the binary image. Another fine tool is the Dependency Walker (depends), which exactly shows you which libraries would be loaded, including their full path, what symbols they export and which they import. Great, good tips. I don't know if I'm really on the windows train, though. I'm still primarily linux with a bit of freebsd on the side; for me, win32 is mostly in the category of bizarre platform to make portability testing more interesting. But it will be good to know my way around a little bit better, so I can solve things more quickly next time. :) Please don't hesitate to ask if you have any questions. Depending on $job workload it might take some time before I can get back to you, though. I know the feeling. Thanks! Mark
[perl #44855] Re: Current win32 linking issues: Summary
On Wed, 22 Aug 2007 11:16:12 +0200 Ron Blaschke [EMAIL PROTECTED] wrote: Jerry mentioned yesterday that there shouldn't be any failures for a release, which makes sense as it would only upset users. Maybe there should be a ticket for the failures then? I have created ticket #44855 for this issue. It sounds like we need to pass -DIN_LIBPARROT or somesuch to the compiler when compiling objects that end up in libparrot.dll. Then, we can use that to decide how PARROT_API will be defined. Sometime in the next couple of days, I'll see what's required to pass additional defines to the compiler, from within the Makefile system. Mark
Re: [perl #44809] [PATCH] use Storable instead of Data::Dumper for PMC .dump files
Oops. I replied to this on the RT site, but it looks like I neglected to tell it to copy the list (or you). I'll cutpaste my response below. On Tue, 21 Aug 2007 21:02:39 -0400 James E Keenan [EMAIL PROTECTED] wrote: I do have some qualms. (1) I know that there have been issues with incompatibility among different versions of Storable. I myself have been bit by these issues with different versions of Storable distributed with different versions of Perl 5.8 (not to mention 5.6). Some of these issues are alluded to in the POD (http://search.cpan.org/dist/Storable/Storable.pm#FORWARD_COMPATIBILITY). I have never heard such compatibility issues with respect to Data::Dumper. This is not a killer objection, but it should be considered. (2) Not that I'm opposed to Storable entirely. Hey, I use it in Parrot::Configure::Trace! But there, as in other places I've used it, I've always found I got better mileage by using 'nstore' instead of 'store'. Hi! I agree, nstore is more useful for stuff that's kept around for a while, exchanged between machines and so forth. But, keeping in mind these files are built by pmc2c.pl as part of the parrot build process, rebuilt whenever the pmc file changes, and removed whenever you do a make clean, does forwards compatibility (or even endian-portability) actually matter? Correct me if I'm wrong, but I don't think we keep any of these files around. Mark
[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.
Re: [perl #44809] [PATCH] use Storable instead of Data::Dumper for PMC .dump files
On Tue, 21 Aug 2007 09:52:01 -0700
chromatic [EMAIL PROTECTED] wrote:
return unless -f $filename;
return retrieve($filename);
My preference is the latter, for clarity and context reasons.
Thanks, you're absolutely right. Here's an updated patch.
Mark
Index: lib/Parrot/Pmc2c/Pmc2cMain.pm
===
--- lib/Parrot/Pmc2c/Pmc2cMain.pm (revision 20762)
+++ lib/Parrot/Pmc2c/Pmc2cMain.pm (working copy)
@@ -4,7 +4,7 @@
use strict;
use warnings;
use FindBin;
-use Data::Dumper;
+use Storable;
use Parrot::Vtable;
use Parrot::PMC;
use Parrot::Pmc2c::VTable;
@@ -226,7 +226,7 @@
$self-read_dump('filename');
BPurpose: A F.dump file is the result of a call to Cdump_pmc() and
-consists of a print-out of a hash reference Data::Dumper-style.
+consists of a binary dump of a hash reference, Storable-style.
Cread_dump() reads in the F.dump file, recreates the data structure and
returns a new hash reference holding the data structure.
@@ -248,11 +248,8 @@
my ( $self, $filename ) = @_;
$filename = $self-find_file( filename($filename, '.dump'), 1 );
-my $class;
-eval do { slurp($filename); };
-die $@ if $@;
-
-return $class;
+return unless -f $filename;
+return retrieve($filename);
}
=head3 Cgen_c()
Index: lib/Parrot/Pmc2c/VTable.pm
===
--- lib/Parrot/Pmc2c/VTable.pm (revision 20762)
+++ lib/Parrot/Pmc2c/VTable.pm (working copy)
@@ -5,7 +5,7 @@
use warnings;
use base qw( Exporter );
our @EXPORT_OK = qw();
-use Data::Dumper;
+use Storable;
use Parrot::Vtable;
use Parrot::Pmc2c::Method;
use Parrot::Pmc2c::UtilFunctions qw(spew);
@@ -73,9 +73,7 @@
my $dump_filename = cwd() . q{/} . basename(
Parrot::Pmc2c::UtilFunctions::filename($self-filename, '.dump') );
-my $Dumper = Data::Dumper-new( [$self], ['class'] );
-$Dumper-Indent(3);
-spew($dump_filename, $Dumper-Dump);
+store($self, $dump_filename);
return $dump_filename;
}
Index: lib/Parrot/Pmc2c/PMC.pm
===
--- lib/Parrot/Pmc2c/PMC.pm (revision 20762)
+++ lib/Parrot/Pmc2c/PMC.pm (working copy)
@@ -25,7 +25,7 @@
use warnings;
use base qw( Exporter );
our @EXPORT_OK = qw();
-use Data::Dumper;
+use Storable;
use Parrot::PMC;
use Parrot::Pmc2c::UtilFunctions qw(spew);
use Parrot::Pmc2c::Method;
@@ -61,9 +61,7 @@
#gen_parent_lookup_info( $self, $pmc2cMain, $pmcs );
#gen_parent_reverse_lookup_info( $self, $pmcs, $vtable_dump );
-my $Dumper = Data::Dumper-new( [$self], ['class'] );
-$Dumper-Indent(1);
-spew($self-filename('.dump'), $Dumper-Dump);
+store($self, $self-filename('.dump'));
}
#methods
Index: config/gen/makefiles/dynpmc_pl.in
===
--- config/gen/makefiles/dynpmc_pl.in (revision 20762)
+++ config/gen/makefiles/dynpmc_pl.in (working copy)
@@ -17,6 +17,10 @@
use warnings;
use File::Copy qw(copy);
+use FindBin;
+use lib $FindBin::Bin/../..;
+use lib $FindBin::Bin/../../lib;
+use Storable;
# q[] isn't guaranteed to work, but it's safer than as some platforms
# (eg FreeBSD) have s embedded in their substution values. q[] is used
@@ -189,8 +193,7 @@
my ( %group_files, %group_libs, %pmc_group, %pmc_libs );
for my $pmc (@pmcs) {
-our $class;
-require $pmc.dump;
+our $class = retrieve($pmc.dump);
# there can be many libs
my %libs = %{ $class-{flags}{lib} || {} };
Re: Current win32 linking issues: Summary
On Tue, 21 Aug 2007 13:08:05 +0200 Ron Blaschke [EMAIL PROTECTED] wrote: The win32 skippage will need to be removed again, once the PMCNULL symbol is exported correctly from libparrot.dll. Not adding the skip on the other t/src tests will cause them to fail. I think it would be best to skip them all, or none of them. Hi Ron, I agree. If we can't find a quick fix to get the tests to pass, I can clean things up to make them consistent (all-failing or all-skipped) before the release. I don't have a preference which route we take. Don't know if its a problem if they fail. I don't have a problem with failures as they tell me there's something that needs attention. True. Well, these issues do need attention, so maybe they *should* fail. :) 1. Do you have any ideas for how we need to decorate PMCNULL so it gets exported by the dll? PARROT_API doesn't seem to be sufficient. I think maybe its because its a variable, not a function. 2. Do you have any preference on how we fix up the Parrot::Config stuff so we can put libparrot.lib on the link command-line for win32, in the t/src/ tests? Sorry to ask so many questions, but I'm a linux geek, and utterly clueless about win32... Mark
Re: [perl #44769] [BUG] Parrot failing to 'make' on Darwin
On Mon, 20 Aug 2007 16:00:28 -0700 chromatic [EMAIL PROTECTED] wrote: On Monday 20 August 2007 05:13:07 James E Keenan wrote: t/src/compiler# '/usr/bin/g++-3.3 -L/usr/local/lib t/src/compiler_2.o src/parrot_config.o -o t/src/compiler_2 blib/lib/libparrot.a -lm' failed with exit code 1 # Failed to build 't/src/compiler_2': ld: multiple definitions of symbol _PMCNULL # t/src/compiler_2.o definition of _PMCNULL in section (__DATA,__common) # blib/lib/libparrot.a(pmc.o) definition of _PMCNULL in section (__DATA,__common) This one looks like fallout of r20649. Mark? I don't believe r20649 would cause duplicate definitions. Missing definitions, sure, but not duplicates. No, I think this is fallout from the win32 workaround I mentioned to you in #parrot a few days ago... a different commit. See r20641. The correct solution is to fix PARROT_API so libparrot.dll exports the PMCNULL global correctly, which will fix win32, and to remove the PMCNULL definitions from t/src/compiler.t, which will fix Darwin. I've been working on the win32 linker part of that, but haven't made any progress yet. I've been trying to make a test dll project to play with, but I can't seem to convince the linker to do the same thing with my dll that it does with parrot's. (It neglects to generate a .lib file, which seems needed for linking applications against the dll.) Mark
Re: [perl #44783] [PATCH] t/distro/file_metadata.t and git
On Sun, 19 Aug 2007 22:22:06 -0700 David Romano (via RT) [EMAIL PROTECTED] wrote: # New Ticket Created by David Romano # Please include the string: [perl #44783] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44783 Testing svn file metadata isn't always appropriate when using git. When git mirrors an svn repo, it can store the metadata for each file in .git/svn/git-svn/unhandled.log, but sometimes the user chooses not to store the metadata. If the user does store it, this patch allows for the tests to pass (and not hang). If the user doesn't have the metadata but has a .git directory, then the tests are skipped. Thanks, applied as r20743. I've used git-svn once or twice in the past for some branch merging, and it was a bit rough; the test suite hated it. Anything to make its use easier is a good thing, in my book. :) Mark
Current win32 linking issues: Summary
The parrot needs help, hopefully before tomorrow's release. There are two issues with linking against libparrot.dll on win32: 1. It refuses to export the _PMCNULL symbol (the PMCNULL global variable defined at the top of src/pmc.c), and thus, embedders cannot use the PMC_IS_NULL macro. This causes t/src/compiler.t to fail. Jerry added a workaround in r20641, declaring a local variable PMCNULL within the test code, to get it to pass. Unfortunately, this workaround causes Darwin to fail with the message ld: multiple definitions of symbol _PMCNULL. 2. The filenames written by Configure.pl are wrong. This causes the linker command line to get the wrong library-name. It looks like this: # 'link -nologo -nodefaultlib -debug -machine:x86 -debug t\src\string_3.obj src\parrot_config.obj -out:t\src\string_3.exe -Lblib\lib libparrot$(A) kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib' failed with exit code 80 # LINK : fatal error LNK1104: cannot open file 'libparrot$(A).obj' The variable $(A) is not expanded properly in the win32 shell. Quoth the Jerry: [18:30] @particle with gcc, you do -lparrot to find the library [18:31] @particle on win32, you do libparrot.lib [18:31] @particle in Parrot::Config, it's stored as libparrot$(A) [18:31] @particle during make, that evaluates to libparrot.lib [18:31] @particle but not in the shell, which is where that value is being used [18:31] @particle 2 ways to fix [18:32] @particle 1: put something in Parrot::Config that has what win32 needs [18:32] @particle 2: make a function available in Parrot::Config that resolves the variables, and call the func Once these two issues are resolved, the extra PMCNULL variables should be removed from t/src/compiler.t, which will make Darwin happy too. :) Please help! I'm clueless about win32... Mark
Re: Current win32 linking issues: Summary
On Mon, 20 Aug 2007 18:37:05 -0700 Mark Glines [EMAIL PROTECTED] wrote: Jerry added a workaround in r20641, declaring a local variable PMCNULL within the test code, to get it to pass. Unfortunately, this workaround causes Darwin to fail with the message ld: multiple definitions of symbol _PMCNULL. Quick followup: in r20750, I reverted this portion of r20641. The test passes again on Darwin, and is skipped again on win32. (I kept the typo fixes in compiler.t, and I didn't revert r20641's changes to the other test files.) The win32 skippage will need to be removed again, once the PMCNULL symbol is exported correctly from libparrot.dll. Mark
