Re: Misleading error message - lack of zlib reported as no libxml2 (compiling XML::LibXML)
* On Fri, Jan 28 2011, Zbigniew Lukasiak wrote: I am not sure where I should report that - it looks like a quite generic bug. I think this is an XML::LibXML bug. If -lxml2 needs -lz, then the Debian package should have figured that out. That leads me to believe that it doesn't actually need zlib, and this is a cargo-cult bug. But I haven't tested this yet. (I will soon.) Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: XML::Reader
* On Tue, May 11 2010, Klaus wrote:
However, unlike XML::Twig, XML::Reader does not rely on callback
functions to parse the XML. With XML::Reader you loop over the
XML-document yourself and the resulting XML-elements (and/or
XML-subtrees) are represented in text format. This style of processing
XML is similar to the classic pattern:
open my $fh, '', 'file.txt'; while ($fh) { do_sth($_); } close $fh;
FWIW, it's very easy to make callback-based code look like an iterator.
Here's an example script.
use strict;
use warnings;
use feature ':5.10';
use Coro;
use Coro::Handle;
use Coro::Channel;
Imagine you have a routine that calls a callback for each event, like
receiving a line from a filehandle:
sub call_on_line(){
my $cb = shift;
async {
my $fh = unblock \*STDIN;
while(my $line = $fh-readline){
chomp $line;
$cb-($line);
}
};
}
(Ignore the implementation here, it's just an example.)
You can loop over the results of the callback, like this:
my $chan = Coro::Channel-new;
call_on_line { $chan-put(@_) };
async {
while(my $item = $chan-get) {
say GOT ITEM: $item;
}
}-join;
So I'm not sure there's a point in writing a module just to be
loop-driven instead of callback-driven; it's easy to convert
callback-based code to blocking code.
When in doubt, if you are trying to write something reusable, make it
callback-driven instead of blocking. Then the consumer can easily
choose how to use it.
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
Re: Module uploaded - whats next?
* On Fri, Dec 11 2009, Rene Schickbauer wrote: Hi! I think a discussion about the why's could be interesting and insightful - unfortunately I have to agree that the posts above are mostly about influencing and not much about truth seeking. Is that ever possible? I don't think so. Everyone thinks and works a little different. So, a feature in a software could be THE feature for one but the killer bug for someone else. This is similar to Whats the best editor? or Whats the best operating system?... Countless flamewars have been fought (and lost) over questions like that. In my experience, ask anyone why they use their favorite editor, and the answer is usually because I learned this one first or because I wrote this one. Nobody has ever answered because I made a chart of editors versus features I desired, tested each one, and the one I chose had the most checkboxes. Just sayin'; like favorite colors, favorite editors and favorite pieces of Perl code are mostly irrational emotional decisions. (My answer, FWIW, is because I learned this one first, but I steal features from the other editors whenever possible. The ease of which this is possible leads me to believe that I made the right choice, but I am just as irrational as anyone else.) Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Module uploaded - whats next?
* On Thu, Dec 10 2009, David Cantrell wrote: On Mon, Dec 07, 2009 at 09:56:58PM -0600, Jonathan Rockway wrote: I remember a few years ago, as a newbie with only CGI.pm and mod_perl experience, discovering the Catalyst website. I thought I liked what I saw, and decided to play with it for a bit. My toy blog project (a very early version of Angerwhale, incidentally) was converted from a mod_perl handler in a weekend, and my $WORK_APP was converted from straight CGI.pm in a few days. Now I didn't need Apache anymore, and my code was no longer a complete mess. If your code was a complete mess, that's not CGI.pm's fault, it's your fault. And it becoming less of a mess wasn't Catalyst's fault, it was - again - your fault, by dint of being more experienced when you re-wrote it. This is partially true. But my messy session-handling, model-instantiating, and request-dispatching code was completely eliminated because I used The Framework instead of my own implementation. The less code I write, the less chance I have to fuck it up. Catalyst allowed me to write less code. (The parts I wrote, of course, were still a mess. I will be the first to admit that I have no idea how to program computers. But then again, I have never heard of anyone else that knows how to either.) [numerous errors and fallacies snipped because they're boring] Hmm, I didn't seem to receive the patches you sent. Could you please resend them? I'll bother to write them once I'm assured that you send patches for all the open source software that you don't like or think is badly implemented or don't do the job very well. After all, I'm sure you're not the sort of person who would hold me to a higher standard than he holds himself. I try to do this whenever possible. Can you link me to some instances of public complaining where I didn't fix the software? (My usual complaint is inability to fix the software, due to hardware restrictions or non-availability of source code. I complain about those a lot, but since that is all I am allowed to do, I don't feel bad about it.) I have written / contributed to a few pieces of software, BTW: http://github.com/jrockway But anyway, I have found it easier, in general, to patch a non-perfect piece of software than to write Perfect Software from scratch. In a world without infinite time, sometimes you just have to deal with ugly and make incremental steps towards beauty. Catalyst is no exception. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Module uploaded - whats next?
* On Fri, Dec 11 2009, Rene Schickbauer wrote: OBut i have one critic to add anyway: There is ONE argument in this discussion that is just stupid: There are X books on the subject so this way is better. A books only search for Microsoft Frontpage on Amazon.com turned up 3088 results - surely you wont suggest i prefer Frontpage over Catalyst/Maplat/CGI.pm? Hmm, I think you missed the point I was trying to make. Let's imagine a hypothetical situation. You want to write a web app. You don't know how. Would you pick a framework with no documentation and no users, or would you pick one with extensive documentation and many users? Most people would pick the second, right? You don't want to learn to write web applications AND dissecting some random source code on the Internet AND fix the bugs in that code, right? This process is inevitable with any software, of course; but the more users a software package has, the less likely *you* are to run into a critical show-stopper bug immediately. And, if you have a few books to help you, you can spend your time on your application instead of making all the beginner mistakes. (I did this recently. I wanted to write an Android app. I didn't want to use plain Java. The decision came down to Clojure and Scala. I like Clojure better than Scala. But I Googled for each in the context of Android, and Scala turned up results that allowed me to immediately get started. I couldn't get Clojure working. Once I got a Hello World app working, I just bought a Scala book and started working out of that. I learned Scala pretty quickly, which left me with plenty of time to work on the Android part. If there were no Google results and no books, I would have just given up, because I am lazy. Clojure may be a better language than Scala... but since I couldn't get started, I may never know.) In the Perl community, Catalyst is the web framework that's the closest to the second scenario. You can go from zero to something pretty quickly. There are books that guide you through the process, and people are around all day (and night) in various forums (and forms?) to help you with your questions. To some people, this is better than Pure Technical Correctness. If you are one of those people, Catalyst is a pretty rational choice for starting a web application in Perl. Hopefully I made this point clear this time. Number of books has nothing to do with the suitability of a technology for a particular purpose. But if you are trying to learn some technology, having a book or two can greatly accelerate the process. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Module uploaded - whats next?
* On Fri, Dec 04 2009, David Cantrell wrote: On Fri, Dec 04, 2009 at 10:21:35AM -0600, Dave Rolsky wrote: On Fri, 4 Dec 2009, Rene Schickbauer wrote: On the other hand, i knew my way around HTML, the Template engine and HTTP::Server::Simple(::CGI). Got the project uprunning in two weeks straight (90% of the code was a fixed up perl port of one old C++ business logic code). The idea that you couldn't learn the basics of Catalyst and get things running in the same time seems unlikely. There's a very big difference between learning the basics of Catalyst and learning enough to do any real work. I've been working as one of several programmers for the last six months on a large product that uses Catalyst. I still have to ask people for help whenever I hit Catalyst. I remember a few years ago, as a newbie with only CGI.pm and mod_perl experience, discovering the Catalyst website. I thought I liked what I saw, and decided to play with it for a bit. My toy blog project (a very early version of Angerwhale, incidentally) was converted from a mod_perl handler in a weekend, and my $WORK_APP was converted from straight CGI.pm in a few days. Now I didn't need Apache anymore, and my code was no longer a complete mess. (It was still very much a mess, of course, but improvement is always good.) This, coming from 0 experience with MVC and OO Perl, and nothing but the website for guidance. Today, there are two full-length books, 480 CPAN distributions, several tutorials, a full manual, and four years worth of blog posts and conference talks. If this isn't enough, you can pay many people to come to your office and teach you Catalyst; or, you can pay them to just start your app for you. If I could learn Catalyst from nothing but a basic overview of the framework and a tiny sample app, I would find it hard to believe anyone that is capable enough to write their own web framework would be unable to learn Catalyst fairly quickly today. It's one of the most well-travelled paths in the Perl Universe, and there are plenty of people that can help you if you have a problem. (See my philosophical talk on this: http://jrock.us/why-i-stick-with-perl.esl) (If you can write an entire web framework faster than you can get started with Catalyst, that is amazing. It has taken me more than 2 years of work just to get an idea of what a successor to Catalyst would look like, and I still haven't accounted for all the reuse patterns that Catalyst *already* provides. If you can design and implement something better... AND your application, in two weeks, that is incredible and unprecedented!) Finally... I have taught a few multi-day Catalyst classes. I have found that people tend to get Catalyst very quickly, even coming from non-web or non-OO-Perl backgrounds. I would like to say that's because I'm an awesome teacher, but my teaching style is probably an *impediment* to learning anything. Catalyst is just not that hard to learn. And I keep finding things in Catalyst that look just plain stupid and wrong. Hmm, I didn't seem to receive the patches you sent. Could you please resend them? (Shockingly, the goal of the Catalyst project is to keep all existing apps working, while removing the stupid and wrong parts of the framework. This is quite difficult, but Catalyst does fairly well here. It's not much different from Perl5 itself, actually...) Anyway, the community solution may not always be perfect... but it is a good stand in until you have the 10 spare years to rewrite it correctly. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Module uploaded - whats next?
* On Mon, Dec 07 2009, Jonathan Swartz wrote: On Dec 3, 2009, at 1:42 AM, Jonathan Rockway wrote: Catalyst is the standard Perl web framework [1], and is neither non- perl nor has very strict security. It also runs on Windows (Strawberry or ActiveState), and does not require Apache. (Apache still exists!?) [2] Ah, the arrogance that oozes forth from a few of the most vocal advocates and authors of Catalyst. That for me is one of the main reasons I avoid it and vaguely wish for it not to succeed. (Which is too bad, because I'm sure most of the folks responsible are quite nice.) Wow, how rational! It may surprise you to know that your reasons for avoiding Catalyst are pretty flaky; fewer than 1% of the lines of code in the Catalyst core were written by me. (Actually, svn blame shows less than this even though I broke the repository a few years ago and every change became owned by me. I am basically completely irrelevant at this point! Damn those facts!) Basically, I am just a happy user that talks about Catalyst at conferences because people keep asking me to. I have no particular investment in it, other than thinking that it *is* the best solution for developing web applications in Perl. (That doesn't mean it's good, it just means that's it the best.) I write my apps, and Catalyst stays out of my way until I ask it to do something I don't feel like doing myself. Catalyst is a lot like Perl5 itself. It may not be the best-designed language ever, but when you want to do something, you can do it. Someone else has been there and the results are on CPAN. When you are new to something, this is what you value over technical purity. Catalyst is the Perl of Perl web frameworks, and that's why I use it and recommend it. (BTW, I chose the word standard because I thought that was generally-believed to be true. If someone was to complete the following set: Ruby: Rails Python: Django Perl: ??? would ??? really be Web::Simple? Nope, sorry. That doesn't mean that Merb and Pylons and Jifty are not great frameworks, it just means that they are not the standard. Don't read into it so deeply.) Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Module uploaded - whats next?
* On Fri, Dec 04 2009, Bill Ward wrote: Yep, that's why I didn't use Catalyst and would never suggest it to anyone... it's an IT nightmare. Seriously? My Catalyst app works as soon as I type # apt-get install libcatalyst-perl on my Debian Stable system. It isn't quite Java + WAR, but it is also no IT nightmare. Please get the facts straight before spreading FUD. Your argument would be more persuasive if it was true. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Module uploaded - whats next?
* On Mon, Nov 23 2009, Rene Schickbauer wrote: Yeah, i looked at many web frameworks, they are either non-perl or have very strict security. Strict security is nice to have, but for in-house intranet projects it sort of gets in the way if you have to quick-hack a solution very fast... so i invented my own framework. Just so you know... Catalyst is the standard Perl web framework, and is neither non-perl nor has very strict security. It also runs on Windows (Strawberry or ActiveState), and does not require Apache. (Apache still exists!?) It even has two books written about it. http://www.catalystframework.org/ -- print just = another = perl = hacker = if $,=$
Re: flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
* On Wed, Nov 18 2009, Aristotle Pagaltzis wrote: * David Golden xda...@gmail.com [2009-11-18 16:05]: So creating/destroying Perl objects -- even just for things like argument passing on the stack -- is part of the cost of the flexibility of Perl. When that becomes a bottleneck in a tight loop, that's when XS becomes a potential option. That's not a knock on Perl -- that's just part of the design. It isn’t inherent in the language design. A tracing JIT runtime *could* make Perl go faster than compiled code. So untrue. Python has this problem, but people wrote new implementations anyway. Psycho, PyPy, and Unladen Swallow may not run every program ever written, but the programs they do run run much faster. If someone were to write a new VM, legacy code could run on the old VM, and new code can be tested and tweaked to run on the new VM. If you don't want to use the new VM, then don't. Get that 1000x speedup some other day... The real reason for the lack of another Perl VM is that Perl programmers are very, very lazy. ;) -- print just = another = perl = hacker = if $,=$
Re: naming advice required
* On Fri, Nov 06 2009, Ryan Voots wrote: On Friday 06 November 2009 14:09:47 brian d foy wrote: Is this something that would be useful outside of GitHub? Are you screen scraping or doing something special with git? I think a name might be Github::Fork::Parent, if this is only for Github. Maybe even WWW::Github::Fork::Parent or something on there since its interacting with a website? Why not just Github::? -- print just = another = perl = hacker = if $,=$
Re: How can I tell MakeMaker to insert recommended modules into META.yml?
* On Fri, Oct 16 2009, O. STeffen BEYer wrote: Any hints on all that? Wow, a lot of people CC'd on that message. That is probably Considered Annoying to the people you sent it directly to. Anyway, optional requirements probably aren't the *worst idea ever conceived*, but they are close. When your module depends on optional modules, my module can't just say, requires Foo::Bar, it has to say requires Foo::Bar and whatever modules one would need to make your optional features work. This may change from version to version, making it impossible to ship a reliable module that depends on yours. It is also a problem when communicating with others; when I ask someone to try Foo::Bar, I now need to tell them exactly which combination of optional modules to install also. If I can remember. Finally, detecting which features to enable at runtime can be flaky. Imagine you have a module that enables an optional feature when Foo::Quux is installed. I don't want that feature when I install the module, so I skip installing the prereq. For a while, your module works fine. Some time in the future, I install Foo::Quux to satisfy the dependencies for Gorchify::It, and suddenly, your module stops working due to auto-detecting Foo::Quux, enabling an optional feature, and then not working the same way anymore. Very bad. Modules should not work differently based on whether or not other random modules happen to be in @INC. The solution is to make each optional feature a separate distribution; then it's easy to depend on the optional feature, easy to remove if you don't want it, and easy to communicate to others. Also, I can tell you one thing that nobody wants to do while installing CPAN modules, and that's answer questions. I want to say cpan Foo and go away and not monitor the terminal it's running in to see if it's asking me questions like Do you want to install the module that you requested to install? [y]. No... I don't want to install the module I just invoked cpan -i on... thanks for asking... To summarize: Optional requirements considered harmful. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: How can I tell MakeMaker to insert recommended modules into META.yml?
* On Sat, Oct 17 2009, O. STeffen BEYer wrote: In the meantime I found out when this META_MERGE tag works and when not: When I run a tool from the terminal which calls make dist, everything works fine. When I run the same tool from within a cron-job, with stdout and stderr redirected (to a file and /dev/null, respectively), the extra tags in META.yml disappear! Looks like a bug to me... Best regards, Steffen (P.S.: Why do I run the tool from within a cron-job, you may wonder? Because when doing a make dist, I touch all files and directories first. It turns out that the size of the dist file varies quite a bit depending on this time stamp on all files and dirs! So I re-run the make dist every minute and keep the new dist file if it is smaller. That costs me (or better, Ralf :-) ) a bit of CPU time, but when several thousand people download the file, this saves some bandwidth!) LOL. -- print just = another = perl = hacker = if $,=$
Re: Access to bug queue
* On Wed, Aug 19 2009, sawyer x wrote: What was the HOOO incident, if I may ask? Among other things, this: http://www.mail-archive.com/cpan-test...@perl.org/msg448605.html Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Optional Features and down-stream modules
* On Mon, Aug 17 2009, Zbigniew Lukasiak wrote: Optional features are not well suited for automated install. They impose questions on the install - but what is more important they generate problems when for down-stream modules that rely on the optional features. There is no easy way to specify this - and also if those optional features depend on installation of some optional prerequisites - then the down-stream module have no way to determine which ones of the optional prereqs are needed for the feature it depends on (and if that optional feature relies on another optional feature in one of the prerequisites - then the situation is completely non-transparent for the down-stream module author). I agree completely, this has been bugging me for a while. Personally, I never do optional features anymore. I just make the extra features mandatory. If they can install my module, they can probably install anything it depends on. If not, they can send me a patch to split out the optional feature into a new distribution. But this has never been necessary. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: module/script to clean up old files and prune empty directories
* On Thu, Jul 02 2009, Dana Hudes wrote: Sent from my BlackBerry® smartphone with Nextel Direct Connect You know, there is a header for this sort of thing. -- print just = another = perl = hacker = if $,=$
Re: lexical warnings question
* On Tue, Jun 16 2009, Bill Ward wrote:
I'm more interested (at $JOB) in global warnings, actually. Of course
one can enable those with $^W or perl -w and I do, but developers
ignore the warnings all too often. Many of our core modules were
written without warnings enabled, and people are slow to fix those
warnings. So, we want to make warnings fatal in the development
environment to force developers to fix those niggling uninitialized
value warnings that are all over the place in our log files.
Honestly, I think this is worth bringing up on p5p. I think it should
be possible to convince perl to give user code control over the hints
hash as each scope is compiled.
I tried the obvious technique of:
package forcewarn;
use strict;
use B::Hooks::OP::Check::StashChange;
our $id = B::Hooks::OP::Check::StashChange::register(sub {
my ($new, $old) = @_;
warn compiling $new;
warnings-import( FATAL = 'all' );
});
1;
And then use forcewarn before any of my code compiled, but the
warnings-import only seems to affect the calling scope, not the scope
currently being compiled.
I have a feeling that with some tweaking this will work, though, and
would be interested to see if anyone has some insight here.
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
Re: Help needed testing security of login module
* On Wed, May 20 2009, Arthur Corliss wrote: On Wed, 20 May 2009, Jonathan Yu wrote: Not totally pointless, of course, because it would still require regenerating a rainbow table versus downloading one of them already available. On the other hand, depending how popular your application gets, this can be dangerous -- take for example Microsoft's Lan Manager Hash algorithm, LMHash. Even though it is a specialized algorithm, it became popular enough to make it feasible/useful to create and distribute rainbow tables for. So your point is valid in that case, and it never hurts security nor is it a big deal on performance. I would suggest that the benefit of a static salt is marginal in best since many of these hash algorithms aren't exactly computationally intensive on today's hardware. Yes, this is why you should use Bcrypt or something else designed for hashing passwords. You should be using Authen::Passphrase anyway, which makes this a one-liner. Before: my $passphrase = Authen::Passphrase::SaltedDigest-new( algorithm = 'SHA-256', salt_random = 20, passphrase = 'super secret', ); After: my $passphrase = Authen::Passphrase::BlowfishCrypt-new( cost = 8, salt_random = 20, passphrase = 'super secret', ); I believe A::P will cleanly handle mixed data (including data it didn't create; it handles plenty of hash types), as well, so there is really no reason to not migrate to this. (FWIW, things like bcrypt make brute-forcing theoretically impossible. On my LUKS disk, the key is strengthened with about 2 seconds worth of computation. Assuming someone trying to break my password could get a million computers, it would take them about 665 years to try all possible 10-character passphrases. That puts breaking the encryption out of the range of governments, not just some punk that hacked your server.) Protecting your users passwords like this requires no additional code, so I don't see why you wouldn't do it. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Arguments checker module
You seem to hate everything. I am confused as to why people even waste their time trying to help you. * On Wed, May 06 2009, Bill Ward wrote: 1. Same problem as Moose - it changes the language too much for my taste. I don't see what all the fuss is about declaring $self. Most people want to write code that implements the logic of their application, not work-arounds for missing language features. You write that once, and then use it everywhere. Reuse, they call it. Less noise == code that's easier to read and understand. That's what the fuss is about. 2. Not robust enough - big alpha software warnings are a huge turn-off to me. I think it's more like, anything I didn't write is a huge turn-off to me. Admitting that is the first step ;) But anyway, I would also avoid Method::Signatures -- it was just some stuff from the Devel::Declare test suite that Schwern++ decided to CPAN. MooseX::Method::Signatures (and MooseX::Declare) is the production-ready version. (And yes, I do use MX::Declare in several production applications. It has not caused me any problems at all, other than perhaps a bit of extra wear on the tab key.) Anyway, embrace modules. They are the reason to use Perl. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: New Module
* On Sat, May 02 2009, Aristotle Pagaltzis wrote: * Jonathan Rockway j...@jrock.us [2009-05-01 19:15]: People will find your module, even if the name doesn't make sense. (Examples: Moose, Catalyst.) Yeah, if there are thousands of other programmers using a module, then its name can be pretty much anything. If more or less the only marketing it has is search.cpan.org results page, then most potential users will miss it unless its name is descriptive and based on keywords someone might actually use to search for something like it. This is why Perl people should blog more. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: New Module
* On Thu, Apr 30 2009, Ivan Wills wrote: My module uses template toolkit templates. By manage I mean provide a command line tool to supply template parameters and print out processed templates. My long term goal is to provide a infrastructure to produce commands like catalyst.pl or h2xs which uses templates, instead of being coded into the scripts/modules of those commands, so that you can override templates if you don't like the defaults those programs use. I would use the App:: namespace for this. In the end, it doesn't really matter what you name your module. Concentrate on writing it, and worry about naming later (or never). People will find your module, even if the name doesn't make sense. (Examples: Moose, Catalyst.) Also, don't worry about the people that want you to justify the module's existence by explaining how it's different from other things. The other things are worth considering (the best code is code you didn't have to write), but if you don't like the existing stuff and you can't fix it, write your own. You don't need to be accountable to anyone but yourself. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: managing your perl
* On Mon, Apr 13 2009, Joshua ben Jore wrote: /Now/ I can rebuild the set inside of half an hour which is /actually/ about 28 minutes too long. More highly annoying things are CPAN.pm being unable to install from a set of local tarballs. I tried for a bit to manufacture some small bits of program to create a local CPAN repo and had some success but not enough that my sysadmin incorporated it. Uh, CPAN::Mini and CPAN::Mini::Inject? Andreas also maintains a list of CPAN module prompts and the correct answers. You can use that to install modules without answering questions for them. (BTW, when I fix the perl build system, you will have to go way out of your way to ask the user stupid questions. No more Are you sure you're sure you're sure that you want to install the MANDATORY modules [y]) Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: a lot of controversy about Module::Build
* On Thu, Apr 09 2009, Arthur Corliss wrote: On Thu, 9 Apr 2009, Eric Wilhelm wrote: A common plaint I hear about perl code *from people outside the community* is that we have too many dependencies and our code is too hard to install. ... If on top of that you want them to *upgrade perl* they're going to think you're mad. Ruby didn't seem to have a problem getting installed. There's a huge difference in installing a new software stack altogether and updating something that's there by default on just about every UNIX out there. Given how many OS's use Perl scripts for administrative tasks I wouldn't necessarily be surprised to learn that some of them also bundle some CPAN modules with their package just to keep that running. So, if your vendor doesn't update the system perl, you shouldn't be overwriting it with no regard to the consequences. Even more so when you have people installing modules via CPAN and outside of package management. They always run the risk of updating perl and forgetting a litany of other modules that were installed for various scripts, etc., which use XS modules, etc. The anticipation of that kind of triage is more than enough reason for a lot of people to avoid updating perl. How many sys-admins and non-developers are aware of perlocal.pod? Most people I know compile one perl for each of their applications. The OS perl is for the OS, not for you. (OK, and packages the OS installs. Basically, if you plan on modifying anything perl touches in any way, you want your own perl install for that. Otherwise, yeah, you will break your OS. Why would this surprise anyone?) Admittedly, it would be nice if this process were easier, although I think using local::lib for development and PAR for deployment is a pretty good off-the-shelf solution. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: a lot of controversy about Module::Build
* On Thu, Apr 09 2009, Bill Ward wrote: On Thu, Apr 9, 2009 at 11:26 AM, Jonathan Rockway j...@jrock.us wrote: Most people I know compile one perl for each of their applications. The OS perl is for the OS, not for you. (OK, and packages the OS installs. Basically, if you plan on modifying anything perl touches in any way, you want your own perl install for that. Otherwise, yeah, you will break your OS. Why would this surprise anyone?) You'd be surprised... So maybe we should try educating users, instead of holding back the ENTIRE COMMUNITY for their sake. -- print just = another = perl = hacker = if $,=$
Re: PBP Module Recommendation Commentary and recent CPAN ratings spammings
* On Wed, Apr 08 2009, Burak Gürsoy wrote: OK, the intention is good but the location (perlfoundation.org) of that page is not that good maybe, since someone flooded CPAN Ratings with a reference to that page. So? If you haven't learned to take things you read on the Internet with a grain of salt, then you deserve what you get. All the code implementing the recommended modules is freely available to read. If you really want to know whether the code is good or not, download the code, get a cup of coffee, open your favorite editor, and play with it. That will buy you a lot more than reading cpan-hatings or some wiki will. Regards, Jonathan Rockway -- use strict; print join ' ', Just::, another::, Perl::, hacker::
Re: PBP Module Recommendation Commentary and recent CPAN ratings spammings
* On Wed, Apr 08 2009, Burak Gürsoy wrote: Maybe you should learn to read first before replying anything. Maybe you should learn to write before replying anything? :) Seriously, though, do we really need to have a personal-attack-war? Let's make fun of Python instead! Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: ARGH!
* On Fri, Feb 20 2009, Aristotle Pagaltzis wrote: A great bonus is that while messing around in an object’s internals outside your own package is easy to do, there’s some pretty repulsive syntactic salt associated with it – as it should be. A great bonus? Easy things should be easy. You shouldn't need syntactic salt to prevent yourself from writing bad code. You should avoid writing bad code because it's bad. I could go on and on about why inside out objects are worthless, but it's not worth the effort. Anyone that cares already knows :) Fortunately, it's easy to remove all that brain damage anyway: http://search.cpan.org/~swalters/Acme-RightSideOutObject-0.01/lib/Acme/RightSideOutObject.pm Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: ARGH!
* On Thu, Feb 19 2009, Ovid wrote: Java programmers learned long ago not to let people touch their privates, Perl programmers should learn the same thing. This is one of Java's worst design decisions. A while back, I needed to customize the way URLConnection worked. The parts I needed to touch were private, so I had to copy the source files from the open source java implementation, modify one line, and use my custom library instead of the one bundled with the JVM. All because they said private instead of public, and the runtime insisted on enforcing that restriction. (Sure, they could change the implementation out from under me. I am willing to take that risk. The point is that it should be *my* decision, not the module author's decision.) In general, you should make it clear that internals are at your own risk, but you shouldn't physically prevent access. It just wastes everyone's time, and doesn't make any code more maintainable. (Since I'll just have to cut-n-paste to work around it.) In general, whenever Java does something, you actually want the opposite. This case is no exception. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: RFC: String::Tagged
* On Fri, Jan 30 2009, Bill Ward wrote: On Fri, Jan 30, 2009 at 2:32 AM, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: On Thu, 29 Jan 2009 16:57:42 -0800 Bill Ward b...@wards.net wrote: Why just strings? Why not scalars? Because only strings have character positions. I must confess I didn't read your docs at all, just going by the name and the basic description I assumed you meant tagging in the sense that is used on blogs, Flickr, etc. as a means of organizing or labeling data. I agree here. There is prior art for calling these overlays: http://www.gnu.org/software/emacs/elisp/html_node/Overlays.html BTW Padre folks, you should use this module :) Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Specifying different bug trackers?
* On Tue, Jan 27 2009, Chris Thompson wrote: Can I prevent people from opening tickets on rt.cpan,org. Does the bugtracker item in META.yml cascade through to the front page of search.cpan? No, it doesn't. How can I make the RT emails for my module NOT open a ticket, but bounce with a message, or even better, forward to my lighthouse incoming email? I think you will have to roll your own here. I recommend a quick procmail rule that redirects incoming mail from RT to your own bug tracker. Really though, RT.CPAN is quite nice these days. You can even connect to it with SD and work on tickets offline. I find this much nicer than maintaining my own infrastructure. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Specifying different bug trackers?
* On Tue, Jan 27 2009, Andy Lester wrote: On Jan 27, 2009, at 2:52 PM, Jonathan Rockway wrote: Can I prevent people from opening tickets on rt.cpan,org. Does the bugtracker item in META.yml cascade through to the front page of search.cpan? No, it doesn't. Yes, it does. See http://cpansearch.perl.org/src/PETDANCE/ack-1.86/META.yml and how it reflects on http://search.cpan.org/dist/ack/ Ah, I read this as the front page of RT.CPAN, which is not aware of anything in META.yml. It would be nice if rt.cpan.org allowed authors to shut down queues, but hey, I'm not arguing with a free service. The idea is for something to exist for when authors Go Away, their email address stops working, and their own bugtracker 404s. Of course, RT also works when the author is still around. :) Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: META.yml how to declare the need for threaded perl?
* On Sat, Nov 01 2008, Dr.Ruud wrote: Gabor Szabo schreef: I guess we can implement everything with fork but I think - maybe because of my lack of experience in threads - that it will be better to use them than to fork. I think it was Randal Schwartz who said something like: If the answer involves threads, then the question was wrong. This assumes that you value snide comments over working code. Anyway, I wouldn't use threads for this, but that doesn't make threading an unreasonable approach. I would use POE. (Oh, and by would, I mean do: http://git.jrock.us/?p=Server-Stylish.git;a=summary ) Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: META.yml how to declare the need for threaded perl?
* On Fri, Oct 31 2008, Gabor Szabo wrote:
Hi,
currently I have this code in Build.PL to check if the perl where Padre
is being installed is threaded.
use Config;
if (not $Config{usethreads}) {
warn Padre requires a perl built using threads\n;
exit 0;
}
Probably off topic, but last time I tried Padre, I commented out all the
references to threads (non-threaded perl here) and it worked fine.
Maybe it doesn't really require threads?
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
Re: Arrays in Config::General without resorting to copy/paste OR yaml
* On Wed, Oct 29 2008, Sawyer X wrote: I'm trying to set a configuration file with Config::General and apparently to set an Array, I need to the following example: example lamp = linux lamp = apache lamp = mysql lamp = perl /example When using keys that are long, it's simply a copy paste issue. Isn't the a more comfortable way? These don't work either: lamp linux, apache, mysql, perl /lamp What is stopping you from post-processing this into the data you want? You are but a simple split away from having this syntax work. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Arrays in Config::General without resorting to copy/paste OR yaml
* On Wed, Oct 29 2008, sawyer x wrote:
I'm using Moose with MooseX::SimpleConfig
I guess it'd be nicer if the configuration module (Config::Any) or
even MooseX::SimpleConfig role would do this instead of having to do
sub BUILD {
my $self = shift;
$self-method( [ split /,/, $self-method ] );
}
In this case, I think you can write a custom Config::Any plugin:
package Config::Any::Foo;
sub extensions { 'foo' }
sub load {
my ($class, $filename, $args) = @_;
...
if( whatever ) { split /, /, ... }
return ...
}
Then if you have a .foo file, this code will run to load it. Totally
untested, but something like this should work.
BTW, I would just use YAML (or JSON) here. Config::General is one of
the ugliest file formats I've ever seen, and it maps poorly to Perl.
YAML is nice looking and maps perfectly to Perl.
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
Re: Integrating license related things of CPAN
* On Thu, Oct 23 2008, Bill Ward wrote: Perhaps when you upload to PAUSE without a license in META.yml it could actually replace the META.yml with one that has a license, based in input from an HTML form? Would that be too weird? I think it's technically feasible. So if the user doesn't provide information, PAUSE should just make it up? That doesn't sound very valuable. Now someone reading the license field will have to wonder whether they are looking at the real license or just the license that was randomly selected by PAUSE. This negates the entire usefulness of the field. Also, altering the contents of a distribution will break the signature generated by Module::Signature. Some other thoughts... is the license specified in the META.yml legally binding in any way? If not, anyone using the module will have to look at the rest of the distribution to determine its license, again negating the usefulness of this field. Then again, I, as the author, don't really know what license my distributions are distributed under. I could pick one, but can I really be sure that it applies? If I use Term::ReadLine and it picks the Term::ReadLine::Gnu, is my module GPL now? I don't know and I don't care. Does anyone else? Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Exporter::Safe?
* On Fri, Jul 18 2008, Bill Ward wrote:
Sorry for replying to an old thread... but I was catching up on old email.
It occurs to me that if we had the behavior that OO method calling
would reject any imported modules, wouldn't that solve the problem?
How do you tell what an imported subroutine is?
There is lots of valid OO code that works exactly like Exporter, namely:
*{ ${caller}::foo } = sub { ... }
I don't see a way to implement what you want without making Perl
unusable for modern development. :)
I can't think of any reason you would want to use an imported
subroutine as an object method
Roles/traits. OO is more than inheritance these days.
Anyway, I think the conflicting imports can be solved with
Sub::Exporter. It lets you rename the imports to something useful.
Obviously not every module on CPAN uses S::Ex, but they should start.
In the mean time, you can work around with something like:
package Work::Around;
use strict; use warnings;
use Sub::Exporter -setup = { exports = [qw/foo bar/] };
use Broken::Module qw(foo bar);
1;
Untested, but something like that.
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
Re: Proposal: Test::Refcount
* On Mon, Jul 14 2008, Paul LeoNerd Evans wrote:
On Tue, 15 Jul 2008 06:11:25 +1000
Ivan Wills [EMAIL PROTECTED] wrote:
If Paul LeoNerd Evens doesn't want to create the module Devel::Refcount
along with Test::Refcount I would be happy to do it my self.
Well, it's not that I don't want to as such.. I'm just not sure it's
really justified.
It's kindof a personal thing, but I have a disliking for the mass
accumulation of really small one-liner modules around the place.
I like these. It's as important to reuse simple things as it is to
reuse complicated things.
Would anyone consider
package String::CaseInsensitive;
sub casecmp { lc $_[0] cmp lc $_[1] }
1;
as a module, for example?
No, but that's because lc is the hard part, not the call to cmp. If
Perl didn't have lc built in, you'd bet I'd want the lc function
from a module, rather than the simple (but wrong) tr/[A-Z]/[a-z]/.
When the module starts to get this small, I begin to wonder if it's more
of a documentation issue. Perhaps somewhere in the documentation about
objects and reference counts:
The reference count of an object can be obtained by
use B qw( svref_2object );
my $count = svref_2object($ref)-REFCNT;
Considering B is core, there is probably no need for a module to do
this. But, does this always return correct results? Does the
svref_2object call affect the REFCNT? I am too lazy to check, but these
are nice questions for the documentation to answer. If svref_2object
affects its argument, then it's probably best to write a module that
compensates for this behavior.
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
Re: Proposal: Test::Refcount
* On Mon, Jul 14 2008, Paul LeoNerd Evans wrote:
On Tue, 15 Jul 2008 00:44:12 +0100
Paul LeoNerd Evans [EMAIL PROTECTED] wrote:
SCALAR = do { \my $var },
It seems I can make the SCALAR ref have refcount 1 by changing this to
SCALAR = do { my $var; \$var },
Various initialisations {e.g my $var = 1} also keep it happy.
Just the CODE and GLOB to go then...
Hmm, it might be a good idea to ask about this on p5p. It would be good
to get this right Once And For All and make it really easy to use.
Memory cycles are the most common cause of memory leaks in Perl, and
they're really easy to fix once you know about them. So a module that
makes them easy to find would be very good for everyone :)
Thanks for your work so far ;)
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
Re: Name space: throwing exceptions easily
* On Wed, Jul 02 2008, Aristotle Pagaltzis wrote: On this, I disagree. Here’s litmus test: would you ever use the opposite adjective in a description? If not, it’s not useful. I think you’ll agree that no one would call a module Exception::Complicated except as a joke. That means “easy” provides no useful differentiation in practice. I don't think this tests what you think it tests. People don't name their module Foo::Complicated because they don't want to admit the interface is complicated. People *do* call modules Foo::Easy because they're proud that they made Foo easy. So the module naming here reflects the author's personal or societal hangups, not the validity of any naming scheme. In fact, the “simplified” in “simplified interface” is largely redundant. Using an interface by definition means you are looking for simplification in doing or accessing the thing that the interface provides. Easy means less features to learn. Ever use XML::LibXML? It's big. It's hard to get started with it. If you just wanted to XPath some XML string, you might like a module like XML::LibXML::Easy to exists. Instead of creating a parser, parsing a balanced chunk into a document fragment, initializing the XPath engine, adding some namespace, running the query, and then printing the returned nodes; you might just want to say 'xml(foo)-xpath(//foo)-stringify'. That's not nearly as complex as XML::LibXML, so why not call it Easy? Of course, you lose a lot of power with that API. Tradeoffs. Similar words that say something without communicating anything are “fast” and “flexible.” No one would say that they are trying to achieve slowness or inflexibility. Usually the slow/inflexible version comes first, so it gets the base namespace. If history could be rewritten, then the slow version would be replaced with the fast one... but that's not always possible, especially with how CPAN.pm works. Basically, the names of CPAN modules are hacks around CPAN itself. I see a trend here… you are the person who argued loudly that in the end, anyone who wants to know how Catalyst works needs to read the code, regardless of the state of the docs… I'm not sure why this upsets so many people. If you want a complete understanding of every detail of a codebase, you have to read it. You're not going to get any better at programming if you never read code. This is what I believe and I'm going to stand by it. (If you don't want to be good at programming, that's fine with me. Give me some money and I can solve your programming problems for you :P) Anyway... if you don't want to read the code, I hear there's a whole book about Catalyst. Then again, you are the author of a Catalyst-based weblog app called Angerwhale, which makes me wonder if you haven’t long forfeited your right to take part in *any* discussion about naming. :-P Modules and applications have different naming standards. I think most of my modules have names that make sense. I can't think of any applications I use that have names that make sense, however. emacs for editing text? amarok for playing music? urxvt for emulating terminals? irssi for chat? None of those names make any sense at all. So I don't feel like I'm alone in coming up with weird-ass names for things :) Names for modules need to be somewhat related to what they do, but you probably shouldn't devote too much mental energy to coming up with a name. It's just not *that* important. (Opaque identifiers)++ Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Maintainer mode
* On Tue, Jun 10 2008, Elliot Shank wrote:
Dave Rolsky wrote:
On Tue, 10 Jun 2008, Eric Roode wrote:
How do you do that, by the way? How do you set it up so the test
suite knows it's you and not an end-user?
plan skip_all = 'This test is only run for the module author'
unless -d '.svn' || $ENV{IS_MAINTAINER};
Perl::Critic used to do that sort of thing, but no more. Too many
times people would grab from the public repository or have the same
environment variable set and the author tests would run and we'd get
failure reports. Now, in order to run author tests you actually have
to specifically invoke a Module::Build target to get them to run
This is basically what I do. Normal tests are t/*.t, author tests are
t/author/*.t, and I just prove -Ilib t/author when I want to run the
author tests.
If I want multiple levels (t/*/*.t), then I put my author tests in
t_author instead. It works well enough :)
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
Re: Maintainer mode
* On Wed, Jun 11 2008, Hans Dieter Pearcey wrote:
On Wed, Jun 11, 2008 at 12:31:00PM -0400, Eric Roode wrote:
I thought xt was for author tests. What means xt/author??
No, xt is for 'extra tests'.
xt/author -- run when testing as an author
xt/release -- run these right before you release, only
xt/smoke -- run these only for automated testing
Maybe the subdirectory name should be a string containing code to
execute to determine whether or not to run the contained tests. For
example:
xt/$ENV{PAUSE_ID} eq 'JROCKWAY'/pod_coverage.t
xt/!-e 'META.yml'/prerelease.t
For extra kwalitee, don't forget to use strict and warnings:
xt/use strict; use warnings; $ENV{PAUSE_ID} eq 'JROCKWAY'/pod_coverage.t
xt/use strict; use warnings; !-e 'META.yml'/prerelease.t
Yes, I'm kidding. :)
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
Re: Application Building
You really didn't say much about what you're trying to do. You said you
did some stuff and some other stuff didn't happen. It's hard to help
you -- what *exactly* is the problem? (There are plenty of things that
install and run apps on the CPAN. App::Ack comes to mind. It Just
Works, there is nothing special you need to do.)
That said, I always do this:
package MyApp::Script::Whatever;
use Moose;
with 'MooseX::Getopt';
has ...;
sub run { ... }
Then:
#!/usr/bin/env perl
use FindBin qw($Bin);
use lib $Bin/../lib;
use MyApp::Script::Whatever;
MyApp::Script::Whatever-new_with_options-run;
This is similar to your parse $0 solution. But of course it won't
work for installed scripts where the library directory isn't in @INC.
If I put #!perl at the top of display.pl it will have a path to perl
(though not the one I specified), but it won't have use lib $HOME/MyApp/lib
at the top of the script, so it can't run.
Furthermore, there's no way for the script to know what was used
for install_base, so there's no way for the script to know where the data
file is located.
This must be something people do, right? Currently I hard code paths
and force the installation to be where I want it, but this seems really
sub-optimal, doesn't work for having test environments, etc.
I've been considering parsing $0 at the top of the script, is that
what other people do?
All I can say about this is ... right. You need to put the path where
you install stuff into @INC (via PERL5LIB). See local::lib, for
example. Module::Build (etc.) isn't going to edit your file to
hard-code the install path... I guess you could do that, but I've never
seen anyone do that.
Perhaps you are worrying a problem that doesn't exists?
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
Re: Idea: CPAN Category Reviews
* On Sat, Apr 05 2008, Shlomi Fish wrote: Hi all! In regards to the previous discussion about trimming down CPAN and finding better ways to find quality modules, I got an idea of making CPAN category reviews. The idea was originally derived from Freshmeat.net where they often have category reviews of the various software hosted there: http://themes.freshmeat.net/articles/section/category%20reviews/ Now I thought of importing that idea for CPAN. [cut] So what do you think - is there an interest in this? I think you should just do it. Then we can see if there is interest or not. Personally, I don't like reviews. I think reviews tend to aim for quantity over quality. For example, can you really become an expert in Template Toolkit, HTML::Mason, Template::Declare, and HTML::Template in a weekend, and then write an article? Of course not -- I use TT and TD extensively every day and I don't think I could give them a fair review. There are parts I like, but I don't think I could give you a full overview on exactly why or why not to use them. So the issue is that the reviews are very superficial unless the reviewer is an expert in all of the modules, which is rarely the case. If there are 5 similar modules, you are probably just going to pick one -- in which case, you won't be qualified to write about the other 4. So anyway, I prefer articles like here's a cool thing I did with Foo::Bar. People can see what's good about Foo::Bar in a natural way, instead of having some review shoved down their throats. If some like Quux::Foo better, then they can write an article about that. In this system, the experts write about their areas of expertise, and let everyone else make decisions for themselves. I think that's what we need more of. As an example: http://blog.jrock.us/articles/Devel%3A%3ABeginLift.pod I suppose you could categorize that as documentation, but I like it for the here's a module you haven't heard of before factor. Another example: http://blog.jrock.us/articles/Adding%20more%20methods.pod The goal there was to show what you can do with Class::MOP and Moose. It's probably something you weren't looking to do, but now that you know about it, you have a new tool in your toolbox. I think that is more valuable than comparing Text::Template and TT. Anyway, no need to worry about what I think. Just add yourself to Planet Perl and start writing. Instant access to 2000+ readers. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Changing the focus of the chronic CPAN problem
* On Sat, Apr 05 2008, Eric Wilhelm wrote: It appears that our current strategy is this: * rely on a proprietary web application for search (search.cpan.org) I like kobesearch better. I hear the code for that is available, which is the main reason I like it better :) I haven't actually looked at the code yet though (or talked to Mr Kobes). * create multiple, unconnected web apps hosting diverse information * mention and apologize for the above web apps in a wiki (web app) * count on fewer than 10 people to keep the web apps working So, I would love to see a better strategy -- probably involving more web APIs and desktop clients, but definitely with more openness. I've wanted easily-available CPAN-related APIs also, so I wrote this (with the help of brian d foy++): http://git.jrock.us/?p=MetaCPAN.git;a=summary This indexes the BACKPAN and CPAN and lets you ask questions like what version of Foo::Bar was current on January 8th 2004? or give me all dists containing Quux::Baz, in release order. I needed this feature for git-cpan, which is also on the back burner for now. (git-cpan == every cpan module + history available in a read/write git repository. Now that everyone's using git anyway, I think this would be even more useful than when I thought of it... but it's a tuits issue right now :) Basically, tell me what sort of data you want available through the REST interface, and I will take care of finding the data and keeping it up to date. You can also have the sqlite database if you want (it's about 200M right now). I haven't had time to write the sysadminy stuff yet (get cpan via rsync, reindex new modules, etc.) ... or the web interface for that matter... but all the data gathering and analysis stuff is there. Patches welcome! Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Removing or Archiving outdated and unsupported modules on CPAN; proposal
* On Thu, Apr 03 2008, Dave Rolsky wrote: On Thu, 3 Apr 2008, John M. Gamble wrote: Okay, that was uncalled for. It wasn't incoherent, and it wasn't a rant, and trying to be dismissive like that doesn't help even if the thesis was wrong. I agree that the problems listed mostly aren't problems (on the other hand, I'm not going to pretend Time::Cube didn't happen). Furthermore, the best solutions to the perceived problems are patch first, apply for co-ownership second. I agree, Jon (R), there's no call to be so rude. I apologize. I get upset when people feel they are *entitled* to CPAN modules (or the CPAN, or Perl, or Linux, or emacs, ...). It shows that they don't really understand the open source movement. The open source movement is about sharing, not taking. People that take and never give back aren't worth being nice to. CPAN is an all volunteer effort. In an ideal world, every module would be perfect. We don't live in an ideal world. The only way to make modules better is for *you* to make them better. I agree that it's annoying to find an almost perfect module on CPAN, except for just this one thing. But it would be a lot more annoying to have nothing at all. (Even stubs are useful; it shows someone else is interested in the topic, and it gives you a good name.) Anyway, when I find a bug or missing feature in a module I want to use, I consider myself personally responsible for that problem. If I want a feature so badly, why don't I write it myself? (I think other people should consider adopting this attitude :) If they do, there will be more coding and less whining on mailing lists, which is always good.) Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Removing or Archiving outdated and unsupported modules on CPAN; proposal
for the perl-version associated with the bug, removed (indicating the module doesn't work in that version of perl). Nothing would prevent a module maintainer from re-adding the tag, but hopefully they'll close out the bug(s) that caused the tag-removal in the first place (either by fixing it, or marking it as NOTABUG, ISAFEATURE, or WONTFIX). (whatever values that make the bug no longer 'active'). More work for authors? I already have to maintain 30 modules. If I have to do work for no reason, you can bet that I won't bother uploading to CPAN in the future. Is that what you want? 6) Modules that are more than 2 or 3 stable .versions 'old' would be automatically moved to 'archive.cpan.org'. I.e. with 5.10 out, cutoff would be those modules not marked with tags for anything later than 5.4 or 5.2 (respectively) (in my mind, something written for 5.4 may or may not work but if something hasn't been known or marked to work with anything newer than 5.2, I'd have a low confidence of its current usefulness. There is no such thing as perl 5.4 :P Also, why wouldn't old modules work with new Perls? Perl is supposed to be backwards compatible. And usually is. Auto expirations would get rid of the stuff that no one cares about (or at least not enough to check with newer versions) and would prevent crude from building up, forever, over time. Define no one. Not an area I want to address with this -- If it is obsolete or broken for years, I don't care if it is rated 10 stars, it still shouldn't clutter up the working CPAN library. It's not hard if someone wants to 'game' the system. If someone is 'gaming' the system, this isn't meant to deal with that. It's only meant to slowly expire older, non-working modules and archive them for historical reference. The core of your argument confuses me. You want to archive things. What is the difference between archiving something and not archiving it? You want two search sites, one for non-archived modules and one for archived modules. No offense, but that sounds like a waste of effort. Does this sound like a reasonable, concrete and automatable proposal? No, it sounds like an incoherent rant from somebody that knows nothing about the CPAN. Basically, it sounds to me like you're new to the CPAN. After you use it for a few years, you will learn how to find good distributions that will solve your problems. It's called experience, and is something that only time can bring. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: cpan-testers in the inbox
* On Mon, Feb 11 2008, Andy Lester wrote: http://log.perl.org/2008/02/no-more-email-d.html Well I guess that settles that. :) This is unrelated to the usual whining about receiving FAIL reports in your inbox. Those are sent directly by the smoker, not via the cpan-testers mailing list. The cpan-testers mailing list is a mailing list that sends *every* cpan testers report; good for, say, irc bots that announce the results of testers reports live. Regards, Jonathan Rockway
Re: Namespace for new perl (chess) module
* On Mon, Feb 04 2008, Christian Bartolomaeus wrote: I think about putting some generic, non-specific methods in a separate module, which wouldn't be useful by itself, but would be used by the more specific modules. Maybe it would be useful to put those generic methods to Chess::Rating::Calculate Sounds good. But how about just Chess::Rating? There's no reason to be too verbose... Chess::Rating is clear and easy to type. Anyone searching for a module that calculates chess ratings will likely find yours and the name will encourage them to read more about it. That's the goal. Also, do the users care about the algorithm used to calculate the rating? Would it not be better to have an API like: my $r = Chess::Rating-new( method = 'FIDE', ... ); rather than many separate modules? Anyway, CPAN is very ad-hoc. People will discover your module if it has good docs, so there's no need to worry too much about the name. Good code speaks for itself ;) (Who would guess that Angerwhale is blogging software or that Catalyst is a web framework? Hopefully nobody, but both have quite a few users.) Regards, Jonathan Rockway
Re: Maintenance of IO::Socket::INET6 - http://search.cpan.org/dist/IO-Socket-INET6/
* On Sun, Feb 03 2008, Gabor Szabo wrote: On Feb 3, 2008 12:01 PM, Shlomi Fish [EMAIL PROTECTED] wrote: And some people go on holiday for more than that. The question is: how long should we wait? There wasn't a new release of IO::Socket::INET6 for over three years, and it has three pending bug reports. This probably indicates that the author is missing-in-action. Instead of this infighting why not just upload a development version of the module with something like this in the pod: This is an unnofficial version of module X::Y::Z till the original module author reappears or till I get official maintainership of the the module. Excellent idea. Another possibility is to release a subclass of the module that has your fixes in it. Then people can use IO::Socket::INET6::Shlomi, and forget about the brokenness in IO::Socket::INET6. When I::S::6 fixes the bug you can re-upload your module as a simple package IO::Socket::INET6::Shlomi; use base IO::Socket::INET6; 1. It's not *ideal*, but we don't live in an ideal world. This is a pretty good solution, though. Regards, Jonathan Rockway
Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
Andy Lester [EMAIL PROTECTED] writes: On Jan 29, 2008, at 11:32 AM, Jonathan Rockway wrote: To be honest, it's usually humans that provide the least useful reports. The bots do a much better job. If they're using CPAN::Reporter, then it's all the same. Humans include a lot of extra junk, and they've usually misconfigured their machines. (I force-installed your dependencies but now your module IS BORKEN!!!11 Yes, I've gotten that a number of times.) Bots do not report actual use cases. They report imagined, speculative use cases. Like whether or not cpan -i Your::Module works on a clean install? Yeah, that sure is a imagined use case. Regards, Jonathan Rockway
Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
Andy Lester [EMAIL PROTECTED] writes: On Jan 29, 2008, at 10:10 AM, Philippe Bruhat (BooK) wrote: Maybe the most practical option is still the global skip file mentioned by David Golden. Uninterested people would get a single unsollicited email, and would need to opt-out once only. Except that the global skip file would need to apply to individual bots, not the entire cpan-testers architecture. Again, I have no problem with human reports. It's the bots I mind. To be honest, it's usually humans that provide the least useful reports. The bots do a much better job. I'm all for the robots.txt sort of thing, though. I would like to get every FAIL mailed to me without having to subscribe to the cpan-testers mailing list. A frequent annoyance is seeing the IRC bot announce a failure but having to wait an hour for the nntp.perl.org archive to catch up before I can see what the problem is and start working on a fix. (It would be nice if the main cpantesters site updated faster also, but I'm fine with just email.) Regards, Jonathan Rockway
Re: Date::Piece months and weeks
On Fri, 2008-01-04 at 13:50 -0500, Keith Ivey wrote: Jonathan Rockway wrote: Uh, in en_US we say this too. There are people in the US (and probably other places) for whom I went to the zoo this Sunday is perfectly grammatical. Some might say this past Sunday to distinguish it from this coming Sunday, but the tense of the verb is enough. http://www.google.com/search?q=%22went%20*%20this%20sunday%22 There are people in the US that think 2 + 2 = 5, also: http://www.google.com/search?q=%222+%2B+2+%3D+5%22 But anyway s/en_US/en_US.jrockway/ in my original post :) Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: EUMM and Module::Build installations - Oh God, Help!
On Fri, 2007-12-21 at 03:36 -0800, Ovid wrote: Is there some script out there which will properly configure CPAN::Config to give us fine-grained control over all of this? Is there something I've missed in the above? local::lib is close, although it just changes the PREFIX (for EUMM and MB). http://search.cpan.org/~apeiron/local-lib-1.001000/lib/local/lib.pm Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: With the Macrame macro system, Perl may now be a Lisp.
On Fri, 2007-12-07 at 20:54 +, Nicholas Clark wrote: One particular problem can be that if something you use adds a dependency on something else you weren't previously using, so you can reach the situation where upgrading to fix a bug will also bring in something new that you didn't want (for valid local policy reasons). All I'm saying is that you can't control what other people do. People experimenting with Perl 5 aren't going to stop simply because someone on the mailing list says it might make his job harder. If dependencies are a big problem for your business, learn to fix the CPAN modules, or don't depend on them at all. I get upset when arguing about this because I have never had a problem, and I depend on a metric fuckton of CPAN modules. (I'm sure a nit has come up from time to time, but I just send a patch to the author and it's fixed forever.) BTW, I like the term failed experiment. Isn't everything a failed experiment? Should we remove CGI.pm from the CPAN because CGI.pm-style code is a failed experiment in writing web applications? Should we all stop using emacs because elisp's lack of static scope is a failed experiment? Should we forget about java because single inheritance is a failed experiment? Should we stop using Perl because TMTOWTDI is a failed experiment? To be clear, my point is that everyone thinks differently. What you consider failure many consider success. Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: With the Macrame macro system, Perl may now be a Lisp.
On Fri, 2007-12-07 at 10:44 -0800, Bill Ward wrote: Experimenting with the language itself should be reserved for new development such as Perl 6, not for trying to add yet more layers on top of Perl 5. Hi. Nobody cares about your opinion on this matter. Many perl5 experiments have been quite successful; for example, Moose. The great thing about Perl is you can choose what to use. Don't like macros? Don't use 'em. Don't like people using macros in CPAN modules? Don't use 'em. Trying to control what other people think and do will get you nothing except flames. Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: Help with Test Failures
On Sat, 2007-12-01 at 06:51 -0800, Bill Moseley wrote:
Any ideas on how to add a make test-exclude-recommends to Makefile.PL to
make that easier?
Add something like this to Makefile.PL
my @RECOMMENDS = qw/.../
requires $_ for @RECOMMENDS; # or whatever
sub MY::postamble {
my $optional = join ',', @RECOMMENDS;
return EOM;
test-exclude-recommends:
\tperl -MDevel::Hide=-from:children,$optional 'exec(make test)'
EOM
}
Untested.
Regards,
Jonathan Rockway
signature.asc
Description: This is a digitally signed message part
Re: Help with Test Failures
On Sat, 2007-12-01 at 09:49 -0800, Bill Moseley wrote:
Not sure Module::Install does anything with those recommended modules,
though. ;)
MI (with EUAI, I think) will prompt you to install optional dependencies
if you specify them like this:
feature ('Description of optional feature', [
Dependency::One = 0.01,
Another::Dependency = ...,
]);
For the record, optional dependencies suck. You can't introspect
installed modules to see if the correct modules are installed for
features your application needs, so you just have to cross your fingers
and hope your sysadmin said OK to the optional prereqs.
If there's some difficult module that you don't want to depend on,
either fix it or release a separate dist that adds the desired
functionality. Much more sane IMO.
It's fine to ask do you want the XS version of these modules, though,
as long as your module behaves the same regardless of whether PP or XS
is installed.
JMHO.
Regards,
Jonathan Rockway
signature.asc
Description: This is a digitally signed message part
Re: With the Macrame macro system, Perl may now be a Lisp.
On Sat, 2007-12-01 at 23:36 +0100, Jenda Krynicky wrote: Yes, I know it is a source filter. And has all the problems of source filters ... that is it can misunderstand something, transform your source code in completely unexpected way and cause next to impossible to find bugs. As such it needs to do something really really important to warrant the danger. This is why I've been ignoring it :) Even the simplest of simple filters like Filter::EOF can go massively wrong. (Multiple packages in a file? You're fucked.) Source filters should be considered a failed experiment, like pseudohashes. IMO, Devel::Declare is the right way to do this sort of thing. Messy code, but much safer to use (and more tests; the test shiped with Macrame scares me with how little it covers). Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: Namespace question: ok if I use Text::Locale
On Mon, 2007-11-26 at 17:46 +0100, Chris Vertonghen wrote: Hello all, I'm writing a module that I dubbed Text::Locale for now. I am thinking about publishing it on CPAN. IMHO, Text::Locale is a little too standard (or approved) sounding for something that's already done better by Local::Maketext::Simple and friends. There's a lot of infrastructure around to support the /lang/*.po format, so I think it's generally advisable to use that instead of writing your own module. BTW, the UUID scheme in your module misses cases where the message has parts whose ordering changes between locales, like: en_US: Hello, $given_name $surname. ja_JP: ようこそ, $surname$given_name！ and then: print loc(Hello, [_1] [_2], $given_name, $surname); Anyway, TMTOWTDI, so I don't want to discourage from finding the best way to do i18n, but do keep in mind that other people have also solved this problem before. Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)
Ovid wrote: I do get tired of writing code like that (it happens a lot in test suites when I have use_ok $CLASS in a BEGIN block). OT, but 'ok.pm' is quite nice: use Test::More tests = 1; use ok 'My::Module'; # test runs at compile time Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: RFC: relative.pm
Pearce, Martyn wrote: -Original Message- From: Jonathan Rockway [mailto:[EMAIL PROTECTED] Pearce, Martyn wrote: It is? How so? Don't top-post. It ruins the flow for people trying to reply to you. Fair point, apologies. I blame outlook, which I use only under protest. Ah, understood. I was stuck with Outlook at my last job, and it was impossible to get it to quote a message in a way that you could actually reply to things point by point. It seemed optimized for sending a message to every person in the company and making all of your text blue. What a fucking joke. Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: RFC: relative.pm
Andy Armstrong wrote: On 9 Oct 2007, at 11:05, Jonathan Rockway wrote: What a fucking joke. If it's a joke you should use Comic Sans so everyone /knows/ it's funny. No no, Comic Sans is for presentations to the shareholders! Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: RFC: relative.pm
Pearce, Martyn wrote: It is? How so? Don't top-post. It ruins the flow for people trying to reply to you. To answer your question, see http://use.perl.org/~Aristotle/journal/33995 . FWIW, I (and thousands upon thousands of others) have used FindBin for years without problems. However, it is annoying if you run into an edge case that doesn't work. I never have though. In fact, I've even gotten away with things like 'use lib $Bin/../lib' working across platforms :) Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: Choosing a name for may new module
Jean-Christian Hassler wrote: Well... The module itself is not made specially for catalyst. I d'like to use it in a view for catalyst in a second time. Just like HTML::Template which is used in Catalyst::View::HTML::Template . Fair enough. Regardless, I think you'll get more interest on the Catalyst list though. Anything that's tangentially related to Catalyst is welcome there, and there's a lot more traffic than on module-authors. Regards, Jonathan Rockway
Re: Choosing a name for may new module
Jean-Christian Hassler wrote: Hello !! I would like to create a module to use as a view in the catalyst framework. You should ask on the Catalyst list instead. See http://lists.scsys.co.uk/mailman/listinfo/catalyst for details. Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Module metadata
David Golden wrote: On 9/25/07, Chris Dolan [EMAIL PROTECTED] wrote: Well, one option might be something like: http://www.cpanforum.com/tags/name/helpwanted Gabor, would it be easy to add an Atom/RSS feed for a particular tag? Please no! Let's not spread module metadata around any more than we have to. Extend META.yml to include the same kind of information that used to be managed via the modules list. If someone wants to write a website to index and syndicate *that*, fine, but don't make authors go to multiple places to create and manage their metadata. Yuck. I don't want to release a new dist just to add a tag to my module. Regards, Jonathan Rockway
Re: Module metadata
David Golden wrote: (Which reminds me to go update my module metadata on CPAN::Reporter since I've changed license and abstract since I first registered. The changes are in my META.yml, of course, but I forgot about PAUSE.) This is a pretty good point and has caused me to change my mind. It would be nice to put all this stuff in META.yml. Keeping data in multiple places consistent is much more painful than uploading to the CPAN. Anyway, should the DSLIP stuff be added to the META-spec? (I see that some stuff, like the S and L parts, are already covered by META.yml. Is the rest worth adding, or is it time to forget about it?) As for keywords, can I use those for anything? It would be nice to replace the manually-generated categories on search.cpan (and other places) with popular tags. Maybe that's too web 2.0y but I think it might be nice :) Regards, Jonathan Rockway
Re: Module Proposal: Package::Data::Inheritable
nntp.perl.org wrote: Hello all. I've written a module to deal with the issue of inheritable class data (yes, yet another one). What's peculiar with it is that it doesn't rely on accessor methods. After declaration, you can use the variables just like any other package variable but you can inherit and override those variables in other packages/classes. I'm thinking of calling the module Package::Data::Inheritable which should reflect the emphasis on package variables rather than on classes. Before uploading to CPAN I would like to check whether I missed some module that does the same and if the proposed name/namespace is good. Not sure what you're trying to do. Is it this? package A; our $DATA = 'A'; package B; use base 'A'; our $DATA = 'B'; package C; use base 'A'; And then: $A::DATA # 'A' $B::DATA # 'B' $C::DATA # 'A' If so, I don't know of anything on CPAN that does this. However, I think inheriting variables is a *terrible* idea. What is your reason for wanting to use variables instead of properly delegating to methods? Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: Modules are missing on CPAN
On Thursday 24 May 2007 08:29:55 am Graham Barr wrote:
On May 23, 2007, at 4:28 PM, Andy Lester wrote:
At first I thought I might have deleted two revisions of
WWW::Mechanize by mistake, but it's not just Mech: SOAP::Lite is
missing revisions.
http://search.cpan.org/dist/SOAP-Lite/ only shows SOAP::Lite up to
0.60a, but I know for a fact that there's been a 0.67.
There is a 0.69 at http://search.cpan.org/~byrne/SOAP-Lite-0.69/
But it contains a module SOAP::Packager that cpanid BYRNE does not
have permission to upload. Permission is given to KBROWN due to first-
come
But you will not see this dist under /dist/SOAP-Lite/ because it
contains unauthorized modules.
Late reply but... how is this helpful to anyone?
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
Re: Module::Install reporting ARRAY(0x82c3dd8) ...missing
On Sunday 17 June 2007 09:52:47 am Bill Moseley wrote:
On Sun, Jun 17, 2007 at 04:17:24PM +0200, Dominique Quatravaux wrote:
Bill Moseley wrote:
# Specific dependencies
requires'Form::Processor'= '0.11',
requires'HTML::FillInForm' = 0,
requires'Catalyst' = '5.50',
requires'UNIVERSAL::require' = 0,
I know nothing about Module::Install, but have you tried using
semicolons instead of commas at the end of those lines?
Geeze.
Turns out coffee helps, too! That's what I get for editing an
existing MakeMaker Makefile.
I think you can actually use EUMM syntax:
requires ( foo = '0.01', MyApp = '3.14', ... ) # parens, not {}
or:
requires foo = '0.01'
requires MyApp = '3.14';
TMTOWTDI :)
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
US mirror of search.cpan *broken*
The bizrate search.cpan is broken. The most recent module (judging by the
recent tab) is from 5 days ago, 23 May.
I'm told that the UK mirror (digitalcraftsmen) is running fine.
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
pgpeDQJtghopx.pgp
Description: PGP signature
unicode filenames
I'm the author / maintainer of a bunch of filesystem-related modules, and ran
into a problem tonight when I realized that none of them really care about
unicode. I'd like to make them smarter, but I'm not sure what I should do.
For things that write the filesystem, the most logical thing to do would be
to encode perl characters into utf8 octets, since that's what's happening now
(with a warning). But not everyone is using utf8, and surely the non-users
would like their data in their native encoding. Any recommendation on the
best thing to do here?
Reading things is a whole 'nother can of worms. Right now my modules are
doing nothing, which seems wrong to me (the user shouldn't have to worry
about octets vs. characters, he should always have characters). The approach
i took in angerwhale was to assume ascii until i could read a config setting
that indicated the encoding (assuming utf8 after that). Unfortunately the
modules in question deal with metadata... so there's nowhere to store
metadata metadata :)
Anyway, any advice would be appreciated. I'm tempted to say use utf8 or die
in the docs, but I think I could do better. For reference, the modules in
question are File::Attributes, File::Attributes::Simple,
File::Attributes::Extended, and Directory::Scratch.
Thanks!
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
pgpXlEkcqD9Sp.pgp
Description: PGP signature
Re: LISP module from CPAN
On Tuesday 08 May 2007 01:40:09 pm David Nicol wrote:
On 5/8/07, Vadim [EMAIL PROTECTED] wrote:
no, it uses CFFI, so this should cover every implementation supporting
that.
Ever since reading Hackers and Painters
http://www.amazon.com/exec/obidos/ISBN=0596006624/tipjartransactioA
I've been defending Perl is a LISP! (which is actually quite easy,
because nobody knows what I'm talking about)
Are there a lot of libraries and things written to CFFI? Perl could
provide a CFFI interface, that would strengthen the perl is a lisp meme.
I think the LISP folks would like to use CPAN, not the other way around.
As for Perl being a LISP... Perl is missing macros (unless you count opgrep
and B::Generate) and continuations. Lisp is also dynamically typed
(originally), which you can admittedly emulate in Perl, i.e.
(let ((mk-adder (lambda (x) (lambda (y) (+ x y ... )
is
our $x;
sub mk_adder { return sub { my $y = shift; $x + $y } }
...
but much cleaner (in Perl-land) as:
sub mk_adder { my $x = shift; return sub { my $y = shift; $x + $y } }
Incidentally, emacs lisp is dynamically typed, but scheme isn't. Confused? I
am. :)
... wow, this is offtopic now.
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
pgplQRObWB40O.pgp
Description: PGP signature
Re: recent search.cpan changes?
On Sunday 06 May 2007 10:50:52 pm Adam Kennedy wrote:
Jonathan Rockway wrote:
Hi all,
I noticed search.cpan is acting differently now (probably due to the HOOO
perl fiasco). Were these changes discussed anywhere publicly before they
were made? I'm interested in a full list of changes, so I don't have to
guess what they are. (I'm a /little/ upset since DBIC developer releases
are missing, modules I own in the modulelist are showing up as **
UNAUTHORIZED RELEASE **, modules are missing from search results,
different mirrors are behaving differently, etc.)
Also, I can't seem to find the search.cpan source. Could someone provide
a pointer to it?
search.cpan is not an official perl.org as such.
It's written and owned by Graham, and blessed with the domain name as
the best implementation of this functionality.
As for your unauthorized release, they are because you made unauthorized
releases :)
You released modules without getting permissions on all of the namespaces.
I suggest you rectify the problem and do an authorized release :)
The problem seems to have fixed itself. The module in question was
Test::WWW:::Selenium::Catalyst, which is the only module in the dist and was
registered to me in the modulelist... but it was only a developer release and
I had never uploaded a real release. Corner case...
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
pgpBmPp6e7e3t.pgp
Description: PGP signature
recent search.cpan changes?
Hi all,
I noticed search.cpan is acting differently now (probably due to the HOOO perl
fiasco). Were these changes discussed anywhere publicly before they were
made? I'm interested in a full list of changes, so I don't have to guess
what they are. (I'm a /little/ upset since DBIC developer releases are
missing, modules I own in the modulelist are showing up as ** UNAUTHORIZED
RELEASE **, modules are missing from search results, different mirrors are
behaving differently, etc.)
Also, I can't seem to find the search.cpan source. Could someone provide a
pointer to it?
Thanks!
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
pgp9rmIDddihN.pgp
Description: PGP signature
Re: Test failures - I can't work out why
On Wednesday 02 May 2007 09:26:56 am Ovid wrote:
--- Keith Ivey [EMAIL PROTECTED] wrote:
Yeah, Zawodny was a joke. But JWZ is still Zawinski, not Zawinsky.
Gah. Kill me now, please.
Some people, when confronted with a problem, think Gah. Kill me now,
please. Now they have two problems.
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
pgpPN95226GvT.pgp
Description: PGP signature
Re: CPAN testers machines that lack Module::Build
On Tuesday 13 March 2007 14:23, Paul LeoNerd Evans wrote:
On Sun, Mar 11, 2007 at 07:43:38AM -0500, David Golden wrote:
That said, i agree in the meantime that providing a traditional
Makefile.PL along with a Build.PL is usually a wise approach, as Chris
suggested.
But to my knowledge, I can't do that, because I have some
'build_requires' lines. I previously had a long discussion about using
Test::Exception, my hesiation centring around the problem that it isn't
a core module, so how to guarantee testing against it. The suggestion
was to use M::B and 'build_require' it. So I don't really want to back
out of that now
Why don't y'all just use Module::Install? It handles build_requires, AND you
can bundle modules with your dist, in case dependencies worry you. Problems
solved.
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
pgpWwlekGGMZt.pgp
Description: PGP signature
Re: Module proposal: Test::Timer
On Thursday 08 March 2007 13:59, Jonas B. Nielsen wrote:
I will look into converting all tabs to spaces, it is simply in the
fingers and I find it hard to not use tab, perhaps I should just map the
key to something else - actually I do not get all the fuss about
tabs, but I will clean it up.
(vim's :retab command is likely to be useful in fixing up this one)
I am using Komodo for this kind of work.
Most real editors will bind the Tab key to an indent-line command, instead of
actually inserting a literal tab (or a fixed number of spaces). Emacs does
this by default, and I couldn't live without it. (And actaully, it even
works for python and Haskell, where whitespace is sensitive. It's quite fun
to see it in action, but I digress...)
However, you will want to set intent-tabs-mode to nil in your .emacs file to
avoid 8 spaces being auto-replaced with a tab.
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
pgpJK1HcTYtFI.pgp
Description: PGP signature
Re: Another non-free license - PerlBuildSystem
Ashley Pond V wrote:
If there are any law/license experts in the crowd, I'd love to see a
formal/named/solid version of this sort of license. It's just about
exactly what I've always wanted to put on all my own code.
Yikes.
I used to think like this -- ``my software is so awesome that people
will change their ways just to remain in compliance with the LICENSE
file''. The fact of the matter is, the real world doesn't work this
way. Your users will either ignore your license and make $MILLIONS
off your code, or they'll just rewrite your code themselves. (Look at
OpenBSD vs. GNU... every GNU utility has been rewritten just because
of bickering over licensing concerns. What. A. Waste.) Unless
you're some massive can't-get-it-elsewhere project (which really
doesn't exist these days), there's always an alternative. If your
license is too restrictive, it's just going to sit on CPAN with no
users. Who does that help?
Plus, even if you do attract users and they're non-compliant, what are
you going to do about it? Sue a megacorp in your free time? If you
do win, who's going to collect the settlement/award? You? The money
that that takes would be better spent elsewhere.
For these reasons, I mostly license things under the BSD* license.
That way people that want to contribute to Free software can easily do
so, and I don't have to worry about someone potentially ``stealing''
my ``intellectual property''. It's out there; take it.
In the end, people that want to help your software project will do it
anyway, and people that don't want to help you won't. A clever
LICENSE file isn't going to change human nature. Sorry :)
* Artistic/GPL seems more appropriate for CPAN projects, because
That's What Everyone Else Does (tm). Good enough for me.
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
Re: Delete hate speech module
David Landgren wrote:
I recommend against deleting it, because that only add fuel to the fire.
The crackpot who uploaded this drivel in the first place will be able to
crow freedom of speech and it's all a communist plot, there really is a
perl cabal and they're out to get me and blah blah blah.
So what? This guy is not contributing anything of value, and his PAUSE
ID is a generic trolling username. The CPAN is a service to authors as
much as it is to users -- if you want your code to be mirrored on 1000s
of machines worldwide, at least make it do *something*.
I would look at it this way. If a module is really useful and contains
a hateful comment here and there, I would ask the author nicely to
reconsider his choice of words, but I wouldn't delete the module from
the CPAN. Similarly, if a module is pretty much useless, but it's funny
in good taste (Acme::), then I would also never consider deleting it.
But when it's useless AND in bad taste, it's not doing anything good for
anyone, so why should the CPAN mirror it? What's the advantage for anyone?
If I were in charge, this module would be deleted and the PAUSE account
disabled. If the author would like to try again, he can register with
his real name, upload some good code, and he will be welcomed to the
community. But someone needs to draw the line saying that useless hate
speech is not what the CPAN is for. Otherwise the CPAN is going to
become slashdot without a moderation system, and people are going to
stop mirroring it.
I would also recommend writing your (*) opinion about the module by
means of reviews on cpanratings, as well as annocpan and cpan::forum.
That way a third party will understand that the module is not condoned
by the general Perl community.
This is probably exactly what the author wants. Think about how much of
everyone's time he's wasted already -- in the end, time we spend
discussing hate speech on CPAN::Forum is time that we could have spent
making our CPAN modules better.
Delete and be done with it.
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
Re: Delete hate speech module
David Landgren wrote:
Continuing as the devil's advocate, I still can't decide if that's just
a parody on the whole license issue. It's just too over the top.
That said, I agree that CPAN doesn't have to be the vector for
distributing this useless drivel. While the license gave me a big laugh,
the comments in the source code are distinctly unfunny.
In this day and age, it's not worth opening up mirror owners to lawsuits
from module authors because we think something might be a joke --
lawsuits cost you money even if you win. (Also, if this module is a
joke... it's really not all that funny. It's juvenile stupidity at best.)
It's ESPECIALLY not worth the legal risk for such a stupid and
controversial module. The license looks non-Free, the module sucks, so
deletion is a no-brainer. It's not worth the time spent guessing.
If licensing is the only reason for deleting this thing, then
delete first and allow the author to reupload with a Free license later.
CPAN has rules. Let's enforce them.
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
Re: Bindings
Darek Dwornikowski wrote:
One question, If i wont to write perl bindings for some library what
should i use ? I am thinking about bindings for rsbac.
SWIG is probably a good start, although it doesn't play well with CPAN
(it can be made to, though). Otherwise there's h2xs if you want to
write a real XS binding. Check out the manual pages for each.
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
Re: Updating a module that's included in another distro
On Saturday 25 November 2006 16:00, Andy Armstrong wrote:
Anyway, the PAUSE indexer has failed because:
status: Not indexed because Geo-Cache-0.06/lib/Geo/Gpx.pm in
R/RB/RBOW/Geo-Cache-0.06.tar.gz has a higher version
number
(0.1)
I spoke to Rich Bowen (the original author) and agreed that I'd take
over the module and release a new version - but obviously I can't
because PAUSE thinks Geo::Gpx is part of Geo::Cache. Does anyone know
what I should do? I could ask Rich to make a release of Geo::Cache
that had Geo::Gpx as a dependency rather than bundling it - does
anyone know if that'd fix it?
That would probably fix it. You should also bump the version number of your
module to 0.11, to placate the PAUSE indexer. If Geo::Cache needs an older
version of Geo::Gpx to be bundled with it, make sure the $VERSION in (the
bundled) Geo::Gpx is lower than the real CPAN version. That should prevent
future version problems.
Hope that helps.
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
Re: Modules dealing with data files
David Nicol wrote:
On 11/10/06, David Landgren [EMAIL PROTECTED] wrote:
I suppose it will default to the site_perl directory if run in batch
mode, but interactive installations allow the directory to be specified.
OS distribution maintainers may wish to override the default (how? an
environment variable à la PERL_G_F_P_PATH=/usr/local/share/doc/insee?)
A non-standard installation procedure that runs the package through
a transform while installing it, allowing the path to be written into the
installed module.
What about Module::Install and File::ShareDir? If the author is OK with
bundling the datafile with his module, this seems like the perfect way
to do things. There's really no disadvantage to bundling data with the
module, because the module won't work without the data, and the code
size is probably much less than the data size. (So it's not wasteful to
download the code with each data update.)
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
Re: Preventing PAUSE from indexing a module?
no_index:
DB: 1
WTH am I doing wrong?
It looks like Module::Install does this:
no_index:
directory:
- t
- t/lib
- foo/bar
i.e.:
YAML::Dump({no_index = {directory = [qw|t t/lib foo/bar|]}})
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
pgpezD0hMGQap.pgp
Description: PGP signature
Re: HOW-TO?
You shouldn't have to do anything other than upload your file and claim
it in the yellow box on this page:
https://pause.perl.org/pause/authenquery?ACTION=add_uri
If you upload using the blue box, then PAUSE will claim the module for
you and send you some e-mail about it. Foo::Bar has entered the CPAN
as ...
The docs are here:
https://pause.perl.org/pause/authenquery?ACTION=pause_04about
BTW, it looks like your module (Parallel-Pvm-Scheduler-0.01 ?) got
uploaded and indexed OK. You should be seeing it on search.cpan.org in
a few hours.
Thanks for your contribution to the CPAN! :)
Regards,
Jonathan Rockway
Ryan Golhar wrote:
Is there a HOW-TO for adding a module to CPAN? I recently got a PAUSE
account and uploaded a tar.gz module I created. However I'm not sure
what to do after that. I don't see a Help menu item on the PAUSE menu
so I'm not sure what to do...
Ryan
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
Re: spamming cpan? was [Fwd: Perl-Freelancer needed]
OK, I submitted it along with a note saying that this probably affected
5453 people (zcat 01mailrc.txt.gz | wc -l), which is definitely not
acceptable. If anyone else has a spamcop.net account, please submit
that message so that the offending party's ISP gets the idea that
01mailrc is not an advertising list :)
Regards,
Jonathan Rockway
Jerry Hedden wrote:
Jonathan Rockway queried:
Did anyone else get a message like this via their CPAN alias?
Yep. I did.
If this is the case, I'm going to report it to spamcop.
Great idea. Please do.
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
Re: Take back your modules!
Agreed. JFDI. It puts everyone (users, you, the real maintainer) in a tough position when you just take over someone's module without having provided any code. Maybe you want to work on it, but after you realize what that actually entails you'll become a bad maintainter too. That doesn't solve any problems. Send patches, send good bug reports. We're a community here, everyone /wants/ to help everyone else. Forget about who owns what, though, because it just doesn't matter. Regards, Jonathan Rockway Mark Stosberg wrote: Ovid wrote: Hi all, No names, but if you happen to be sitting on a module which other people depend on and you're not going to fix bugs, give up the module, offer someone co-maintainership or figure out *something* which gives users a way out. I realize that not everyone has a pile of free time to constantly upgrade and maintain modules, but if it's something widely used and you don't have time for it, isn't the responsible thing to find a way to get those bug fixes out there? I just want to point out that giving maintainership involves two consenting parties, and this a author-centric approach. The user-centric approach works too. Leave patches in RT. Follow-up on the other bug reports until you reach resolution. Leave a note in RT that says I recommend this issue be resolved because... Go ahead and prepare a next proposed release with tests/docs/code and ChangeLog updates and tell the author they can simply sign-off on it. I now help maintain Data::FormValidator, CGI::Session, CGI::Application, and WWW::Mechanize, none of which I wrote. In all cases, the existing maintainers have been appreciative of my pro-active approach. From my perspective, there aren't enough users acting like the software is theirs. Considering the licenses on CPAN, they have equal right to work on it. I'm not sure what the hang-ups are for getting users to be more active, though. I say: If you are care about a module's maintenance, start acting like you own it, being considering that others, especially the current maintainer, may feel the same way. Mark
Re: CPAN::Forum update rss feed per PAUSEID
http://www.petefreitag.com/item/381.cfm Hacks like these are ruining the Internet. RSS is application/rss+xml, period. Atom is application/atom+xml. XHTML is application/xhtml+xml. If your user agent cannot understand this, please get a user agent that has been updated in the last 10 years! If we continue to serve everything as text/tag-soup, browsers will never be fixed and this nightmare will continue indefinitely. (You wouldn't believe how much hate mail I got for serving my YAPC slides as application/xhtml+xml...) /rant That said, thanks for the RSS feeds, Gabor. They work for me :) Regards, Jonathan Rockway
Re: Give up your modules!
Isn't CPANTS down indefinitely? I guess such thing should be part of CPANTS. Gabor
Re: Give up your modules!
BTW, I have some free time to devote to maintaining modules. So, if you want to unload one, let me know. Although, for some reason I doubt that anyone who reads module-authors wants to give up their modules :) Regards, Jonathan Rockway Ovid wrote: Hi all, No names, but if you happen to be sitting on a module which other people depend on and you're not going to fix bugs, give up the module, offer someone co-maintainership or figure out *something* which gives users a way out. I realize that not everyone has a pile of free time to constantly upgrade and maintain modules, but if it's something widely used and you don't have time for it, isn't the responsible thing to find a way to get those bug fixes out there? Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Give up your modules!
Is there software that needs to be written? I could write a small Catalyst application to handle this, if someone is willing to host it. Regards, Jonathan Rockway 1. Place for current module authors/maintainers who wish to transfer maintenance of certain modules to so indicate. 2. Place for people who are willing to take over maintenance of CPAN modules to so indicate. 3. (And this is the delicate part ...) A way to encourage authors/maintainers whose code needs transfer to a new maintainer to effect that. Nothing wrong with a good-old-fashion hostile fork now and again :) But hopefully we can avoid that.
Re: Test-time dependencies.
If you use Module::Install, there's a separate option called build_requires that should do what you want. People installing from source via CPAN will have to download the build_requires, because they're building the packages, but users of pre-compiled (and tested) binary distributions won't be asked to install the modules that your test depends on. If you're not using Module::Install, though, I would include Test::Exception as a regular dependency anyway. You'll get better feedback from the CPAN testers that way, and that's probably more important than worrying about whether or not someone needs to install T::E. It's a pretty standard module; they'll need it sooner or later :) Regards, Jonathan Rockway Dmitri Tikhonov wrote: Dear fellow Perl module authors: I have a test suite for my distribution (RT-Client-REST) that requires some modules that the module itself does not require (Test::Exception, for example). Since it is not listed as a dependency, some people's tests fail[1,2]. Question: is it a good idea to put Test::Exception in as a dependency? My problem with this is that the module itself, once installed, does not use Test::Exception, so it is not really a dependency. On the other hand, I want all tests to run (most of them test exceptions), so I do not want to 'skip' any tests. Thanks for your input, - Dmitri. 1. http://www.nntp.perl.org/group/perl.cpan.testers/340611 2. http://www.nntp.perl.org/group/perl.cpan.testers/340620 signature.asc Description: OpenPGP digital signature
