[perl #51116] [BUG] languages/perl6/perl6 --target=past ignores -e
# New Ticket Created by Mitchell N Charity # Please include the string: [perl #51116] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=51116 > languages/perl6/perl6 --target=past gives no output with -e CODE. r25997 on fedora 8, x86_64. # works $ languages/perl6/perl6 -e 'say(3);' 3 # works $ echo -n 'say(3);' > deleteme.pm; languages/perl6/perl6 --target=past deleteme.pm # ...big past output... # doesn't work $ languages/perl6/perl6 --target=past -e 'say(3);' # no output at all Fyi. Thanks for all your work. Mitchell
Re: [perl #51116] [BUG] languages/perl6/perl6 --target=past ignores -e
On Friday 22 February 2008 16:50:35 Mitchell N Charity wrote: > languages/perl6/perl6 --target=past gives no output with -e CODE. > r25997 on fedora 8, x86_64. > > # works > $ languages/perl6/perl6 -e 'say(3);' > 3 > > # works > $ echo -n 'say(3);' > deleteme.pm; languages/perl6/perl6 --target=past > deleteme.pm > # ...big past output... > > # doesn't work > $ languages/perl6/perl6 --target=past -e 'say(3);' > # no output at all Confirmed on 32-bit Linux, confirmed also with perl6.pbc. The problem's not in pbc_to_exe; it's in PCT, specifically HLLCompiler. The attached patch fixes things. It's slightly quick and dirty. A better solution is to clean up compile() further to handle adverb combinations. However, this patch works. -- c --- compilers/pct/src/PCT/HLLCompiler.pir (revision 26008) +++ compilers/pct/src/PCT/HLLCompiler.pir (local) @@ -712,7 +714,8 @@ self.'version'() goto end eval_line: -self.'eval'($S0, adverbs :flat :named) +result = self.'eval'($S0, adverbs :flat :named) +goto save_output .end
Re: [perl #51122] GC bug in bytecode loading (again)
On Friday 22 February 2008 19:52:29 Bob Rogers wrote: > The "[loading list.pbc]" message shows that it is dying in the > load_bytecode op for this file. (If the bug fails to manifest, the code > will fail to find a *.pbc file in fairly short order.) > >In GDB, the backtrace from the segfault looks like this, where the > second argument to ascii_compare is an invalid STRING *, that came from > the HLL ID hash. Is this after r25990? -- c
Re: [perl #47978] [C99] [IMCC] double free
On Thursday 29 November 2007 20:34:17 Will Coleda wrote: > On feather, languages/c99 (et al.) fail with: > > $ make > ../../parrot -o src/CPP_PGE2AST.pbc --output-pbc src/CPP_PGE2AST.pir > *** glibc detected *** ../../parrot: double free or corruption > (fasttop): 0x0823e328 *** > > running this through gdb, I get: > > bt > #0 0xb7f41402 in __kernel_vsyscall () > #1 0xb6f77a85 in raise () from /lib/i686/nosegneg/libc.so.6 > #2 0xb6f794e1 in abort () from /lib/i686/nosegneg/libc.so.6 > #3 0xb6faf7dc in __libc_message () from /lib/i686/nosegneg/libc.so.6 > #4 0xb6fb7755 in _int_free () from /lib/i686/nosegneg/libc.so.6 > #5 0xb6fbb270 in free () from /lib/i686/nosegneg/libc.so.6 > #6 0xb7e75ad5 in read_macro (valp=0xbfc40c4c, interp=0x804f008, > yyscanner=0x8235678) at compilers/imcc/imcc.l:888 > #7 0xb7e71d71 in yylex (valp=0xbfc40c4c, yyscanner=0x8235678, > interp=0x804f008) > at compilers/imcc/imcc.l:385 > #8 0xb7e6b85d in yyparse (yyscanner=0x8235678, interp=0x804f008) > at compilers/imcc/imcparser.c:2598 > #9 0xb7e7856a in compile_to_bytecode (interp=0x804f008, > sourcefile=0xbfc41bb5 "src/CPP_PGE2AST.pir", > output_file=0xbfc41b94 "src/CPP_PGE2AST.pbc") at compilers/imcc/ > main.c:960 > #10 0xb7e788f6 in imcc_run (interp=0x804f008, > sourcefile=0xbfc41bb5 "src/CPP_PGE2AST.pir", argc=1, > argv=0xbfc40ec4) > at compilers/imcc/main.c:1060 > #11 0x0804896d in main (argc=1, argv=0xbfc40ec4) at src/main.c:62 > > compilers/imcc/imcc.l:888 seems to be where it goes off the rails.. > > IANACP, but there seems to be several calls to 'free(valp->s)' in > that function that aren't careful about not freeing that pointer more > than once. Andy and I cleaned up a lot of these; can you reproduce it? -- c
[perl #51124] [TODO] Remove docs/imcc/macros.html from website
# New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #51124] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=51124 > docs/imcc/macros.pod has been removed from the repository. This document can also be found on the website, but obviously it's no longer there as the source has been removed: http://www.parrotcode.org/docs/imcc/macros.html This should be removed from the website. (Sorry, don't have access myself) kjs
[perl #32667] [TODO] IMCC - documentation needs updating
imcc's documentation is up to date.
[perl #50920] [BUG]: t/compilers/imcc/syn/macro.t failing on Darwin
On Fri Feb 22 20:18:03 2008, [EMAIL PROTECTED] wrote: > > > > > The test passed at 25900. > > > > and it passed at 25950. I'll have to pick up on this tomorrow. And it passed at 25973.
[perl #43481] t/examples/shootout.t (shootout_16.pir) fails on gentoo/x86
The vampire has lain cold for a week. I'm resolving the ticket. Any new instances of failure in t/examples/shootout.t should open a new ticket (albeit one which should refer back to this one). kid51
Re: [svn:parrot] r25990 - trunk/src/pmc
On Friday, February 22, 2008 10:50 PM [EMAIL PROTECTED] wrote: On Friday 22 February 2008 08:45:42 [EMAIL PROTECTED] wrote: Modified: trunk/src/pmc/parrotinterpreter.pmc Log: In thawfinish, delay setting constant flag on lib_name until Parrot_load_lib has been called, to avoid corruption in iglobals during GC. This fixes segfault attempting to run tcl tests on some platforms. Very nice. How in the world did you find this? I know there's some weird bug somewhere related to doing a string_copy from a constant string to a non-constant string, but I've never been able to track it down. -- c I committed this because it fixed the specific problem I was having with lib_name, and helped track down the problem; but it is not the correct solution, as shown by bug #51122.from Bob Rogers, which shows the same problem but on hll_name. The true problem is that it is not safe to set the constant flag on a string after creation, as the constant flag implies that the string's data content is stored in a non-garbage-collectable area, which is only true if the flag is set before the storage is allocated, so the allocation can be from to the constant pool. Removing the setting of the flag breaks assertions in Parrot_register_HLL*, but these need to be fixed. Peter Gibbs
Re: [perl #51104] [BUG] bad pointer! segfaults are bad!
Jerry Gay (via RT) wrote: # New Ticket Created by Jerry Gay # Please include the string: [perl #51104] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=51104 > during the build of languages/c99, specifically: ..\..\parrot.exe -o src\CPP_PGE2AST.pbc --output-pbc src\CPP_PGE2AST.pir boom. msvcr80.dll!strlen(unsigned char * buf=0x0400) Line 81 Asm libparrot.dll!read_macro(YYSTYPE * valp=0x0017fb8c, parrot_interp_t * interp=0x03ab1248, void * yyscanner=0x03be5ec0) Line 991 + 0xb bytes C libparrot.dll!yylex(YYSTYPE * valp=0x0017fb8c, void * yyscanner=0x03be5ec0, parrot_interp_t * interp=0x03ab1248) Line 425 + 0x11 bytes C libparrot.dll!yyparse(void * yyscanner=0x03be5ec0, parrot_interp_t * interp=0x03ab1248) Line 2601 + 0x14 bytes C libparrot.dll!compile_to_bytecode(parrot_interp_t * interp=0x03ab1248, const char * const sourcefile=0x03ab1219, const char * const output_file=0x03ab11f8) Line 951 + 0xd bytes C libparrot.dll!imcc_run(parrot_interp_t * interp=0x03ab1248, const char * sourcefile=0x03ab1219, int argc=1, const char * * argv=0x03ab11c8) Line 1051 + 0x11 bytesC parrot.exe!main(int argc=1, const char * * argv=0x03ab11c8) Line 56 + 0x15 bytesC parrot.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C kernel32.dll!76d019f1() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] ntdll.dll!7775d109() at line 990 in imcc.l, valp is uninitialized. it's full of bad pointers. i haven't tracked down why. any help? I think this is the same as "[perl#47978][C99][IMCC] double free". The issue seems to be caused by languages/c99/src/preamble, where: .local $iter_loop: Consider this test program. $cat m.pir .macro test .local $iter_loop: .endm $ parrot -o m.pbc --output-pbc m.pir compilers/imcc/imcc.l:992: failed assertion 'valp->s' (Remove the colon and it parses again.) I could track it down as far as read_macro in imcc.l, where line 1015 does not fill valp, and returns the token MACRO. c = yylex(valp, yyscanner, interp); Ron
Re: [perl #47978] [C99] [IMCC] double free
chromatic wrote: On Thursday 29 November 2007 20:34:17 Will Coleda wrote: On feather, languages/c99 (et al.) fail with: $ make ../../parrot -o src/CPP_PGE2AST.pbc --output-pbc src/CPP_PGE2AST.pir *** glibc detected *** ../../parrot: double free or corruption (fasttop): 0x0823e328 *** running this through gdb, I get: bt #0 0xb7f41402 in __kernel_vsyscall () #1 0xb6f77a85 in raise () from /lib/i686/nosegneg/libc.so.6 #2 0xb6f794e1 in abort () from /lib/i686/nosegneg/libc.so.6 #3 0xb6faf7dc in __libc_message () from /lib/i686/nosegneg/libc.so.6 #4 0xb6fb7755 in _int_free () from /lib/i686/nosegneg/libc.so.6 #5 0xb6fbb270 in free () from /lib/i686/nosegneg/libc.so.6 #6 0xb7e75ad5 in read_macro (valp=0xbfc40c4c, interp=0x804f008, yyscanner=0x8235678) at compilers/imcc/imcc.l:888 #7 0xb7e71d71 in yylex (valp=0xbfc40c4c, yyscanner=0x8235678, interp=0x804f008) at compilers/imcc/imcc.l:385 #8 0xb7e6b85d in yyparse (yyscanner=0x8235678, interp=0x804f008) at compilers/imcc/imcparser.c:2598 #9 0xb7e7856a in compile_to_bytecode (interp=0x804f008, sourcefile=0xbfc41bb5 "src/CPP_PGE2AST.pir", output_file=0xbfc41b94 "src/CPP_PGE2AST.pbc") at compilers/imcc/ main.c:960 #10 0xb7e788f6 in imcc_run (interp=0x804f008, sourcefile=0xbfc41bb5 "src/CPP_PGE2AST.pir", argc=1, argv=0xbfc40ec4) at compilers/imcc/main.c:1060 #11 0x0804896d in main (argc=1, argv=0xbfc40ec4) at src/main.c:62 compilers/imcc/imcc.l:888 seems to be where it goes off the rails.. IANACP, but there seems to be several calls to 'free(valp->s)' in that function that aren't careful about not freeing that pointer more than once. I think this is the same as "[perl#51104][BUG] bad pointer! segfaults are bad!". The issue seems to be caused by languages/c99/src/preamble, where: .local $iter_loop: Consider this test program. $cat m.pir .macro test .local $iter_loop: .endm $ parrot -o m.pbc --output-pbc m.pir compilers/imcc/imcc.l:992: failed assertion 'valp->s' (Remove the colon and it parses again.) I could track it down as far as read_macro in imcc.l, where line 1015 does not fill valp, and returns the token MACRO. c = yylex(valp, yyscanner, interp); Ron
Re: [svn:parrot] r26013 - trunk/src
On Sat, Feb 23, 2008 at 6:44 AM, <[EMAIL PROTECTED]> wrote: > Author: paultcochrane > Date: Sat Feb 23 03:44:12 2008 > New Revision: 26013 > > Modified: >trunk/src/oo.c (props changed) > > Log: > [core] For some reason svk hasn't picked up the svn properties properly, so > setting them here. This in some sense is a test commit (for that I > apologise in advance) so that I can make sure I haven't killed anything on > the svn side. If this works, all the other files in my svk working copy > with the appropriately updated svn properties will be committed. > > I just checked the properties in the repository for this file before and after your commit, and they seem identical. What specifically were you trying to change here? If the test is failing on your svk instance and not your svn instance, I would tend to suspect that your svk repo is out of whack. This used to happen to Chip and I on a regular basis. (I was never able to resolve my svk issues to my satisfaction; I switched back to svn.) FYI: $svn up -r 26012 && svn pl --verbose src/oo.c Properties on 'src/oo.c': svn:keywords : Author Date Id Revision svn:eol-style : native $svn up -r 26013 && svn pl --verbose src/oo.c Properties on 'src/oo.c': svn:keywords : Author Date Id Revision svn:eol-style : native (It might be helpful if our svn commit messages showed the properties that were updated on the commit) -- Will "Coke" Coleda
Re: [perl #51122] GC bug in bytecode loading (again)
- Original Message - From: "Bob Rogers (via RT)" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, February 23, 2008 5:52 AM Subject: [perl #51122] GC bug in bytecode loading (again) To reproduce, unpack the attached tarball as follows: copy. Then: [EMAIL PROTECTED]> make make: *** [all] Segmentation fault Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1215781184 (LWP 15318)] 0xb7d33e62 in ascii_compare (interp=0x8050008, lhs=0x82855a0, rhs=0xb77eaa14) at src/charset/ascii.c:474 -- Bob Rogers http://rgrjr.dyndns.org/ Hi Bob Please try revision 26025. This should be a full fix for the problem I started working on in r25990. Regards Peter Gibbs
Re: [perl #51000] [BUG] t/src/intlist.t failures.
On Fri, Feb 22, 2008 at 9:58 PM, James Keenan via RT <[EMAIL PROTECTED]> wrote: > > Coke: > > Last weekend I applied a patch in r25788 which corrected persistent > problems in src/list.c and thereby enabled t/src/intlist.t to pass for > the first time in a month. > > In this RT, you report that t/src/intlist.t is again failing -- this > time failing all its tests. > > Was t/src/intlist.t passing or failing for you as of r25788? If it was > passing, do you know at what revision it started to fail again? > > Thank you very much. > > kid51 > > > This appears to be failing identically in both r25787 and r25788 (and from then on, at least in a few spot checks through r26000) My suspicion is that the original tickets chromatic opened about these test files need to be implemented. -- Will "Coke" Coleda
Re: [perl #51122] GC bug in bytecode loading (again)
From: "chromatic via RT" <[EMAIL PROTECTED]> Date: Sat, 23 Feb 2008 01:29:53 -0800 On Friday 22 February 2008 19:52:29 Bob Rogers wrote: > The "[loading list.pbc]" message shows that it is dying in the > load_bytecode op for this file. (If the bug fails to manifest, the code > will fail to find a *.pbc file in fairly short order.) > >In GDB, the backtrace from the segfault looks like this, where the > second argument to ascii_compare is an invalid STRING *, that came from > the HLL ID hash. Is this after r25990? -- c Yes; r25998 to be exact. -- Bob
[svn:perl6-synopsis] r14515 - doc/trunk/design/syn
Author: larry Date: Sat Feb 23 09:40:46 2008 New Revision: 14515 Modified: doc/trunk/design/syn/S12.pod Log: some clarifications on multiple dispatch and protos Modified: doc/trunk/design/syn/S12.pod == --- doc/trunk/design/syn/S12.pod(original) +++ doc/trunk/design/syn/S12.podSat Feb 23 09:40:46 2008 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 27 Oct 2004 - Last Modified: 15 Feb 2008 + Last Modified: 23 Feb 2008 Number: 12 - Version: 57 + Version: 58 =head1 Overview @@ -894,16 +894,25 @@ Only one such sub (or method) can inhabit a given namespace, and it hides any outer subs (or less-derived methods) of the same short name. -The default C declarations provided by Perl from the global scope -are I propagated to the user's scope unless explicitly imported, -so a C declaration there that happens to be the same as a global -multi is considered C unless explicitly marked C. +The default C declarations provided by Perl from the global +scope are I automatically propagated to the user's scope +unless explicitly imported, so a C declaration there that +happens to be the same as a global multi is considered C unless +explicitly marked C. In the absence of such an explicit C +declaration, however, the global proto is used by the compiler in +the analysis of any calls to that short name. (Since only list +operators may be post-declared, as soon as the compiler sees a +non-listop operator it is free to apply the global C since +any user-defined C version of it must of necessity be declared +earlier in the user's lexical scope or not at all.) -A C may share with multis declared after it in the same scope, +A C may share dispatch with multis declared after it in the same scope, but in that case it functions only as the final tie-breaker if the inner multies can't decide among themselves what to do. (It may then, of course, decide to redispatch outside of the current scope.) -The signature of such a proto-multi also nails down the presumed order + +Within its scope, +the signature of a C also nails down the presumed order and naming of positional parameters, so that any multi call with named arguments in that scope can presume to rearrange those arguments into positional parameters based on that information. (Unrecognized names @@ -943,7 +952,7 @@ considered, and the best matching default routine is used. If there are no default routines, or if the available defaults are also tied, a final tie-breaking proto sub is called, if there is one (see above). -Otherwise an exception is thrown. +Otherwise the dispatch fails. The order in which candidates are considered is defined by a topological sort based on the "type narrowness" of each candidate's
Re: [svn:parrot] r26013 - trunk/src
> I just checked the properties in the repository for this file before > and after your commit, and they seem identical. Yeah, that happened to me too but in my svn checkout. In the svk checkout things seemed as though things weren't correct, so I committed the changes. > If the test is failing on your svk instance and not your svn instance, > I would tend to suspect that your svk repo is out of whack. This used > to happen to Chip and I on a regular basis. (I was never able to > resolve my svk issues to my satisfaction; I switched back to svn.) I switched back to svn after problems early on in my parrot involvement, however, I thought I'd give svk 2.02 a go, but it seems to have "issues". It's also doing some funny things like making checkins it's already done from the last 'svk up -sm'. *sigh* I guess I'd best go back to svn then... Thanks for keeping a watchful eye on things :-) Paul
Re: [svn:perl6-synopsis] r14515 - doc/trunk/design/syn
Hm, I see a minor nit... On Feb 23, 2008, at 12:40 , [EMAIL PROTECTED] wrote: +A C may share dispatch with multis declared after it in the same scope, -^^ but in that case it functions only as the final tie-breaker if the inner multies can't decide among themselves what to do. (It may ^?^ -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: [perl #51122] GC bug in bytecode loading (again)
From: "Peter Gibbs via RT" <[EMAIL PROTECTED]> Date: Sat, 23 Feb 2008 07:57:13 -0800 Hi Bob Please try revision 26025. This should be a full fix for the problem I started working on in r25990. Regards Peter Gibbs Works like a champ in r26026. Thanks heaps for the swift turnaround! -- Bob
Re: [svn:parrot] r26013 - trunk/src
On Saturday 23 February 2008 09:40:52 Paul Cochrane wrote: > > I just checked the properties in the repository for this file before > > and after your commit, and they seem identical. > Yeah, that happened to me too but in my svn checkout. In the svk > checkout things seemed as though things weren't correct, so I > committed the changes. That happened to me once too. I couldn't ever reproduce it to file a bug against svk, but I dumped and reloaded my repository and things work again. -- c
Re: Perl 6 fundraising and related topics.
On Fri, Feb 22, 2008 at 7:38 PM, Dave Rolsky <[EMAIL PROTECTED]> wrote: > On Thu, 21 Feb 2008, Joshua Gatcomb wrote: > > > I am mostly ignoring the rest of what others have said in this thread > > because I think it is detracting from your intention of getting money to > > people to work more. Here is one thing that has frustrated me about TPF. > > They are a non-profit organization. Yeah, kind of suprising that would be > > the frustrating thing. The issue is that they can't take money from Bob to > > give to Sue to work on Bob's widget. This is an extreme oversimplification > > but in general, they have to abide by the rules that allow them to keep > > their non-profit status. Where am I going with this? > > This doesn't make any sense to me. There's nothing about being a nonprofit > that prevents TPF from accepting donations targeted to a specific program. > There's a bit of accounting overhead to make it happen, but it's perfectly > legal and in keeping with TPF's 501c3 status and its mission. I don't know but I think I was told at least once that TPF cannot handle donations targeted to a specific person. That might of course be different then targeting at specific program, I am not familiar what 501c3 means. Personally - and there might be few others - I'd be much more comfortable to give money to a specific target or person than to a general pool. What I was hoping for a long time is to be able to give a modest amount on a monthly basis. Currently AFAIK TPF can only accept stand alone payments. IMHO many people in the community would be ready to give 5-10-20 USD/month but it would be much harder to get them give 100 or 200 USD once a year. How hard would it be to enable (Paypal?) recurring monthly payments to TPF? How hard would it be to allow people to target their money to a specific project/person? TPF can then still focus on raising money from corporations. Gabor -- Gabor Szabo http://www.szabgab.com/
Re: interpolating complex closures
On Fri, Feb 15, 2008 at 03:12:20PM -0800, Larry Wall wrote: > No, there's no problem with that. This is Perl 6, which is full of > wonderfulness, not Perl 5, which was written by a person of minimal clue. :) > > That's part of what S02 means right at the top where it's talking > about a one-pass parser. There's no lookahead to find the end of a > construct. You just come to it when you come to it, and the parser > has to be smart enough to know which terminators mean what in each > context. > > Larry Hmm, just when editors have gotten smart enough about parsing to often get the colouring right for perl 5...
Re: [perl #47978] [C99] [IMCC] double free
On Sat, Feb 23, 2008 at 5:00 PM, Ron Blaschke <[EMAIL PROTECTED]> wrote: > chromatic wrote: > > On Thursday 29 November 2007 20:34:17 Will Coleda wrote: > > > >> On feather, languages/c99 (et al.) fail with: > >> > >> $ make > >> ../../parrot -o src/CPP_PGE2AST.pbc --output-pbc src/CPP_PGE2AST.pir > >> *** glibc detected *** ../../parrot: double free or corruption > >> (fasttop): 0x0823e328 *** > >> > >> running this through gdb, I get: > >> > >> bt > >> #0 0xb7f41402 in __kernel_vsyscall () > >> #1 0xb6f77a85 in raise () from /lib/i686/nosegneg/libc.so.6 > >> #2 0xb6f794e1 in abort () from /lib/i686/nosegneg/libc.so.6 > >> #3 0xb6faf7dc in __libc_message () from /lib/i686/nosegneg/libc.so.6 > >> #4 0xb6fb7755 in _int_free () from /lib/i686/nosegneg/libc.so.6 > >> #5 0xb6fbb270 in free () from /lib/i686/nosegneg/libc.so.6 > >> #6 0xb7e75ad5 in read_macro (valp=0xbfc40c4c, interp=0x804f008, > >> yyscanner=0x8235678) at compilers/imcc/imcc.l:888 > >> #7 0xb7e71d71 in yylex (valp=0xbfc40c4c, yyscanner=0x8235678, > >> interp=0x804f008) > >> at compilers/imcc/imcc.l:385 > >> #8 0xb7e6b85d in yyparse (yyscanner=0x8235678, interp=0x804f008) > >> at compilers/imcc/imcparser.c:2598 > >> #9 0xb7e7856a in compile_to_bytecode (interp=0x804f008, > >> sourcefile=0xbfc41bb5 "src/CPP_PGE2AST.pir", > >> output_file=0xbfc41b94 "src/CPP_PGE2AST.pbc") at compilers/imcc/ > >> main.c:960 > >> #10 0xb7e788f6 in imcc_run (interp=0x804f008, > >> sourcefile=0xbfc41bb5 "src/CPP_PGE2AST.pir", argc=1, > >> argv=0xbfc40ec4) > >> at compilers/imcc/main.c:1060 > >> #11 0x0804896d in main (argc=1, argv=0xbfc40ec4) at src/main.c:62 > >> > >> compilers/imcc/imcc.l:888 seems to be where it goes off the rails.. > >> > >> IANACP, but there seems to be several calls to 'free(valp->s)' in > >> that function that aren't careful about not freeing that pointer more > >> than once. > > I think this is the same as "[perl#51104][BUG] bad pointer! segfaults > are bad!". > > The issue seems to be caused by languages/c99/src/preamble, where: > > .local $iter_loop: > > Consider this test program. > > $cat m.pir > .macro test > .local $iter_loop: > .endm > > $ parrot -o m.pbc --output-pbc m.pir > compilers/imcc/imcc.l:992: failed assertion 'valp->s' > > (Remove the colon and it parses again.) > that makes sense, now i see this: .local is not valid anymore to declare labels, you should use .label. kjs > > I could track it down as far as read_macro in imcc.l, where line 1015 > does not fill valp, and returns the token MACRO. > > c = yylex(valp, yyscanner, interp); > > Ron >
[perl #47391] t/configure/1*.t tests incorrectly rely on init::defaults
A patch has been posted to a related ticket that addresses the issues raised in this ticket. See http://rt.perl.org/rt3/Ticket/Attachment/362970/163286/diff.trunk.tcif.txt. Thank you very much. kid51
Re: [perl #51122] GC bug in bytecode loading (again)
From: Bob Rogers <[EMAIL PROTECTED]> Date: Sat, 23 Feb 2008 12:44:02 -0500 From: "Peter Gibbs via RT" <[EMAIL PROTECTED]> Date: Sat, 23 Feb 2008 07:57:13 -0800 Hi Bob Please try revision 26025. This should be a full fix for the problem I started working on in r25990. Regards Peter Gibbs Works like a champ in r26026. Thanks heaps for the swift turnaround! Oops; I spoke too soon. It turns out that r26025 causes the #50040 test case to break again (I checked that it still worked in r26024). So perhaps the change chromatic made didn't actually fix it . . . -- Bob
RE: Perl 6 fundraising and related topics.
> From: Gabor Szabo [mailto:[EMAIL PROTECTED] > Sent: Saturday, February 23, 2008 2:04 PM > > On Fri, Feb 22, 2008 at 7:38 PM, Dave Rolsky <[EMAIL PROTECTED]> wrote: > > On Thu, 21 Feb 2008, Joshua Gatcomb wrote: > > > > > I am mostly ignoring the rest of what others have said in this > thread > > > because I think it is detracting from your intention of getting > money to > > > people to work more. Here is one thing that has frustrated me > about TPF. > > > They are a non-profit organization. Yeah, kind of suprising that > would be > > > the frustrating thing. The issue is that they can't take money > from Bob to > > > give to Sue to work on Bob's widget. This is an extreme > oversimplification > > > but in general, they have to abide by the rules that allow them to > keep > > > their non-profit status. Where am I going with this? > > > > This doesn't make any sense to me. There's nothing about being a > nonprofit > > that prevents TPF from accepting donations targeted to a specific > program. > > There's a bit of accounting overhead to make it happen, but it's > perfectly > > legal and in keeping with TPF's 501c3 status and its mission. > > I don't know but I think I was told at least once that TPF cannot > handle donations > targeted to a specific person. That might of course be different then > targeting > at specific program, I am not familiar what 501c3 means. > > Personally - and there might be few others - I'd be much more > comfortable to give > money to a specific target or person than to a general pool. > > What I was hoping for a long time is to be able to give a modest amount > on a monthly basis. Currently AFAIK TPF can only accept stand alone > payments. > > IMHO many people in the community would be ready to give 5-10-20 > USD/month but > it would be much harder to get them give 100 or 200 USD once a year. > > How hard would it be to enable (Paypal?) recurring monthly payments to > TPF? > How hard would it be to allow people to target their money to a > specific project/person? > > > TPF can then still focus on raising money from corporations. Good ideas/questions. TIMTOWTDI. A couple of quick comments (for everyone): (1) Richard Dice (TPF) recently left for a week of $work travel and might not be able to reply for a while, so please be patient and considerate. (2) Please direct all follow-ups to just the perl6-users list. My apologies to others with likewise-cluttered in-boxes for neglecting to request this in my initial post. Meanwhile, thanks for everyone's suggestions. I'm sure that we'll eventually see some major improvements, one way or another. Best regards, Conrad Schneiker www.AthenaLab.com http://www.perlfoundation.org/perl6 - Official Perl 6 Wiki http://www.perlfoundation.org/parrot - Official Parrot Wiki
Re: Perl 6 fundraising and related topics.
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> By the way, it's possible that I might deserve a little more money, LW> because *my* cat died last year, and as near as I can tell, I didn't LW> spend any money on girls and booze because of it... :) i will donate to get larry a new cat. in fact we can probably find a free stray or extra kitten somewhere near him. will this make perl 6 happen before christmas? :-) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.sysarch.com -- - Perl Architecture, Development, Training, Support, Code Review -- --- Search or Offer Perl Jobs - http://jobs.perl.org - - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
[perl #51136] [BUG] Segfault in Parrot_Ref_morph
# New Ticket Created by Will Coleda # Please include the string: [perl #51136] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=51136 > As of r26037, tcl is once again generating a segfault (even on feather!). The change in 26037 was to replace a morph + assign with the 'copy' opcode. To trigger it, run: ../../parrot tcl.pbc t/cmd_lassign.t Oddly, the backtrace is slightly different on feather and my os x intel box. Feather: (gdb) bt#0 0xb7dd529f in Parrot_Object_morph (interp=0x804f008, pmc=0xb6b04120, type=133) at ./src/pmc/object.c:2557 #1 0xb7b96e91 in Parrot_copy_p_p (cur_opcode=0xb6c9f00c, interp=0x804f008)at src/ops/set.ops:553 #2 0xb7c21d64 in runops_slow_core (interp=0x804f008, pc=0xb6c9f00c) at src/runops_cores.c:213 #3 0xb7bedac6 in runops_int (interp=0x804f008, offset=3308)at src/interpreter.c:878 #4 0xb7bee407 in runops (interp=0x804f008, offs=3) at src/inter_run.c:104 #5 0xb7bee696 in runops_args (interp=0x804f008, sub=0x826f170, obj=0x80937b8, meth_unused=0x0, sig=0xb7e46cc3 "vP", ap=0xbff9c70c "??&\bH???\220??X$\017\b??&\bp?&\b\030\016?H???2$?\b?\004\b\002") at src/inter_run.c:230 #6 0xb7bee7cc in Parrot_runops_fromc_args (interp=0x804f008, sub=0x826f170, sig=0xb7e46cc3 "vP") at src/inter_run.c:299 #7 0xb7bd6be7 in Parrot_runcode (interp=0x804f008, argc=2, argv=0xbff9c878)at src/embed.c:912 #8 0xb7e22432 in imcc_run_pbc (interp=0x804f008, obj_file=0, output_file=0x0, argc=2, argv=0xbff9c878) at compilers/imcc/main.c:794 #9 0xb7e22e22 in imcc_run (interp=0x804f008, sourcefile=0xbff9c9f9 "tcl.pbc", argc=2, argv=0xbff9c878) at compilers/imcc/main.c:1076 #10 0x080488c2 in main (argc=2, argv=0xbff9c878) at src/main.c:56 OS X intel: (gdb) bt #0 0x0118c3cc in Parrot_Ref_morph (interp=0x3003e0, pmc=0x775488, type=133) at ./src/pmc/ref.c:744 #1 0x0102f824 in Parrot_copy_p_p (cur_opcode=0x648d10, interp=0x3003e0) at src/ops/set.ops:553 #2 0x010bce7e in runops_slow_core (interp=0x3003e0, pc=0x648d10) at src/runops_cores.c:213 #3 0x01088ee3 in runops_int (interp=0x3003e0, offset=3308) at src/interpreter.c:878 #4 0x010898f6 in runops (interp=0x3003e0, offs=3) at src/inter_run.c:104 #5 0x01089b98 in runops_args (interp=0x3003e0, sub=0x4ab200, obj=0x302ec48, meth_unused=0x0, sig=0x12564c8 "vP", ap=0xba3c "??J") at src/inter_run.c:230 #6 0x01089cd8 in Parrot_runops_fromc_args (interp=0x3003e0, sub=0x4ab200, sig=0x12564c8 "vP") at src/inter_run.c:299 #7 0x01071f5c in Parrot_runcode (interp=0x3003e0, argc=2, argv=0xbb88) at src/embed.c:912 #8 0x01231d7c in imcc_run_pbc (interp=0x3003e0, obj_file=0, output_file=0x0, argc=2, argv=0xbb88) at compilers/imcc/main.c:794 #9 0x0123282a in imcc_run (interp=0x3003e0, sourcefile=0xbc27 "tcl.pbc", argc=2, argv=0xbb88) at compilers/imcc/main.c:1076 #10 0x23cc in main (argc=2, argv=0xbb88) at src/main.c:56 -- Will "Coke" Coleda
