Re: GSOC 2012
On Mar 27, 2012, at 11:51 AM, Andrew Whitworth wrote: Also since TPF didn't get into GSOC this year, Parrot is willing to host Rakudo-related projects. This surprised me when I saw the list of projects. Do you know why TPF didn't get in? Were they not accepted? Or did they not apply? Or a combination of the two? xoa -- Andy Lester = a...@petdance.com = www.petdance.com = AIM:petdance
Re: GSOC 2012
On Mar 27, 2012, at 12:04 PM, Brandon Allbery wrote: This surprised me when I saw the list of projects. Do you know why TPF didn't get in? Were they not accepted? Or did they not apply? Or a combination of the two? Google seems to have gone for some new blood and dumped some old timers to make room; dunno if this applies to TPF, I know MacPorts got rejected solely on that basis though. Sorry, I didn't mean to stir this all up again. I retract my query in hopes it will stanch the impending meta-discussions. Thanks, xoxo, Andy -- Andy Lester = a...@petdance.com = www.petdance.com = AIM:petdance
Rakudo.org upgrade
I'm going to be switching Rakudo.org to Drupal tonight from Movable Type. All the existing blog entries will no longer be able to have comments made on them, and will move to an /archive/ directory. Please don't make any blog posting in rakudo.org today. If you are a blogger on Movable Type on rakudo.org now, and I haven't set up a new account for you, please let me know and I'll set one up. Thanks, xoxo, Andy -- Andy Lester = a...@petdance.com = www.petdance.com = AIM:petdance
Re: [PATCH] Add .trim method
On Jan 12, 2009, at 11:27 AM, Carl Mäsak wrote: How about .trim(:start) and .trim(:end)? And .trim(:both) for orthogonality. -- Andy Lester = a...@petdance.com = www.petdance.com = AIM:petdance
Rakudo in Perl culture
I like the sound of Rakudo Tuesday. xoa Begin forwarded message: From: Joe Kline gi...@purdue.edu Date: January 8, 2009 2:51:53 PM CST To: Purdue Perl Mongers purdue...@pm.org Subject: [Purdue-pm] meeting date -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - From a recent blog entry by chromatic on use.perl.org: We release a new stable version of Rakudo on the third Tuesday every month, as we've done every month since November 2007 So our meeting date is Rakudo Tuesday. :-) joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFJZmdob0mzA2gRTpkRAqidAJ9bG6olYr+HZZosOG75BiM77SWEoQCeLxns 5jxJ3qOuWNDlfqiwSxmIm8k= =7VJE -END PGP SIGNATURE- ___ Purdue-pm mailing list purdue...@pm.org http://mail.pm.org/mailman/listinfo/purdue-pm -- Andy Lester = a...@petdance.com = www.petdance.com = AIM:petdance
Re: Rakudo in Perl culture
On Jan 8, 2009, at 3:11 PM, chromatic wrote: I can't read the word Purdue without thinking Year of the Purdue Wonder Chicken -- but try working that into Perl 6 advocacy. Except that's Perdue. xoa -- Andy Lester = a...@petdance.com = www.petdance.com = AIM:petdance
Re: Ticket #105 (NULL checks)
On Dec 31, 2008, at 3:50 PM, Andy Dougherty wrote: We can solve it by getting rid of the attribute_nonnull decorations and replacing them with assert()s. An even better solution is to keep the attribute_nonnull and also add asserts. The ARGIN()/ARGOUT() decorators are useful both to GCC and to splint, and who knows what other compiler that might come along. They also help document the expected API. xoxo, Andy -- Andy Lester = a...@petdance.com = www.petdance.com = AIM:petdance
fudging the headerizer
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? Thanks, xoxo, Andy -- Andy Lester = a...@petdance.com = www.petdance.com = AIM:petdance
Re: fudging the headerizer
On Dec 27, 2008, at 11:03 AM, Mark Glines wrote: 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: OK, I'll come up with a solution for that somehow. For now, your #ifdefs are getting removed by the headerizer in the commit I'm about to make, so you'll have to live with the compiler warnings, which shouldn't be too odious, I hope? xoxo, Andy -- Andy Lester = a...@petdance.com = www.petdance.com = AIM:petdance
Re: For your encouragement
On Dec 5, 2008, at 4:13 AM, Simon Cozens wrote: I just ran this code, which worked with the expected results: Beautiful. Posted to Perlbuzz. http://perlbuzz.com/2008/12/database-access-in-perl-6-is-coming-along-nicely.html xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: For your encouragement
On Dec 5, 2008, at 1:11 PM, Geoffrey Broadwell wrote: I can't, because as Perlbuzz oh-so-helpfully tells me when I try to submit my comment: Registration is required. With no indication how to actually do so. You have to have JavaScript turned on. Sorry that the message sucks. It's on my to-do list to fix. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: For your encouragement
On Dec 5, 2008, at 3:41 PM, Geoffrey Broadwell wrote: OK, that's fair enough -- but why does submitting a dead simple form require JavaScript? Got me. Hmmm, maybe I should be taking this up with the MT developers. Are you running a current enough rev that it's likely still a problem? (I don't want to go through the trouble of installing a local MT just to check that. :-) No, I'm not current. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: For your encouragement
On Dec 5, 2008, at 6:33 PM, Simon Cozens wrote: It's Perl people, Geoffrey. You tell them that you've made a racing car out of old biscuit tins, they'll tell you that you painted it the wrong colour. s/Perl//; But I agree with you, it's frustrating that that's what people choose to see. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Branching
On Aug 5, 2008, at 11:12 AM, chromatic wrote: Don't use long-lived branches. The smaller the merge in *any* system, the easier it is. I agree 100%. If you think your project is so big that you have to have a long-lived branch, then it should be broken up into smaller, mergeable milestones. Branches that don't merge back to trunk regularly are out of touch with the rest of development. Length of a branch increases technical debt of merging exponentially. xoox, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [RFC] merge stack_common.c and stacks.c
On Jun 29, 2008, at 1:23 PM, Andrew Whitworth wrote: After all the efforts to simplify Parrot's stack situation, it seems to me like src/stack_common.c and src/stacks.c can be merged. Are you saying you want to do it, or asking someone else to? I'd be glad to do that. C-level source, that I can handle. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [perl #44039] [CAGE] in compact_pool, we can be doing null dereferences
On Jun 9, 2008, at 7:13 PM, James Keenan via RT wrote: Andy: Is this still the case? I don't know. I haven't done anything in parrot for months. Sorry. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [perl #53990] [CAGE] [PATCH] warnings in compilers/imcc/optimizer.c
On May 12, 2008, at 3:11 AM, NotFound wrote: Maybe the solution is to avoid the problem, that is, put the declarations outside of the HEADERIZER block. What's the point of having static functions inside one? So that declaration and definition are always in sync. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn:parrot] r27435 - trunk/src/gc
On May 11, 2008, at 4:07 PM, chromatic wrote: Log: putting back the struct on Parrot_Context for headerizer I prefer that headerizer does the right thing, rather than cluttering up functional code. What goes kablooie in the headerizer here? Actually, it's not headerizer, but the header file. The typedef is not visible in a header file. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn:parrot] r27436 - in trunk: compilers/imcc include/parrot src/charset src/gc
On May 11, 2008, at 4:09 PM, chromatic wrote: headerizer should *not* delete preprocessor directives. What needs changing so that it doesn't mangle this code in the future? A massive reworking of how headerizer handles header files, because what you expected here is not at all how the headerizer works. The sections that the headerizer rewrites are not for human modification. Putting preprocessor directives between HEADERIZER BEGIN and HEADERIZER END is the same as modifying an auto-generated file. As the headerizer exists now, you have no expectations of having your changes continue to exist. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn:parrot] r27436 - in trunk: compilers/imcc include/parrot src/charset src/gc
On May 11, 2008, at 8:48 PM, chromatic wrote: I'm trying to decide which I hate more, headerizer, C, or #ifdefs in .c files. Ah, who am I kidding? It's the latter. If you add a note to headerizer to this effect (or tell me It's already there, you dope!) I'll fix the .c files so this won't happen again. If you hate the headerizer, then kill it, and take care of the problem yourself. You're welcome. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn:parrot] r27436 - in trunk: compilers/imcc include/parrot src/charset src/gc
On May 11, 2008, at 9:08 PM, chromatic wrote: Perhaps you missed the invisible sarcasm tags I forgot to include. I must have. headerizer makes the silly double-declaration problem of C more bearable. Thank you for writing it. You're welcome. I'm about to finish with a DO NOT TOUCH message. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn:parrot] r27436 - in trunk: compilers/imcc include/parrot src/charset src/gc
I accept that, and the note helps, but I just pulled the conditional declarations out of the block and ran make headerizer again. It put the headers for the conditional functions back in the headerizer block. Yeah, I understand. I don't have a solution yet. I'll ponder. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
GCC 4.4
I've just built the 5/2/2008 snapshot of GCC 4.4 and Parrot builds fine on it. I wonder what new warning flags 4.4 has that I can exploit. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: This week on parrot?
On May 5, 2008, at 8:52 AM, Will Coleda wrote: This presupposes that the summaries are a good thing: anyone have any feedback on this point? Just wondering who the audience would be. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: This week on parrot?
On May 5, 2008, at 10:23 AM, Eric Wilhelm wrote: Lurkers (potential contributors.) Posting it on use.perl.org (and/or various other feed sources) would reach more of us. But do those lurkers actually exist? My gut says no. My gut says that the people who would be interested in a summary are already on the list. I guess what I'd really like to see would be something aimed higher than the p5p summaries are. It'd be something that could be interesting to a wider range of readers, not just the people who care about the nitty gritty of PGE/PIR/whatever. This fabulous technology brings is this much closer to Rakudo being reality. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: This week on parrot?
On May 5, 2008, at 2:57 PM, Patrick R. Michaud wrote: FWIW, I suspect that Rakudo-related news (as opposed to Parrot news) belongs in my use.perl journal posts, and that I should be the one writing those summaries. I was doing that regularly back in Nov-Jan, but got sidetracked and haven't gotten back up to speed on them yet. I'll re-double my efforts there. And on rakudo.org. I see no problem with replication of posts between the two. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [perl #53066] consting vtable methods
On Apr 20, 2008, at 2:37 PM, Mark Glines wrote: Failure to do so results in an incompatible pointer warning, just like any other kind of prototype mismatch. And that in my mind is equivalent to can't. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [perl #53066] consting vtable methods
Just popping in to say that we cannot const any parms to vtable methods. Parrot can't impose promises on the called code. Take for example whatever the vtable method is to return the count of elements in the array. You'd think this would easily be constable, but we cannot at this point in time tell how someone in the future is going to implement it. Perhaps the counting of elements in the array will require fetching of elements into the array, because of lazy calculation. If there was a way we could have consted vtable arguments, rest assured I'd have found it. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: tutorial, blog, hackathon
On Apr 2, 2008, at 11:12 AM, Patrick R. Michaud wrote: IIRC, there's not really a conference hotel for IIT. The dorms. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [PATCH] Re: [perl #50684] String Failures with -O2 (GCC 4.1.3, 32-bit x86 Linux)
On Mar 12, 2008, at 2:33 PM, Andy Dougherty via RT wrote: +#ifdef HASATTRIBUTE_NONNULL_AND_I_REALLY_WANT_TO_USE_IT # define __attribute__nonnull__(a) __attribute__((__nonnull__(a))) #endif #ifdef HASATTRIBUTE_NORETURN and suddenly (for some value of suddenly that is more like an hour) 15 more tests pass. Hmm. Perhaps some of those nonnull's don't belong there. Alas, I don't have time to go in and hunt them all down. The attribute__nonnull tells the compiler that it doesn't have to check for null pointers being passed around. If things are being passed around as null that shouldn't be, then the compiler will choke on them because that null-checking is optimized away. Can you give details about which tests are failing? -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [PATCH] Re: [perl #50684] String Failures with -O2 (GCC 4.1.3, 32-bit x86 Linux)
On Mar 12, 2008, at 4:50 PM, Andy Dougherty via RT wrote: The problem is twofold: I'm not sure what you're saying is a problem. Are you saying that the use of __attribute__nonnull__ is a problem? Or just that we don't have it set correctly everywhere? When we DO get it fixed right, it will be an invaluable help. I understand that right now it breaks stuff, but I'm looking at long- term seat belts. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: tutorial, blog, hackathon
On Mar 12, 2008, at 6:43 PM, Allison Randal wrote: Also, we're planning a hackathon the weekend before YAPC::NA, June 14-15, for core hacking, language implementation, and cage cleaning. Excellent. Where? On the IIT campus? xao -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: PARROT_ASSERT considerations
On Mar 11, 2008, at 2:43 PM, Ron Blaschke wrote: It ties pointers to INTVALs, which I guess it shouldn't. As I read the mail, it seems like the only problem we have is in casting the pointer to an int to find its truthiness. I'd say use the !!(x) and be done with it. The PARROT_ASSERT_POINTER() idea gives me the willies because of checking for hardcoded magic values. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: PARROT_ASSERT considerations
On Mar 11, 2008, at 6:12 PM, Geoffrey Broadwell wrote: I'm confused here. My understanding of the difference between PARROT_ASSERT and the PARROT_ASSERT_POINTER suggestion is that the former checks for truth, and the other would check for lack of obvious insanity. A pointer of 0 is always, 100% of the time invalid. Always. A pointer of 0xdeadbeef has a non-zero chance of being valid and thus throwing a false positive. We don't get to control what malloc throws our way. Although, I guess, we DO get to if we force all our allocations to go through mem_sys_allocate(), which we are indeed doing. Usually. I guess we COULD just make mem_sys_allocate() re-malloc if it gets the magic 0xdeadbeef. Hmmm. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Fwd: GCC 4.3.0 Released
Everyone jump on board and get all the flags and warnings I've been enjoying for months now! Not that I remember exactly what they are. But there ARE some! xoxo, Andy Begin forwarded message: From: Jakub Jelinek [EMAIL PROTECTED] Date: March 10, 2008 5:21:34 AM CDT To: [EMAIL PROTECTED] Subject: GCC 4.3.0 Released Reply-To: Jakub Jelinek [EMAIL PROTECTED] GCC 4.3.0 has been released. GCC 4.3.0 is a major release, containing substantial new functionality not available in GCC 4.2.x or previous GCC releases. See: http://gcc.gnu.org/gcc-4.3/changes.html for more information about changes in GCC 4.3.0. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in gcc/gcc-4.3.0/ subdirectory. There is one important caveat. It was discovered after the final release has been made that some OS kernels on i?86 and x86_64 architectures violate the processor specific ABI with regards to the DF flag, if a process is interrupted with a signal while doing overlapping memmove or running some other code with DF flag set, the signal handler might be started with DF flag set on entry to the signal handler. GCC 4.3.0 no longer emits cld instructions unnecessarily, so GCC 4.3.0 compiled async signal handlers or functions the signal handlers call that rely on DF flag being cleared might misbehave. This will be hopefully fixed in the kernels soon and future GCC releases might provide an optional workaround for this bug. Fixes for some systems: Linux http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e40cd10ccff3d9fbffd57b93780bee4b7b9bff51 FreeBSD http://www.freebsd.org/cgi/query-pr.cgi?pr=121422 Hurdhttp://sources.redhat.com/ml/libc-alpha/2008-03/msg00020.html If you encounter difficulties using GCC 4.3, please do not contact me directly. Instead, please visit http://gcc.gnu.org for information about getting help. As always, a vast number of people contributed to this GCC releases -- far too many to thank individually! -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn:parrot] r26236 - trunk/compilers/imcc
On Mar 6, 2008, at 2:53 AM, chromatic wrote: Better as: current[len - 1] Whitespace is nice. Don't run ack '\w-1\]' or you might cry. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn:parrot] r26248 - trunk/src/pmc
On Mar 6, 2008, at 11:58 AM, chromatic wrote: Ugh. People can get over being sad, but unless there are resource release considerations, increasing the nesting depth of a function, widening the scope of stack variables, and obscuring the control flow with more if/else constructs seems like a net loss to me. Actually, it was to decrease the scope of stack variables. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn:parrot] r26248 - trunk/src/pmc
On Mar 6, 2008, at 1:09 PM, chromatic wrote: Actually, it was to decrease the scope of stack variables. Carry on then. (As long as it's not Functions should have one entry and one exit point, at which point I pull out the whiteboard and give my Does this LOOK like FORTRAN to you? lecture.) Well, they should have exit point, ideally. We should also have 100% code coverage, too. And I should be a much better dancer. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [perl #50920] [BUG]: t/compilers/imcc/syn/macro.t failing
Nope, no clue, we're still segfaulting, and valgrind finds it, but I don't know enough about internals to fix. uniqua:~/parrot $ valgrind ./parrot t/compilers/imcc/syn/macro_32.pir ==1234== Memcheck, a memory error detector. ==1234== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==1234== Using LibVEX rev 1804, a library for dynamic binary translation. ==1234== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==1234== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==1234== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==1234== For more details, rerun with: -v ==1234== ==1234== Invalid read of size 1 ==1234==at 0x4A06C82: strlen (mc_replace_strmem.c:242) ==1234==by 0x4F4F39D: read_macro (imcc.l:995) ==1234==by 0x4F4A7EB: yylex (imcc.l:424) ==1234==by 0x4F42521: yyparse (imcparser.c:2693) ==1234==by 0x4F520DC: compile_to_bytecode (main.c:954) ==1234==by 0x4F52480: imcc_run (main.c:1055) ==1234==by 0x400AE4: main (main.c:56) ==1234== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==1234== ==1234== Process terminating with default action of signal 11 (SIGSEGV) ==1234== Access not within mapped region at address 0x0 ==1234==at 0x4A06C82: strlen (mc_replace_strmem.c:242) ==1234==by 0x4F4F39D: read_macro (imcc.l:995) ==1234==by 0x4F4A7EB: yylex (imcc.l:424) ==1234==by 0x4F42521: yyparse (imcparser.c:2693) ==1234==by 0x4F520DC: compile_to_bytecode (main.c:954) ==1234==by 0x4F52480: imcc_run (main.c:1055) ==1234==by 0x400AE4: main (main.c:56) ==1234== ==1234== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 5 from 1) ==1234== malloc/free: in use at exit: 4,084,828 bytes in 3,962 blocks. ==1234== malloc/free: 4,094 allocs, 132 frees, 4,142,163 bytes allocated. ==1234== For counts of detected errors, rerun with: -v ==1234== searching for pointers to 3,962 not-freed blocks. ==1234== checked 4,852,040 bytes. ==1234== ==1234== LEAK SUMMARY: ==1234==definitely lost: 4 bytes in 2 blocks. ==1234== possibly lost: 0 bytes in 0 blocks. ==1234==still reachable: 4,084,824 bytes in 3,960 blocks. ==1234== suppressed: 0 bytes in 0 blocks. ==1234== Rerun with --leak-check=full to see details of leaked memory. Segmentation fault -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Eclipse
Anyone out there using Eclipse? I figure there might be value in its ability to handle large codebases all at once. Any pointers for startup and using the existing parrot project? xoxo, andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [perl #51146] [TODO][IMCC] Remove unused function mk_address
Although i can remove this function, I'm not really clear on how to update the header file symreg.h w.r.t the headerizer stuff. (can i just remove the prototype , or is this generated?) You run make headerizer and it updates the header. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [perl #50920] [BUG]: t/compilers/imcc/syn/macro.t failing on Darwin
On Feb 22, 2008, at 9:38 PM, chromatic wrote: Alas! It is once again failing as of r25999. Did it work at r25997? I think Andy keeps reverting the fix. What is the fix we're talking about? -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [perl #50920] [BUG]: t/compilers/imcc/syn/macro.t failing on Darwin
On Feb 22, 2008, at 10:18 PM, James Keenan via RT wrote: The test passed at 25900. and it passed at 25950. I'll have to pick up on this tomorrow. OK, I know what I did to break it. I'm going to see if I can get it to fail on OS X and then fix it the real way, rather than the way chromatic fixed it, which does fix it, but we both think there should be another fix that frees all the memory. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: r25810 - make error
On Feb 18, 2008, at 11:04 AM, James E Keenan wrote: I suspect a 'make realclean' should fix this. or make distclean, which is even more thorough than realclean. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [perl #50922] [BUG] t/src/intlist.t failing on Darwin
On Feb 16, 2008, at 10:29 PM, chromatic wrote: -chunk = list-first = chunk-next ? chunk-next : list-last; Urgh, I missed that list-first in the middle. My bad. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Shark under Leopard
Shark seems to have a lot of possibilities. $ shark -i -1 ./parrot --leak-test languages/perl6/perl6.pbc -e 'say Hello, world!' makes a little session file called session_001.mshark and then you open it with Shark.app and it makes bunches of different views you can play with. (You have to install xcode) The command-line tool creates text output too. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Hackathon at FP
I see that Allison's going to be at Frozen Perl. Will you be hackathonning? Anyone else going to be there besides me? I'm not sure I'll be sticking around for the hackathon, especially if I don't hear from anyone, so give me a reason to stay! xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
s/string_equal/string_compare/g
string_equal() is misnamed. It should be string_compare() like strcmp() and memcmp(). Objections? xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Functions that malloc()
There's now a make target to show all the functions that are PARROT_MALLOC: make malloclist xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn:parrot] r25630 - trunk/include/parrot
On Feb 10, 2008, at 4:00 PM, chromatic wrote: I'm all for this change, but it throws a lot of _MSC_VER is not defined errors in non-Windows platforms. I poked at the defines a little bit, but didn't see an immediately obvious way to make things right (my most recent attempt broke the OS PMC). Do we need a separate header for Windows? No, I'll take care of it. I like this kinda stuff. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: What goes in the API?
On Feb 6, 2008, at 5:04 AM, Francois PERRAD wrote: I agree with you, 'ld' is not a good name for a public function. It's bigger than that. We need to not be making visible a function to figure out log base 2. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
What goes in the API?
I had removed the PARROT_API from ld() in list.c because we don't need to offer as a public function to the user a function that computes logs base 2. fperrad reverted that because it broke make hello. It seems to me that this is backwards, just like my PARROT_APIing some other something last week that was needed only for making tests pass. Is there a way we can make functions visible for tests, and not make them visible via PARROT_API? I think we need to be very careful in what we publish as functions, especially something like ld() which seems highly likely to clash with another name somewhere. Do we have guidelines for knowing what should be PARROT_API and what shouldn't? xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Let's use snprintf()
Constructions like this give me the willies: char * const buf = (char *)mem_sys_allocate(16); sprintf(buf, %d, type); Yes, I know that 16 characters is more than enough, but I still don't like it. I'd prefer it if we were using instead snprintf(buf, 16, %d, type); I suspect there's a teeny performance hit since snprintf() has to check how far it's gone, but I can't imagine it's big enough to offset the safety. Thoughts? xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Let's use snprintf()
On Feb 5, 2008, at 1:17 PM, [EMAIL PROTECTED] wrote: (He sent this to me directly by mistake) snprintf is problematic on older Solaris systems, for one. At least through 2.7 (2.8?) it's not included in any lib. So other apps needed to test and bring in their own version. This is covered in the ticket that exists already, it turns out: http://rt.perl.org/rt3/Ticket/Display.html?id=39117 Short version: We'll need to make a snprintf() wrapper around sprintf() that ignores the length argument for the systems that don't support it. I'd rather ignore the length and pass on through to sprintf() than to have a parallel implementation. Ignoring the length parameter leaves those platforms without snprintf() exactly where they are today. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Why IMCC Leaks Memory and How You Can Help Fix It
On Feb 4, 2008, at 1:21 AM, Andy Lester wrote:
SymReg * r = _get_sym_typed(hsh, name, t);
if (r) {
free(name);
return r;
}
It's really saying If I don't need a copy, then free what I assume
is a copy, rather than If I need a copy, I'll make one.
I'm working on reversing this RIGHT NOW. It also lets me const more
stuff. :-)
I've committed code that right now leaks MORE than before, but the
interface makes more sense: The calling functions must free the memory
if necessary, and the mk_* functions now all str_dup() any args they
want copies of.
xoa
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Why IMCC Leaks Memory and How You Can Help Fix It
On Feb 4, 2008, at 12:44 AM, chromatic wrote:
SymReg * r = _get_sym_typed(hsh, name, t);
if (r) {
free(name);
return r;
}
It's really saying If I don't need a copy, then free what I assume is
a copy, rather than If I need a copy, I'll make one.
I'm working on reversing this RIGHT NOW. It also lets me const more
stuff. :-)
xoxo,
Andy
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Why IMCC Leaks Memory and How You Can Help Fix It
While we're at it, how about the horror of delete_ins() being told whether it should be freeing its argument? -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn:parrot] r25412 - trunk/src/ops
Any reason not to write: PMC *result = PMC_IS_NULL(lex_pad) ? NULL : VTABLE...; This assignment seems like a simple case, and you get a nice const opportunity for free. No reason in my book, but I got a general anti-ternary vibe in the past from the p2 crew. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn:parrot] r25410 - in trunk: include/parrot src
Do we really need to export 16,000 symbols? We ought to be *removing* PARROT_API, not adding it. The bulk of those are autogenerated in the PMCs, of course. What about unused functions? Look at, say, Parrot_char_digit_value() in src/string_primitives.c. It's PARROT_API for no apparent reason, so I went acking for it, and look, it's unused anywhere. Can we safely yank anything that's just not referred anywhere? xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
More pruning
I'm also suggesting that we prune old unused docs, starting with: =head1 HISTORY Initial version 2004.06.11 by Matt Fowles Not to pick on Matt (since much of these are by Leo), but I see zero value in this used-once boilerplate. Anyone mind if I get rid of it as I come across it? xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
API listing
I hacked the headerizer to do double duty as a lister of everything marked PARROT_API in the main C source files. It skips the PMCs. The make target is make apilist. It's crude, but ought to make it easy to skim for things that shouldn't be marked PARROT_API. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [svn:parrot] r25208 - trunk/src
On Jan 25, 2008, at 2:16 AM, chromatic wrote: Did you test this with make testC and make testj? I'm unaware of testC and testj. So no. I'm looking at the Makefile, and I guess I'm not understanding the differences between the various cores. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
My valgrinder
uniqua:~ $ cat ~/bin/vgr #!/bin/sh make perl6 valgrind \ --suppressions=/home/andy/parrot/tools/dev/parrot.supp \ --num-callers=500 \ --leak-check=full \ --leak-resolution=high \ --show-reachable=yes \ ./parrot --leak-test languages/perl6/perl6.pbc -e 'say Hello, world!' 21 | perl -p -e's/^==\d+==//' Dropping the leading process number leaves pure stack trace goodness, suitable for diffing between runs. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [perl #50010] [BUG]: make failure on Linux: conflicting types for 'Parrot_set_executable_name'
On Jan 19, 2008, at 10:59 PM, James Keenan via RT wrote: Occurs on Darwin as well: r25026. This should be OK now. I fixed the prototype. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Rakudo.org is up live
http://www.rakudo.org/ Right now it's just a blog, but we can add more more more. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Gearing up for Parrot release 0.5.2
On Jan 13, 2008, at 8:12 PM, Bob Rogers wrote: If there is any doubt, it would be better to wait, and let it mature a bit. We can always shout it from the rooftops at the next release. I disagree. It need not be perfect, and I'd like to keep this momentum going. Even if you have to do a chmod +x, or we have to modify the description a bit, it's still a big leap of usability. But I leave it in your hands, of course. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Gearing up for Parrot release 0.5.2
On Jan 12, 2008, at 4:22 PM, Bob Rogers wrote: - Implementation + New pbc_to_exe utility turns bytecode to executables Please put something in the top, shouting from the rooftops, that we can now say make perl6. That pbc_to_exe is interesting to core people, maybe, but make perl6 is exciting to a much larger audience. It is a huge step forward. Thanks, xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Gearing up for Parrot release 0.5.2
On Jan 12, 2008, at 10:07 PM, Bob Rogers wrote: How about leading with - make perl6 now builds a Perl6 executable as a section of its own? It's a start, but how about this: --- begin --- Parrot 0.5.2 brings a major new feature to users: The ability to build a perl6 executable. Parrot has been creating bytecode for years, but the conversion of these Parrot bytecode, or PBC, files is a relatively new function. Now, with the pbc_to_exe program, Parrot can compile high-level languages, such as Perl 6, into PBC and then create a standalone executable that doesn't need to be run through the Parrot runtime. Perl 6 is by no means complete, but the addition of a perl6 executable makes it easy for Parrot users to play with perl6, find out what Perl 6 is all about, and even join the project team. We'd love to have you join us. --- end --- I think this tells a better story than a list of bullet points. In fact, we ought to have some narrative atop every release of Parrot from here on out. I'll volunteer to do so if nobody else will when those releases come around. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: ubuntu-ppc-trunk BUILD FAILED
On Jan 12, 2008, at 10:12 PM, jesse wrote: What would it take to create a separate perl.org mailing list for buildbot status messages? Start by dropping a note to [EMAIL PROTECTED] If that doesn't get a response, ping me. There's no reason that the list needs to live at perl.org. It's trivial to set up a list via Google Groups, for example. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Gearing up for Parrot release 0.5.2
On Jan 12, 2008, at 10:26 PM, Bob Rogers wrote: One line is fine for NEWS, I think. Text is cheap. If people want to skip past it, they can. We need to be talking more about what we're doing. Consider the outside person who's only vaguely, if at all, familiar with Parrot. pbc_to_exe means nothing to them. Great; thanks. But is this the only thing we want to mention in such a narrative? Not at all. It's just the one that I see as most important and am most familiar with. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Gearing up for Parrot release 0.5.2
On Jan 12, 2008, at 11:33 PM, Bob Rogers wrote: One line is fine for NEWS, I think. Text is cheap. If people want to skip past it, they can. We need to be talking more about what we're doing. Consider the outside person who's only vaguely, if at all, familiar with Parrot. pbc_to_exe means nothing to them. So you're talking about what goes into the file NEWS. Sure, that can be terse. I just want to make sure that there's the narrative in the email announcements that are sent out and blog entries posted. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Thinking in marketing
On Jan 12, 2008, at 11:33 PM, Bob Rogers wrote: You are advocating better marketing, which is fine -- and I am lousy at producing marketing copy, so I appreciate the help. Also, it's really not that tough thinking about marketing. All I wrote up is enough to explain to an outside why the make perl6 target is useful, and how it works underneath. It's just a matter of stepping outside the project and thinking could someone else understand this? Maybe it doesn't have to be so simple that Aunt Gladys can get it, but maybe just the guy who sits in the next cube over who just knows a bit of Perl. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [PATCH] probe for gcc -Wxxx only when gcc (well, g++)
Unfortunately I haven't been able to test the patch, however, icc *should* handle -W flags exactly the same as gcc. And if it doesn't, then there is an issue there we (or Intel) should deal with. So, I would update the patch to ask if we have gcc or icc. I agree that -W doesn't apply to some other compilers, so it's a good idea to restrict the warnings checks to those compilers for which it is meaningful. I don't think that's the case. Yes, I believe there's a compatibility mode with GCC or something, but I try not to use it. I'd like to keep compiler warnings specific to the compiler being used, anyway. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Perl 6 new contributor day
With the new contributor day coming up, I'd like to run an article on Perlbuzz about it. Can anyone supply me some text? Or point me to a preferred old text that I can adapt? I'm looking at http://www.oreillynet.com/onlamp/blog/2007/08/parrot_new_contributor_day_thi.html which is from August, and doesn't discuss what we'll be focusing on. And, once we have that up, I'd like to put up a graphic ad/link on the front of Perlbuzz that points to it, like the Frozen Perl ad that's up there now. Anyone with mad graphix skillz wanna come up with something? Thanks, xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Build status wiki page
I've started a wiki page for problems with builds/tests that are known to be problems. http://www.perlfoundation.org/parrot/index.cgi?build_status This way we have a canonical place to look, rather than wondering Hmm, did this t/stm/*.t file pass before, or did I break it? There's also a section for past problems that have already been fixed, so we can see about things that were failures in the past, but have since been cleaned up, in case they break again. I'm hoping that if we all keep it up-to-date, we'll save a lot of needless worry and IRC chatter with problems that are known and being worked on. Thanks, xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Build status wiki page
Can you mention what platform tests were failing on? t/shootout isn't failing anymore on any platform I have access to. It's very slow, but not failing. No, I didn't mean that I would maintain it. I just started a place for people to keep notes on, just to get inertia going. Another really good way to deal with this is to always keep all tests passing in trunk. Clearly. However, since there's been so much lately where that hasn't been the case, I figured it made sense to make a central location for reporting and/or tracking what's failing, without having to resort to RT tickets. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: headerizer and src/atomic/gcc_x86.c
On Jan 4, 2008, at 8:09 AM, Allison Randal wrote: Andy, the headerizer dies with an error when src/atomic/gcc_x86.c has two functions that are marked with both PARROT_API and PARROT_INLINE. Am I correct in understanding that these two markings should never occur on the same function at the same time? Yes, that's correct. PARROT_API means it's something that we can link to in a lib, and PARROT_INLINE means that the compiler can inline it. Those two are mutually exclusive. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Keeping buzz going
http://use.perl.org/~pmichaud/journal/35272 http://perlbuzz.com/2008/01/flurry-of-perl-6-activity-picks-up-new-contributor.html Lots of cool stuff is going on, and I'm so so glad to see it. I'm thinking of making a Perl 6-specific column in Perlbuzz, because I'd like to have a one-stop shop for Perl 6 / Parrot news for those that want to follow, and I don't want to keep posting progress stuff in the main Perlbuzz column. If I created http://perlbuzz.com/perl6andparrotprojectupdates or something similar, do you think there'd be enough to fill the pipe? xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
uninitialized pointer in scheduler.c
Just reporting what GCC tells me, and I don't see that it's wrong. It
says that time_struct below is not initialized before use, and I sure
don't see that it isn't.
I'd investigate further, but I'm off to bed...
xoxo,
Andy
Parrot_cx_schedule_sleep(PARROT_INTERP, FLOATVAL time,
ARGIN_NULLOK(opcode_t *next))
{
#if PARROT_HAS_THREADS
# ifdef _WIN32
/* until we have a better implementation of threads on windows,
* we'll use the non-threaded form of sleep */
Parrot_cx_runloop_wake(interp, interp-scheduler);
Parrot_sleep((UINTVAL) ceil(time));
# else
Parrot_cond condition;
Parrot_mutex lock;
FLOATVAL timer_end = time + Parrot_floatval_time();
struct timespec *time_struct;
/* Tell the scheduler runloop to wake, this is a good time to
process
* pending tasks. */
Parrot_cx_runloop_wake(interp, interp-scheduler);
/* Tell this thread to sleep for the requested time. */
COND_INIT(condition);
MUTEX_INIT(lock);
LOCK(lock);
time_struct-tv_sec = (time_t) timer_end; Uniniitalized
time_struct-tv_nsec = (long)((timer_end - time_struct-
tv_sec)*1000.0f) *1000L*1000L;
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: uninitialized pointer in scheduler.c
On Jan 1, 2008, at 8:38 AM, Leopold Toetsch wrote: struct timespec *time_struct; This is a pointer to an unallocated structure, which was filled thereafter. Of course. I understand the C. It was the intent I couldn't get into. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: VTABLE_elements
What about when you want to implement things like, element -1 gets the last element of the array? That's the case in some languages, I believe... Yes, but we're talking about returning the number of elements in a PMC. That should never be negative. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
VTABLE_elements
Should we be allowing negative in the PMC elements() functions? Seems to me they'd be more appropriate as UINTVALs. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: VTABLE_elements
On Dec 28, 2007, at 12:17 PM, chromatic wrote: Should we be allowing negative in the PMC elements() functions? Seems to me they'd be more appropriate as UINTVALs. I can't think of any reason they could be negative. Can you make a patch to convert them and see if anything breaks? At this point, it's in a todo list in seatbelts.pod. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: writing mod_perl6 in perl 6
On Dec 21, 2007, at 10:50 AM, Jeff Horwitz wrote: This just went up in my blog, but I think it's interesting enough to post to the list as well. URL? I'll post it to Mechanix. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Consting args for vmethods
Andy: My consting has run into its greatest challenge yet. Andy: Making self args to PMCs consts where appropriate. Andy: jarring chord Andy: INTVAL such_and_such_elements( PMC *self ); Andy: Tell me that *self shouldn't be const. Andy: Go on, tell me. Andy: You can't. particle: of course i can't particle: in accessors, self should be constant Andy: I've already picked off the first low-hanging fruit: is_same()Andy: but that's only is_same ( PMC * self, ocnst PMC * other ) particle: joe pmc developer can make is_same do whatever he wantson his pmc. but on the base pmcs, we know what should be const Andy: anyway, I've already dirtied myself in the bowels of lib/Parrot/ Pmc2c/* Andy: well, thing is, if they're const for base, they're gonna be const for everyone. Andy: Could someone want lazy element calculation? Andy: That's my fear particle: yes particle: but they don't have to inherit particle: pmc2c is much prettier than it used to be, thanks to tewk+ +Andy: See, that blows the whole consting of element() then Andy: yeah, but it's all function pointers particle: okay, well we're changing to role-based pmc compositionparticle: so we can provide roles that have methods like is_samethat are const, and ones that aren'tparticle: think of a role as a bag of methodsAndy: but is the role of elements() always going to be const? particle: you build up your class structure (attributes) and mix in roles particle: the role could be called 'enumerable' particle: and would have methods like elements(), next() first() etc particle: it's a good idea to take this to the list. discussion will ensue, i promise. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Consting args for vmethods
On Dec 17, 2007, at 4:17 PM, Paul Johnson wrote: Which is where, in C++, you would be using the mutable keyword. I don't think this has yet made it into any C standard, but my knowledge in these areas is a little out of date. No, you can't. Alas. I'm going to have to give up on the CONSTed selfs. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Memory checking I've been working on lately
Now that I've got all but one function headerized, I'm running splint.
One of the things that splint is good at, and the reason I did all the
PARROT_CAN(NOT)_RETUN_NULL flags, is it'll keep track of when something
could be NULL or not. So splint complains here:
char * const p = malloc(n);
p-foo = ...
and not here
char * const p = mem_sys_allocate(n);
p-foo = ...
because mem_sys_allocate() is marked as PARROT_CANNOT_RETURN_NULL.
So I can do this in PackFile_new:
Index: src/packfile.c
===
--- src/packfile.c (revision 23681)
+++ src/packfile.c (working copy)
@@ -1119,24 +1119,14 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
-PARROT_CAN_RETURN_NULL
+PARROT_CANNOT_RETURN_NULL
PackFile *
PackFile_new(PARROT_INTERP, INTVAL is_mapped)
{
PackFile * const pf = mem_allocate_zeroed_typed(PackFile);
-if (!pf) {
-PIO_eprintf(NULL, PackFile_new: Unable to allocate!\n);
-return NULL;
-}
pf-is_mmap_ped = is_mapped;
-
pf-header = mem_allocate_zeroed_typed(PackFile_Header);
-if (!pf-header) {
-PIO_eprintf(NULL, PackFile_new: Unable to allocate header!
\n);
-PackFile_destroy(interp, pf);
-return NULL;
-}
/*
* fill header with system specific data
*/
Index: include/parrot/packfile.h
===
--- include/parrot/packfile.h (revision 23681)
+++ include/parrot/packfile.h (working copy)
@@ -453,7 +453,7 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
-PARROT_CAN_RETURN_NULL
+PARROT_CANNOT_RETURN_NULL
PackFile * PackFile_new(PARROT_INTERP, INTVAL is_mapped)
__attribute__nonnull__(1);
The other thing to come out of this instrumentation is when splint tells
us that we can be dereferencing NULL, as in here:
intlist_get(PARROT_INTERP, NOTNULL(IntList *list), INTVAL idx)
{
/* XXX list_get can return NULL RT #48367 */
void * const ret = list_get(interp, (List *)list, idx,
enum_type_INTVAL);
const INTVAL retval = ret == (void *)-1 ? 0 : *(INTVAL *)ret;
ret could be NULL, but we're not checking that, so it's possible to
de-refernece a NULL.
So that's what I'm workin' on, running splint, fixing headerizations,
etc. Let me know if anything shakes loose, or looks crazy, or causes
problems with your specific compiler. I'd especially like it if someone
non-GCC has compiler options that we can put into
PARROT_CANNOT_RETURN_NULL and its brethren so we have more compilers
watching our backs.
xoxo,
Andy
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
The headerizer and comment blocks
Tonight I've been working on getting the headerizer to automagically
update the comment blocks for each function in a .c file (.pmc files
will come later). The goal here is twofold:
1) The documentation is always consistent, because the declaration-
based documentation is computer-generated, and
2) The documentation is always up-to-date, because humans don't have
to remember to update the comment blocks.
Right now, it only updates src/tsq.c, a source file I picked at random
for experimentation and public discussion. I made it make comment
blocks look like this:
/*
=item CQUEUE_ENTRY * pop_entry
Does a synchronized removal of the head entry off the queue and
returns it.
=cut
*/
PARROT_CAN_RETURN_NULL
QUEUE_ENTRY *
pop_entry(ARGINOUT(QUEUE *queue))
{
... function body...
I figured that the two big things that mattered in an item heading are
the return type and the function name. What do you think? Do we need
a list of arg names in the =item as well? A copy of the full
declaration? We certainly don't want the full declaration in the
=item itself because it would be absurdly long what with all the
PARROT_ macros and whatnot. But I could see it looking like:
=item CQUEUE_ENTRY * pop_entry(queue)
Does anyone actually run something like perldoc src/filename.c to
look at the docs? I'm thinking that if nobody actually does that, we
could save the doc discussion until we're actually at a point where
we're generating docs. Right now, I think that what I've got as the
prototype above is 90% there, and gets rid of the tons of cut'n'paste
that are sprinkled throughout the C code.
Let me know your thoughts, so I can do more automation and run it on
the rest of the source files.
xoxo,
Andy
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [BUG] headerizer can't handle new file src/atomic/gcc_x86.c
On Dec 10, 2007, at 11:59 AM, Allison Randal wrote: Couldn't handle PARROT_INLINE void *parrot_i386_cmpxchg(void *volatile *ptr, void *expect, void *update) at tools/build/headerizer.pl line 169. Turn that into: PARROT_INLINE void * parrot_i386_cmpxchg(void *volatile *ptr, void *expect, void *update) -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [BUG] headerizer can't handle new file src/atomic/gcc_x86.c
I can't spare the brain bandwidth to dig into this further at the moment, so posting for others. BTW I have other headerizer stuff to update, like updating all the comments automagically so that the function declaration always matches the POD. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
What's up with compilers/imcc?
When last I was playing with Parrot, I recall noises that imcc was not useful, and was effectively dead. Is this right, or am I misremembering? Is it worth my time to const headerize it? If not, I'm pretty much done with headerizing. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [ANN] SF parrot win32
On Dec 5, 2007, at 9:38 AM, François Perrad wrote: I have no personal web site, so I create the project parrotwin32 on sourceforge : http://parrotwin32.sourceforge.net/ This project supplies only binaries for Windows (setup.exe form) of the monthly releases. I hope that help Parrot end-users (on Windows) and promote the use of Parrot. Beautiful. Thanks. http://perlbuzz.com/2007/12/parrotwin32-project-provides-prebuilt-windows-exec.html xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
please stop converting FUNCDOC headings to POD.
On Sep 18, 2007, at 9:04 AM, [EMAIL PROTECTED] wrote: -FUNCDOC: mark_special +=item Cmark_special This is a perfect example of why I want us to use FUNCDOC and not POD. Who says that we are presenting functions as =item lists? Why is it presented in C? =item Cmark_special applies two levels of presentation of documentation when we simply don't know how we want it presented. Paul, please hold off on changing any more FUNCDOC. The only value in having embedded POD in C source code is the ability to say pod2html foo.c foo.html, and that's just not much of a benefit when you consider the amount of boilerplate we'd be re-adding. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: please stop converting FUNCDOC headings to POD.
We decided to remove FUNCDOC in May soon after it appeared. At the time it only appeared in a couple of files, so I was surprised to it now scattered over a couple of dozen files. Who is we? I was entirely unaware of it. I've yanked POD on every file that I've headerized, which is all of them. Back to DRY again, the biggest objection to using Pod is creating an exact duplicate of the function signature in the Pod. More than anything, I want boilerplate gone. =item Cfoo is boilerplate. At the VERY least, remove the C. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Gone for a while
The FUNCDOC hoohah points out something that has been bugging me for a while and that now is actionable: I don't know WTF is going on any more. I'm very out of touch, even though I sometimes sort of try to keep an eye on what's going on. It's no way to be involved in a project. So, I'm backing out of Parrot development for right now. If anyone needs me, you know where to find me. For that matter, if there's anything specifically that I can help with, please let me know. I just can't keep an eye on what's going on any more. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Gone for a while
I'm sorry to hear that. You're welcome back any time. All contributions are valuable, and isn't necessary to follow every detail of every aspect of the project to contribute. Understood. It's just clear that I'm way out the loop on things, and I don't have the time to talk about the things that I've been wanting to talk about for a while anyway. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [perl #39088] [CAGE] Add conditional GCC attributes to functions
You've done a lot of work on this in parrot already and I haven't seen anything new as far as attributes go for a while. Have you finished adding gcc attributes? If so, we can close this ticket. On attributes, I think so. Warning flags will be a separate project. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: mod_perl6 update
http://perlbuzz.com/project-hum/2007/09/first-mod-perl6-handlers.html -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Statistical view of the history of Parrot
http://perlbuzz.com/2007/08/statistical-views-of-open-source-projects- on-ohloh.html -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [perl #38982] [CAGE] refactor long test files
On Aug 19, 2007, at 7:15 PM, David Romano wrote: The patch splits string.t (originally almost 3000 lines) into different files, as well as moves some of the tests for sprintf into t/op/sprintf_tests. Why is this a good thing, to be splitting up the files like this? I can see sprintf getting their own, but why is 3000 lines a bad thing? xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
