Re: [perl #44607] [CAGE] Hoist slurp_file() into Parrot::Util
On 14/08/07, Joshua Hoblitt <[EMAIL PROTECTED]> wrote: > Why not just pull Slurp or File::Slurp into the tree? Yes, writing a > slurp function is trivial but (bare with me here) if it's non-trivial > enough to be factored out into a module then it should be non-trivial > enough to not re-invent the wheel. Agreed. Why not just make it part of Bundle::Parrot? Paul
[perl #44621] Re: [CAGE] Finish this module: Parrot::YetToBeNamed!
# New Ticket Created by "Sandy Bultena"
# Please include the string: [perl #44621]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44621 >
OK, I'm game!
- Original Message -
From: "James E Keenan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 13, 2007 9:31 PM
Subject: [CAGE] Finish this module: Parrot::YetToBeNamed!
> This ticket is a cage-cleaning assignment that would be especially
> good for a newcomer to the Parrot project to take on. It entails the
> creation of a module written in Perl 5 to be placed under lib/Parrot/
> which would serve as a repository for Perl 5 subroutines which can be
> imported on demand by any Perl 5 packages anywhere in the Parrot
> distribution at any point in the compile-build-test-install cycle.
>
> More precisely, it involves the *completion* of such a module,
> because I've begun the module's specification below. Your task will
> be to complete the documentation, write tests of the interface, then
> write the code to implement the interface -- and then repeat the
> cycle until you get a high-quality Perl 5 package.
>
> The impetus for this module comes from an inline comment made by Andy
> Lester in r20618 of config/auto/attributes.pm:
>
> 20618 petdance # Stolen from Parrot::Test
> 20618 petdance # Should be put somewhere more central
> 20618 petdance sub _slurp_file {
> 20618 petdance my ($file_name) = @_;
> 20618 petdance
> 20618 petdance open( my $SLURP, '<', $file_name ) or die "open
> '$file_name': $!";
> 20618 petdance local $/ = undef;
> 20618 petdance my $file = <$SLURP> . '';
> 20618 petdance $file =~ s/\cM\cJ/\n/g;
> 20618 petdance close $SLURP;
> 20618 petdance
> 20618 petdance return $file;
> 20618 petdance }
>
> Code to slurp a file into a string can be found in many places,
> notably in the Perl Cookbook and in Uri's CPAN module File::Slurp.
> But File::Slurp is not part of the Perl 5 core distribution. That
> means it is not automatically available to Parrot developers. But
> it's certainly something that would be nice to have. I wondered why
> no one had made it available already.
>
> It turns out, someone *had* made it available already -- but *not*
> available throughout all parts of the Parrot installation cycle. A
> subroutine called slurp_file() is automatically exported by
> Parrot::Test and is used *very* extensively throughout the build and
> test phases (see attached file 'slurp_file.usages.txt' -- but note
> that some instances of the string 'slurp_file' pertain to PIR code).
>
> So I wondered: Why didn't Andy simply call Parrot::Test::slurp_file
> () in config/auto/attributes.pm? Why was he complaining that it
> wasn't "central" enough?
>
> The answer is that Parrot::Test has a dependency on Parrot::Config:
>
> use Parrot::Config;
>
> ... and Parrot::Config doesn't come into existence until after the
> configuration phase has completed! So Parrot::Test::slurp_file() can
> only be used in the build and later phases -- even though it itself
> has no dependency on Parrot::Config. It was not available when/where
> Andy needed it, because config/auto/attributes.pm is part of the
> configuration phase.
>
> In fact, slurp_file() doesn't have anything to do with testing per
> se. There is no intrinsic reason why it should be housed in
> Parrot::Test. (That's probably just where it first proved useful
> some 8000 commits ago.)
>
> It therefore makes sense to:
>
> 1. Extract slurp_file() from Parrot::Test.
> 2. Place it in a new package under lib/Parrot/ from which it is
> exported on demand (*not* automatically, as is currently the case;
> that's < best practice).
> 3. Make this a package that can hold other self-contained, non-
> object-oriented, utility subroutines written in Perl 5 that can be
> useful in all phases of the Parrot installation cycle.
> 4. Replace all current calls to Parrot::Test::slurp_file() with
> calls to Parrot::YetToBeNamed::slurp_file().
> 5. And, of course, to do it right: write unit tests for the
> subroutines exported by Parrot::YetToBeNamed.
>
> What do you need to accomplish these objectives? You don't need C,
> PIR or PASM. In fact, you don't need to know anything about Parrot
> at all! You only need competence in Perl 5. (Of course, it would
> help if you've drunk the koolaid Schwern first started brewing seven
> years ago. See any YAPC talk on module development or testing given
> by him, chromatic, Ian Langworth, Paul Johnson, Andy or myself in
> recent years.)
>
> In fact, this would be a great assignment for any/all of you who came
> to our Parrot BOF at YAPC, said you were interested in joining the
> project, but haven't yet started an assignment. Or a good assignment
> for those of you in Phalanx Phoenix!
>
> So don't be bashf
Re: [perl #44607] [CAGE] Hoist slurp_file() into Parrot::Util
Paul Cochrane wrote: On 14/08/07, Joshua Hoblitt <[EMAIL PROTECTED]> wrote: Why not just pull Slurp or File::Slurp into the tree? Yes, writing a slurp function is trivial but (bare with me here) if it's non-trivial enough to be factored out into a module then it should be non-trivial enough to not re-invent the wheel. Agreed. Why not just make it part of Bundle::Parrot? To be honest, this is the first that I've heard of Bundle::Parrot. I cannot locate any postings to the mailing list since last November containing 'Bundle' in its subject line. But the fact that I've been able to work on Parrot since last November *without* having installed Bundle::Parrot indicates that we make some distinction between that non-core Perl 5 functionality we want *in* the Parrot distribution and that which is found in Bundle::Parrot. Could you clarify how that distinction is made? kid51
Re: [perl #44607] [CAGE] Hoist slurp_file() into Parrot::Util
On 8/14/07, James E Keenan <[EMAIL PROTECTED]> wrote: > Paul Cochrane wrote: > > On 14/08/07, Joshua Hoblitt <[EMAIL PROTECTED]> wrote: > >> Why not just pull Slurp or File::Slurp into the tree? Yes, writing a > >> slurp function is trivial but (bare with me here) if it's non-trivial > >> enough to be factored out into a module then it should be non-trivial > >> enough to not re-invent the wheel. > > > > Agreed. Why not just make it part of Bundle::Parrot? > > > > To be honest, this is the first that I've heard of Bundle::Parrot. I > cannot locate any postings to the mailing list since last November > containing 'Bundle' in its subject line. > > But the fact that I've been able to work on Parrot since last November > *without* having installed Bundle::Parrot indicates that we make some > distinction between that non-core Perl 5 functionality we want *in* the > Parrot distribution and that which is found in Bundle::Parrot. > > Could you clarify how that distinction is made? > i started Bundle::Parrot to work towards the goal of removing all external modules from the parrot repository. external modules don't belong in the repository unless we need to fork them from their CPAN version. unfortunately, this work has not been completed. the idea is that anybody who wants to develop parrot can install Bundle::Parrot from CPAN, and then run through the config/build/test cycle without requiring any other modules. this requires that Bundle::Parrot contain all necessary modules for those tasks. however, it does not require that every nifty module that might in some way benefit parrot should be added to Bundle::Parrot--we're trying to keep this distro (and requirements for developing parrot) lightweight. work to be done involves assessing what modules are missing from Bundle::Parrot and adding them. also, testing config/build/test and other development tasks with only core perl and Bundle::Parrot--removing external modules contained in the parrot repository. documentation somewhere inside the parrot repository should mention Bundle::Parrot and how to get it once it's truly required. although i started the work, all of the parrot release managers share co-maintainership, so no one person should be a bottleneck if patches are submitted via parrotbug. ~jerry
Re: parrotbug: Can it handle attachments?
On 07/08/12 22:11 -0400, James E Keenan wrote: > docs/submissions.pod states: > "DO NOT paste the content of the new file or files into the body of the > message." > > I.e., send the content as an email attachment. > > But whenever I have used the 'parrotbug' utility, I have never seen a way > to send an attachment. I have always had to past the content of a patch > into the body of the email. > > Am I missing something, or are docs/submissions.pod and parrotbug at odds > with each other? when i wrote parrotbug, i heavily borrowed from perlbug. and it was sending everything in the email body - so i did the same. now, as i already stated, parrotbug is orphaned since i'm a bit short of time (yes, getting married takes a lot of time). so feel free to adopt it, and if the submission rules have changed, you can adapt parrotbug to the new rules! :-) jérôme -- [EMAIL PROTECTED]
Re: `warn_unused_result' warnings
On Mon, 13 Aug 2007, Andy Dougherty wrote: > On Sat, 11 Aug 2007, James E Keenan wrote: > > > Bob Rogers wrote: > > >Compiling r20605 last night gave me 69291 occurrences of a warning > > > about warn_unused_result: > > > > > > include/parrot/stacks.h:56: warning: `warn_unused_result' attribute > > > directive ignored > > > All tests pass, so this is purely at the annoyance level. I'm running > > > gcc 3.3.1; is it because that is too old? > > See http://rt.perl.org/rt3/Ticket/Display.html?id=44389. I'm suffering the > > same problem. > I'm not sure if it's relevant, but this attribute is available with > gcc-3.3, but not with g++-3.3. If you apply my patch at the end of RT > #44379, you can at least be sure that Configure.pl has used the correct > compiler and linker in the test. It probably won't solve the problem, > but may narrow it down some. Ok, I've looked at this further: gcc-3.3 accepts the attribute and exits with a 'success' exit status, but it then prints out the warning you see above. It would have been nice if gcc simply rejected the attribute so that testing the exit status of gcc would be sufficient. gcc-3.4 doesn't have this problem. The test could either be made to only work for gcc > 3.3, or it could try parsing the gcc-3.3 warning output (being careful to handle localization issues appropriately, and avoiding false positives for unrelated warnings). -- Andy Dougherty [EMAIL PROTECTED]
Re: `warn_unused_result' warnings
On Aug 14, 2007, at 6:27 PM, Andy Dougherty wrote: see above. It would have been nice if gcc simply rejected the attribute so that testing the exit status of gcc would be sufficient. gcc-3.4 doesn't have this problem. The test could either be made to only work for gcc > 3.3, or it could try parsing the gcc-3.3 warning output (being careful to handle localization issues appropriately, and avoiding false positives for unrelated warnings) The attribute sniffer looks at the compiler's output and says if it sees "warning" or "error", that the attribute must not work. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: [perl #44607] [CAGE] Hoist slurp_file() into Parrot::Util
On Tue, Aug 14, 2007 at 07:11:36AM -0700, jerry gay wrote: > i started Bundle::Parrot to work towards the goal of removing all > external modules from the parrot repository. external modules don't > belong in the repository unless we need to fork them from their CPAN > version. unfortunately, this work has not been completed. Particle++ > the idea is that anybody who wants to develop parrot can install > Bundle::Parrot from CPAN, and then run through the config/build/test > cycle without requiring any other modules. this requires that > Bundle::Parrot contain all necessary modules for those tasks. however, > it does not require that every nifty module that might in some way > benefit parrot should be added to Bundle::Parrot--we're trying to keep > this distro (and requirements for developing parrot) lightweight. ~/parrot $ grep -iR Parrot::Bundle docs (notta) I think we should just change the install docs now to say the installing Parrot::Bundle is a prereq to building Parrot and that the bundle will need to be reinstalled periodically (perhaps we could add a test to check for the right versions of modules to be installed). > work to be done involves assessing what modules are missing from > Bundle::Parrot and adding them. also, testing config/build/test and > other development tasks with only core perl and > Bundle::Parrot--removing external modules contained in the parrot > repository. documentation somewhere inside the parrot repository > should mention Bundle::Parrot and how to get it once it's truly > required. > > although i started the work, all of the parrot release managers share > co-maintainership, so no one person should be a bottleneck if patches > are submitted via parrotbug. A pointer to where the source code lives would be nice. ;) -J -- pgpX6d0y3U3gt.pgp Description: PGP signature
Re: [perl #44621] Re: [CAGE] Finish this module: Parrot::YetToBeNamed!
Sandy Bultena wrote: # New Ticket Created by "Sandy Bultena" # Please include the string: [perl #44621] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=44621 > OK, I'm game! Sandy: Check out: http://rt.perl.org/rt3/Ticket/Display.html?id=44607 ... if you haven't done so already. It appears the issue of how to deal with needed Perl 5 functionality is something we're still trying to resolve. particle, joshua, ptc: Let's see if we can figure out how to use this RT to integrate new people into the Parrot project. (/me will think about this some more, but now I have to apply some patches.) kid51
[perl #44563] [PATCH] lib/Parrot/Configure/Step.pm: Clarify comment
Patch applied to trunk in r20268 Aug 14 2007.
[perl #44561] [PATCH] lib/Parrot/Vtable.pm: Use qr operator rather than string eval
Patch applied to trunk in r20628 Aug 14 2007.
[perl #44565] [PATCH] lib/Parrot/Configure/Step/Base.pm: Make code more fully testable
Committed to trunk in r20629.
Re: [perl #44607] [CAGE] Hoist slurp_file() into Parrot::Util
On 8/14/07, Joshua Hoblitt <[EMAIL PROTECTED]> wrote: > On Tue, Aug 14, 2007 at 07:11:36AM -0700, jerry gay wrote: > > i started Bundle::Parrot to work towards the goal of removing all > > external modules from the parrot repository. external modules don't > > belong in the repository unless we need to fork them from their CPAN > > version. unfortunately, this work has not been completed. > > Particle++ > thanks. it's nothing, really, CPAN Bundles magically contain precisely zero lines of code. > > the idea is that anybody who wants to develop parrot can install > > Bundle::Parrot from CPAN, and then run through the config/build/test > > cycle without requiring any other modules. this requires that > > Bundle::Parrot contain all necessary modules for those tasks. however, > > it does not require that every nifty module that might in some way > > benefit parrot should be added to Bundle::Parrot--we're trying to keep > > this distro (and requirements for developing parrot) lightweight. > > ~/parrot $ grep -iR Parrot::Bundle docs > (notta) > yep, that's TBD. i'm pretty sure there's an RT ticket... but i can't find it. maybe it's been closed off. the ticket likely didn't specifically mention documentation anyway. > I think we should just change the install docs now to say the installing > Parrot::Bundle is a prereq to building Parrot and that the bundle will > need to be reinstalled periodically (perhaps we could add a test to check > for the right versions of modules to be installed). > > > work to be done involves assessing what modules are missing from > > Bundle::Parrot and adding them. also, testing config/build/test and > > other development tasks with only core perl and > > Bundle::Parrot--removing external modules contained in the parrot > > repository. documentation somewhere inside the parrot repository > > should mention Bundle::Parrot and how to get it once it's truly > > required. > > > > although i started the work, all of the parrot release managers share > > co-maintainership, so no one person should be a bottleneck if patches > > are submitted via parrotbug. > > A pointer to where the source code lives would be nice. ;) > the cpan tarball is the entire source. however, if you prefer svn access, you can get it at googlecode: http://bundle-parrot.googlecode.com/svn/trunk/ thanks for helping me fill in the bits i missed earlier. ~jerry
