Re: Template oriented module
On Mon, Jun 16, 2008 at 6:44 AM, Ivan Wills [EMAIL PROTECTED] wrote: Hi, I have been working on converting a script that I have been using for my self for a while which I use as a templating engine in vim and for creating whole new files (and soon creating whole directory trees from templates). It uses template toolkit for the actual templates. I have several questions about this before I try to put the module on CPAN first what should I call this (my current script is called itemplate but that doesn't seem to fit with CPAN naming conventions). The next question is should I include the templates I use with the module? I have templates that generate perl scripts and packages that follow PBP as well as XHML skelitons etc. If I include these template files, how do I make Module::Build install them and how do I determine where the templates have been installed so that I can create the Template toolkit path correctly? Finally I have been thinking of creating a module to handle svn (or cvs, net etc) like commandline parameters (ie cmd subcmd -parms ...) which I will use with this module (and also sick on CPAN). It will use Getopt::Long for most of its functionality but will be able to do work of finding what parameters each sub command accepts. So again what would be a good name I imagine Getopt::something (SubCommand?) Any suggestions would be helpful Thanks Ivan Wills -- email/jabber: [EMAIL PROTECTED] / / _ _ / \ / | | | | / \/ \_| | | I'm now thinking of calling the module Template::CMD or possibly Template::CLI depending on weather I use App::CMD or App::CLI does this make sense? -- email/jabber: [EMAIL PROTECTED] / / _ _ / \ / | | | | /\/ \_| | |
Re: Must exist, right?
On 19 Jun 2008, at 03:18, Chris Dolan wrote: Implemented! See the attached .pm file and the test.pl file that verifies the four snipped use cases. It could certainly be made more readable, but my interest is waning quickly. :-) I hereby grant anyone permission to use/extend this crappy code under the same license terms as Perl itself. Heh. I can see this going all FizzBuzz :) -- Andy Armstrong, Hexten
RE: Must exist, right?
I think Moose is overkill for this type of thing but Andy++ for this thread, I've been looking for something like this for a while too :) -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2008 3:23 AM To: Eric Wilhelm Cc: module-authors@perl.org Subject: Re: Must exist, right? On 19 Jun 2008, at 01:14, Eric Wilhelm wrote: You want something like Object::Accessor, but without needing to actually create the object? Yup. I want a read-only object with dynamically generated per object methods that reflect the internal data structure. Assuming you could be bothered to call new() for the sub-object (passing it to the contructor, etc), just about anything including Moose would work ;-) I'll let the more Moose-enabled folks comment on how a 'default' sub (or some other setup) would do exactly what you want. I really /must/ look at Moose properly soon :) -- Andy Armstrong, Hexten
Re: Must exist, right?
* Eric Wilhelm [EMAIL PROTECTED] [2008-06-19 10:15]: But even with C::A::Classy, I've had troubles with perception. I just got a project (which I originally architected) set in front of me for the second time after the client's in-house guy decided that he didn't understand C::A::Classy and opted to tear it out and replace it with a beta in-house thing that doesn't really even try to have most of the features of an object system - thereby loosing the read-only distinctions, private mutators, immutable properties on some attributes, etc - and switching all of the calling conventions to require sprinkling extra curlies. The net difference in the code comes from a lot of little details, but I could point to completely redundant classes which exist solely because the lack of object system led to their creation. I think that might be overkill. This is the same reason people write their own crappy templating systems. “I just need to do this one little thing and that whole template engine looks so intimidating, I’ll just write a few lines of code to do this myself.” Of course they end up expending extra effort to deal with the absence of various conveniences of a full-featured system, and the five-line solution inevitably grows until it has 1/3rd the features of a full-featured system except that the in-house solution is an organically grown mudball rather than a coherently designed whole. It’s OK, mind, to write your own templating system. Or meta object library. Or web framework. Or whatever. Just be sure you want to. Especially if your goal is to put it into production, you need be aware of the scope of the problem ahead of time; if you resolve to do a thorough job and understand what you are committing to, go ahead. OTOH if you want to experiment and you don’t have any plans to inflict your creation on production code then that’s great too: learning by doing provides the deepest understanding. But “$system/$library/$framework intimidates me” is not a valid reason to do a zero-effort hack. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Incorrect guessing the part of CPANTS
I looked around at the CPANTS assessment of ack. It's got some big errors. * It thinks that the Util I ship in t/ for the help of tests is a Util in another distro. See http://cpants.perl.org/dist/prereq/ack * CPANTS thinks that Win32::File is a prerequisite, when it very specifically is not. The require for Win32::File is in an eval, so it is fine if it doesn't exist. See http://cpants.perl.org/dist/kwalitee/ack * The overview complains about lack of examples and POD coverage. http://cpants.perl.org/dist/kwalitee/ack However, neither examples nor POD coverage tests are appropriate because ack is a single program, with no user serviceable parts inside. * And, a suggestion: Add links to the project home page and the project's actual bug tracker on http://cpants.perl.org/dist/external/ack xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Andy differentiation
Armstrong: Hexten, London. Lester: Petdance, Chicago.
Re: Andy differentiation
--- David Nicol [EMAIL PROTECTED] wrote: Armstrong: Hexten, London. Actually, Cumbria, just south of Scotland. Not London :) Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: Debian patch
On Fri, Jun 20, 2008 at 5:13 AM, Ivan Wills [EMAIL PROTECTED] wrote: Hi, I noticed that my module SVG::Calendar has failed the kwalitee test has_no_patch_in_debian but does not tell me where to actually find that patch can any one tell me where to look? Also if the test knows that there is a patch (or patches) in Debian should it not report where they are to be found by default? It should but actually in this case there is another issue. This module also fails the distributed_by_debian that is, it is not distributed by Debian. So the other 3 new debian related metrics are actually irrelevant. We either have to turn them to green or maybe not display them at all. regards Gabor -- Gabor Szabo http://szabgab.com/blog.html Perl Training in Israel http://www.pti.co.il/ Test Automation Tips http://szabgab.com/test_automation_tips.html
