Re: Re: Making sure your module works on other OS-es as well
On Sun, Jul 03, 2011 at 12:56:56AM -0700, Serguei Trouchelle wrote: Shmuel Fomberg wrote: I'm not advocating of throwing everything before 5.12, but I think that version 5.8.9 if the earliest we should accept. I know one Fortune 50 company who runs Perl 5.8.5 in production. Happy Birthday 5.8.5 - 7 years old today! Nicholas Clark
Re: Quick and dirty guide to running Perl on Windows (was Re: Making sure your module works on other OS-es as well)
On Sat, Jul 09, 2011 at 01:03:49AM -0700, Eric Wilhelm wrote: # from David Golden On Fri, Jul 1, 2011 at 9:23 AM, David Cantrell wrote: ... the complete lack of a reasonable set of tools on Windows, which just makes me angry whenever I have to touch the blasted thing, made me stop. Definitely the lack of remote text based access makes it harder. But for anyone willing to run Windows in a virtual machine, it's not terribly hard anymore ... With a VM install, you still have to wade through the boggy experience of mousing-around in a completely foreign environment while swearing at the shell for being completely unreasonable about everything. But none of this has anything to do with whether your code works on Windows, only whether you can work within it. IMO, it would be much better to not be actually using windows (or mac for that matter) if that's not your preferred environment and you just need to debug some compatibility issue. How can I debug a problem that only happens on Windows without using Windows? Not to mention the general case of a CPAN author, where you can't assume that they could be bothered to *obtain* a windows/mac OS, let alone boot it. Some open and deployable environment / test kit would go much further than anything involving a VM and proprietary license. Adam Kennedy tried to help with this, by persuading Microsoft to make a few VMs available for perly people to use. I have no idea how successful it's been. I think the utter lack of convenience in testing for and fixing cross-OS bugs is the big barrier to getting better cross-OS support. Nobody likes coding in the dark with a hours-long latency to see if their fix works. This is why, when I can, I set up some kind of guest account on machines that I use for CPAN-testing, so that authors can debug and fix things themselves rather than rely on me to be remote hands which might have a several *week* latency. -- David Cantrell | Minister for Arbitrary Justice When one has bathed in Christ there is no need to bathe a second time -- St. Jerome, on why washing is a vile pagan practice in a letter to Heliodorus, 373 or 374 AD
Re: Quick and dirty guide to running Perl on Windows (was Re: Making sure your module works on other OS-es as well)
# from David Golden # on Saturday 02 July 2011 03:51: On Fri, Jul 1, 2011 at 9:23 AM, David Cantrell wrote: ... the complete lack of a reasonable set of tools* on Windows, which just makes me angry whenever I have to touch the blasted thing, made me stop. * starting with a useable shell and editor, documentation, and remote text-based access. ... Definitely the lack of remote text based access makes it harder. But for anyone willing to run Windows in a virtual machine, it's not terribly hard anymore. Personally, I use VirtualBox on Ubuntu with a Windows 7 guest. I suggest WinXP if you have old licenses kicking around, as it's a little less annoying about validation and such. With a VM install, you still have to wade through the boggy experience of mousing-around in a completely foreign environment while swearing at the shell for being completely unreasonable about everything. But none of this has anything to do with whether your code works on Windows, only whether you can work within it. IMO, it would be much better to not be actually using windows (or mac for that matter) if that's not your preferred environment and you just need to debug some compatibility issue. Not to mention the general case of a CPAN author, where you can't assume that they could be bothered to *obtain* a windows/mac OS, let alone boot it. Some open and deployable environment / test kit would go much further than anything involving a VM and proprietary license. I think the utter lack of convenience in testing for and fixing cross-OS bugs is the big barrier to getting better cross-OS support. Nobody likes coding in the dark with a hours-long latency to see if their fix works. I had no luck getting things to build under wine (IIRC, the trouble came with XS modules), but it's been a few years and I haven't messed with it lately. If it did work well, I'm not sure how much it would gloss over issues of command-not-found and backslashed-path errors. It seems like you could construct a pretty thoroughly windowsish environment by hiding all useful commands (e.g. rename /bin,/usr/bin) and unsetting $PATH, then make some working/temp directories with spaces in the names. That would catch most of the common problems. Not sure if you could emulate the brokenness of the backslashes on a *nix though. --Eric -- Peer's Law: The solution to the problem changes the problem. --- http://scratchcomputing.com ---
Re: Quick and dirty guide to running Perl on Windows (was Re: Making sure your module works on other OS-es as well)
Eric Wilhelm wrote: With a VM install, you still have to wade through the boggy experience of mousing-around in a completely foreign environment while swearing at the shell for being completely unreasonable about everything. I know that Norton Commander clones generally are not used anywhere outside the former Soviet Union, but you may take a look at Far Commander ( http://www.farmanager.com/download.php?l=en ) and install MSYS and MinGW (and optionally: 1. install ActivePerl, 2. Install StrawberryPerl). After that, you should have something close to your working environment, and more (thanks to Far Cmdr). It seems like you could construct a pretty thoroughly windowsish environment by hiding all useful commands (e.g. rename /bin,/usr/bin) and unsetting $PATH, then make some working/temp directories with spaces in the names. That would catch most of the common problems. Not sure if you could emulate the brokenness of the backslashes on a *nix though. Perl on Windows doesn't have any problems with straight slashes. Unless you do my $bla = `/bin/sh`; Something like open (my $FILE, '', '/Windows/TEMP/File.txt') works just fine, though I would recommend using File::Spec-cat just to be sure. P.S. Programming in Perl on the Windows as primary platform for more than 10 years. -- Serguei Trouchelle
Re: Quick and dirty guide to running Perl on Windows (was Re: Making sure your module works on other OS-es as well)
On Sat, Jul 9, 2011 at 4:03 AM, Eric Wilhelm enoba...@gmail.com wrote: Not to mention the general case of a CPAN author, where you can't assume that they could be bothered to *obtain* a windows/mac OS, let alone I think you're missing the point of my post, which was to offer a way for people to try it without a lot of hassle if they were inclined to do so but not sure how. I certainly wasn't preaching that all CPAN authors must set up Windows VMs. -- David
Re: Making sure your module works on other OS-es as well
For better or worse, the native Perl on Solaris 10 remains 5.8.4 as it was 5 years ago with Solaris 10 GA. IIRC Solaris 9 is 5.6. Lest you think nobody still runs Solaris 9 my employer does and they have a Perl application on it which is in transition to Solaris 10. Solaris 11 is I believe shipping with Perl 5.101 when it comes out RSN. I don't remember what AIX 6 has but I see to recall it was 5.8.8 Only Linux distributions ship with more recent Perl. The OpenCSW project is working hard to get a 5.12 release out. This all brings up a point about maintenance of Perl: it is one thing to not release new features in 5.10.1 it is another to say since we have already 514 we won't consider bug fix releases for 5.10.1 Bundling stuff into core and making bug fixes unavailable to older Perl is another mess. Sent from my BlackBerry® smartphone with Nextel Direct Connect -Original Message- From: Serguei Trouchelle s...@cpan.org Date: Mon, 04 Jul 2011 14:01:35 To: module-authors@perl.org Subject: Re: Making sure your module works on other OS-es as well Shmuel Fomberg wrote: Because it gives the feeling that we support them. I think that there is someone who is running a smoker on Perl 5.6. do we want authors to get error reports because some feature that they used does not exists or was buggy on that version? These reports clearly indicate that module is not supported on this particular version and platform. I don't see how 100% of FAIL/UNKNOWN reports can give someone the feeling of any support. It says the module is having problems on that platform, but we are aware of it and it will be fixed. someday It never says it. If the version does not exists, it says what are you talking about? I have never heard of that version. It never says it either. I know well-working distributions without any tests (not that I like this situation but anyway). If you don't like to support any older version, why don't you just add use 5.008009; in Makefile.PL/Build.PL, or to META.yml? It's the most correct way to tell about what's the minimum version supported, and it's really easy. I'm not advocating of throwing everything before 5.12, but I think that version 5.8.9 if the earliest we should accept. I know one Fortune 50 company who runs Perl 5.8.5 in production. I know one that uses Perl 5.6. so? So having test results for this version is helpful for those who use it. I think that most misunderstandings about CPAN Testers appear because module authors think that CPAN Testers is a tool to irritate authors, and sometimes a free auto-tester. But in fact, it's about helping users decide whether this particular distribution runs on their version/platform or not. -- Serguei Trouchelle
Re: Making sure your module works on other OS-es as well
On Mon, Jul 4, 2011 at 5:35 PM, dhu...@hudes.org wrote: This all brings up a point about maintenance of Perl: it is one thing to not release new features in 5.10.1 it is another to say since we have already 514 we won't consider bug fix releases for 5.10.1 Bundling stuff into core and making bug fixes unavailable to older Perl is another mess. I'm very sympathetic to your concern. For a long time, Perl didn't have any formal support policy. That has changed in recent years under Jesse Vincent's leadership and Perl now has a policy: http://perldoc.perl.org/perlpolicy.html#MAINTENANCE-AND-SUPPORT The fundamental issue with backporting bugs to older Perls is lack of volunteer time to do the work. As Jesse's new policy puts it, Perl 5 is developed by a community, not a corporate entity. I think one reason that Perl is generally pretty up to date on Debian-based systems is that the debian-perl group is very active and contribute regularly to the perl5-porters that maintains the Perl source. I don't really know what the story is for other OS groups. -- David
Re: Making sure your module works on other OS-es as well
On 2011/07/04 1:34, David Cantrell wrote: Likewise, if authors don't wish to be notified about reports, they can customize notification on the preferences site: https://prefs.cpantesters.org/ nice. never knew about this option before. Authors are told about it in the summary emails they receive. You know, I think that I do remember that there is some text between the Dear $author on the top of the email and the beginning of the failure report. But I have never read it, as it seen. Shmuel.
Re: Making sure your module works on other OS-es as well
Shmuel Fomberg wrote: Because it gives the feeling that we support them. I think that there is someone who is running a smoker on Perl 5.6. do we want authors to get error reports because some feature that they used does not exists or was buggy on that version? These reports clearly indicate that module is not supported on this particular version and platform. I don't see how 100% of FAIL/UNKNOWN reports can give someone the feeling of any support. It says the module is having problems on that platform, but we are aware of it and it will be fixed. someday It never says it. If the version does not exists, it says what are you talking about? I have never heard of that version. It never says it either. I know well-working distributions without any tests (not that I like this situation but anyway). If you don't like to support any older version, why don't you just add use 5.008009; in Makefile.PL/Build.PL, or to META.yml? It's the most correct way to tell about what's the minimum version supported, and it's really easy. I'm not advocating of throwing everything before 5.12, but I think that version 5.8.9 if the earliest we should accept. I know one Fortune 50 company who runs Perl 5.8.5 in production. I know one that uses Perl 5.6. so? So having test results for this version is helpful for those who use it. I think that most misunderstandings about CPAN Testers appear because module authors think that CPAN Testers is a tool to irritate authors, and sometimes a free auto-tester. But in fact, it's about helping users decide whether this particular distribution runs on their version/platform or not. -- Serguei Trouchelle
Re: Making sure your module works on other OS-es as well
John M. Gamble wrote: Just to be clear: If I have a perl requirement of, say, 5.10 in my META.yml, the smokers will skip testing with all versions of 5.6 and 5.8? Yes. NA report will be sent, no testing or even attempting to build the module will be made. What if the distribution is old and without a META.yml, but there's a require 5.6; line in the module? What happens then? NA report will be sent too. (My modules are currently 5.6 friendly, although I've been considering bumping that up to 5.10.) I think distributions like Modern::Perl ( http://search.cpan.org/dist/Modern-Perl/ ) can be a good example of how to specify a version prerequisite. -- Serguei Trouchelle
Re: Re: Making sure your module works on other OS-es as well
Shmuel Fomberg wrote: Oh, and by the way, can someone make the server reject report from ancient Perl versions? Why? Because it gives the feeling that we support them. I think that there is someone who is running a smoker on Perl 5.6. do we want authors to get error reports because some feature that they used does not exists or was buggy on that version? These reports clearly indicate that module is not supported on this particular version and platform. I don't see how 100% of FAIL/UNKNOWN reports can give someone the feeling of any support. I'm not advocating of throwing everything before 5.12, but I think that version 5.8.9 if the earliest we should accept. I know one Fortune 50 company who runs Perl 5.8.5 in production. -- Serguei Trouchelle
Re: Making sure your module works on other OS-es as well
On 2011/07/03 16:56, Serguei Trouchelle wrote: Because it gives the feeling that we support them. I think that there is someone who is running a smoker on Perl 5.6. do we want authors to get error reports because some feature that they used does not exists or was buggy on that version? These reports clearly indicate that module is not supported on this particular version and platform. I don't see how 100% of FAIL/UNKNOWN reports can give someone the feeling of any support. It says the module is having problems on that platform, but we are aware of it and it will be fixed. someday If the version does not exists, it says what are you talking about? I have never heard of that version. I'm not advocating of throwing everything before 5.12, but I think that version 5.8.9 if the earliest we should accept. I know one Fortune 50 company who runs Perl 5.8.5 in production. I know one that uses Perl 5.6. so? The point is that CPAN deprecation should lag behind Perl deprecation policy. not to go in the other direction. Shmuel.
Re: Making sure your module works on other OS-es as well
On Sun, Jul 03, 2011 at 07:42:42PM +0900, Shmuel Fomberg wrote: On 2011/07/03 16:56, Serguei Trouchelle wrote: Because it gives the feeling that we support them. I think that there is someone who is running a smoker on Perl 5.6. do we want authors to get error reports because some feature that they used does not exists or was buggy on that version? These reports clearly indicate that module is not supported on this particular version and platform. I don't see how 100% of FAIL/UNKNOWN reports can give someone the feeling of any support. It says the module is having problems on that platform, but we are aware of it and it will be fixed. someday Where does it say that? It's certainly not in any of the templates for the pages across cpantesters.org sites I've written. The only truth you can discern from those failures are that some testers had problems with the tests in their environment. It is then up to the reader to look closer and see whether it would be a problem for them. If a author chooses to ignore that version that's fine, it's their choice to support a minimum version. As you and others can witness, businesses (for whatever reason) do run older perls. The reports highlight to those people the problems they may encounter. New versions of distributions tested on older perls is still useful data to those businesses. The point is that CPAN deprecation should lag behind Perl deprecation policy. It does. Testers do upgrade over time. The oldest perl currently tested is 5.6.2, up until about 18 months ago we were still getting test reports for 5.5.x. While perl versions are still relavent in the wild, then I'm happy to see reports for them. Authors do not need to support older versions, and often the reports verify that distributions are no longer supported for a particular version of perl. As David stated, it's all just data. Cheers, Barbie. -- Birmingham Perl Mongers http://birmingham.pm.org Memoirs Of A Roadie http://barbie.missbarbell.co.uk CPAN Testers Blog http://blog.cpantesters.org YAPC Conference Surveys http://yapc-surveys.org Ark Appreciation Pages http://ark.eology.org
RE: Making sure your module works on other OS-es as well
-Original Message- From: Gabor Szabo [mailto:szab...@gmail.com] Sent: Sunday, July 03, 2011 7:33 AM To: Shmuel Fomberg Cc: module-authors@perl.org Subject: Re: Making sure your module works on other OS-es as well On Sat, Jul 2, 2011 at 6:29 PM, Shmuel Fomberg ow...@semuel.co.il wrote: Hi Gabor. Btw, related to your comment, I think that Padre run itself using wxPerl, without regarding on which Perl it is running. I've added a small patch for this a while ago, it tries to locate $our wxPerl. However there are other issues related to 64bit perl + Wx + OSX
Re: Making sure your module works on other OS-es as well
On 7/3/2011 6:40 AM, Barbie wrote: On Sun, Jul 03, 2011 at 07:42:42PM +0900, Shmuel Fomberg wrote: The point is that CPAN deprecation should lag behind Perl deprecation policy. It does. Testers do upgrade over time. The oldest perl currently tested is 5.6.2, up until about 18 months ago we were still getting test reports for 5.5.x. While perl versions are still relavent in the wild, then I'm happy to see reports for them. Authors do not need to support older versions, and often the reports verify that distributions are no longer supported for a particular version of perl. As David stated, it's all just data. Cheers, Barbie. Just to be clear: If I have a perl requirement of, say, 5.10 in my META.yml, the smokers will skip testing with all versions of 5.6 and 5.8? What if the distribution is old and without a META.yml, but there's a require 5.6; line in the module? What happens then? (My modules are currently 5.6 friendly, although I've been considering bumping that up to 5.10.) -john
Re: Making sure your module works on other OS-es as well
On Sun, Jul 03, 2011 at 08:40:02AM +0900, Shmuel Fomberg wrote: On 2011/07/03 1:02, David Cantrell wrote: Oh, and by the way, can someone make the server reject report from ancient Perl versions? Why? Because it gives the feeling that we support them. No it doesn't. It merely tells people this code works on 5.6 (or doesn't). I think that there is someone who is running a smoker on Perl 5.6. do we want authors to get error reports because some feature that they used does not exists or was buggy on that version? I don't test just for authors. I test for users too. Authors who don't care about older versions of perl can easily ignore those reports. -- David Cantrell | Minister for Arbitrary Justice In this episode, R2 and Luke weld the doors shut on their X-Wing, and Chewbacca discovers that his Ewok girlfriend is really just a Womble with its nose chopped off.
Re: Making sure your module works on other OS-es as well
On Sun, Jul 03, 2011 at 09:30:49AM +0900, Shmuel Fomberg wrote: On 2011/07/03 8:50, David Golden wrote: If authors don't want failure reports on ancient Perls, they are advised to be explicit with use 5.006 or use 5.008009 or whatever is the earliest version they choose to support. Let's file it under 'do the right thing by default'. The right thing is to not throw data away. Likewise, if authors don't wish to be notified about reports, they can customize notification on the preferences site: https://prefs.cpantesters.org/ nice. never knew about this option before. Authors are told about it in the summary emails they receive. -- David Cantrell | Cake Smuggler Extraordinaire fdisk format reinstall, doo-dah, doo-dah; fdisk format reinstall, it's the Windows way
Re: Making sure your module works on other OS-es as well
On Fri, Jul 1, 2011 at 4:23 PM, David Cantrell da...@cantrell.org.uk wrote:
On Fri, Jul 01, 2011 at 03:11:08PM +0300, Gabor Szabo wrote:
So I'd like to ask you all to check the test reports of your modules and if
you
have consistent failures of one of your modules on Windows then try to fix
them.
If you need any help, please send a message on either of those mailing list
asking people how to fix specific Windows related issues.
I went through a period of trying to make sure my code worked on
Windows, but I've given up. Not because it's hard to do - it generally
isn't - but the complete lack of a reasonable set of tools* on Windows,
which just makes me angry whenever I have to touch the blasted thing,
made me stop.
Indeed the issues I encountered were all quite simple:
1) This code in test:
`date file`
On Windows the date command waits for input so this got the test stuck.
Probably many testers just put this module in the disabled list so it
will be never tested.
2) the separator of PATH is not : on Windows so this code:
$ENV{PATH} = 'mypath' . ':' . $ENV{PATH}
is incorrect. I think the right approach is to
use Config;
$ENV{PATH} = 'mypath' . $config{} . $ENV{PATH}
3) running external perl scripts
Code like this (in a test)
`path/to/other/perl/script param param`
is not a good idea on Linux either as this will use the perl in the sh-bang
instead of the current perl which is running the tests.
These might be different version of Perl.
Besides, on Windows the above to work needs special configuration that not
all the Perl installers provide. The better approach is to write:
`$^X path/to/other/perl/script param param`
Though I really prefer
qx{$^X path/to/other/perl/script param param}
Thank you for you consideration of the other 80% of people who are
still using Windows.
regards
Gabor
Re: Making sure your module works on other OS-es as well
On Sat, Jul 02, 2011 at 10:24:33AM +0300, Gabor Szabo wrote: On Fri, Jul 1, 2011 at 4:23 PM, David Cantrell da...@cantrell.org.uk wrote: I went through a period of trying to make sure my code worked on Windows, but I've given up. Not because it's hard to do - it generally isn't - but the complete lack of a reasonable set of tools* on Windows, which just makes me angry whenever I have to touch the blasted thing, made me stop. Indeed the issues I encountered were all quite simple: Thank you for you consideration of the other 80% of people who are still using Windows. Gabor, Dave is volunteering his code. That's such a nice way of you to treat volunteers. Would you prefer it that he didn't even upload it to CPAN? Would you prefer it if he remove the important offer [*that you edited out*] that he's happy to accept competent patches from anyone who makes his code woke on Windows? Because you're going the right way about it to get either of those two results. I appreciate what you want. I'd also want what you ultimately want. But you're going the *wrong way* about getting it. Nicholas Clark
Re: Making sure your module works on other OS-es as well
Lovely, so now instead of talking about how to make sure our modules work on other OS-es we are going to discuss how Gabor is offending Dave? I wrote a lengthy response pointing out various things but I think I'd rather just apologize. Dave, I am sorry I did not mean to offend you. Keep up the good work. Actually, according to the matrix http://matrix.cpantesters.org/?author=dcantrell most of your modules have success test reports from Windows. Everyone, I hope we can now get back and see how we can mutually help each other to make it easy for all of us to have our modules support a wider range of operating systems. regards Gabor
Quick and dirty guide to running Perl on Windows (was Re: Making sure your module works on other OS-es as well)
On Fri, Jul 1, 2011 at 9:23 AM, David Cantrell da...@cantrell.org.uk wrote: I went through a period of trying to make sure my code worked on Windows, but I've given up. Not because it's hard to do - it generally isn't - but the complete lack of a reasonable set of tools* on Windows, which just makes me angry whenever I have to touch the blasted thing, made me stop. * starting with a useable shell and editor, documentation, and remote text-based access. No doubt it doesn't help that I have no need for Windows, either personally or professionally, so have no motivation to put the effort into learning it. Definitely the lack of remote text based access makes it harder. But for anyone willing to run Windows in a virtual machine, it's not terribly hard anymore. Personally, I use VirtualBox on Ubuntu with a Windows 7 guest. I suggest WinXP if you have old licenses kicking around, as it's a little less annoying about validation and such. Gabor has made it really easy to get Padre and Strawberry Perl together: http://padre.perlide.org/download.html I also note that gvim runs wonderfully on Windows: http://www.vim.org/download.php#pc -- if you prefer that over Padre, then you only need to install Strawberry Perl: http://strawberryperl.com/ When I was working on Windows regularly, the regular cmd.exe shell worked well enough once I added a bunch of ported gnu programs to my path: http://unxutils.sourceforge.net/ -- that let me keep typing ls, cp, mv etc. IMPORTANT -- be sure to rename/delete all of the tar/zip programs because they are buggy and you don't want your CPAN config finding them. You also need to rename any that conflict with windows programs (I seem to recall find I renamed to myfind or something like that.) If you use git for source control and want to use it to get your code onto the windows box, I recommend using TortoiseGit: http://code.google.com/p/tortoisegit/ Best of luck! -- David
Re: Making sure your module works on other OS-es as well
Hi Gabor. some of you might know that Perl is quite underrepresented in the Windows world. So although my main OS is Linux I thought giving a hand there might be interesting. Therefore recently I started to run a CPAN smoker http://www.cpantesters.org/ on a Windows XP machine running Strawberry Perl 5.12.3. I think that we need another column in the matrix for Strewberry Perl / MingW based Perl. We already have one for cygwin and one for Win32 that I think means MSVC6 / ActiveState. All these are different tool-chains. Oh, and by the way, can someone make the server reject report from ancient Perl versions? Shmuel.
Re: Making sure your module works on other OS-es as well
Hi Gabor. 3) running external perl scripts Code like this (in a test) `path/to/other/perl/script param param` is not a good idea on Linux either as this will use the perl in the sh-bang instead of the current perl which is running the tests. These might be different version of Perl. Btw, related to your comment, I think that Padre run itself using wxPerl, without regarding on which Perl it is running. So it I have two Perl versions installed, and both of them have Wx, and tries to run padre as perl5.xx.x padre.pl, it will actually run on whatever Perl that was installed last instead. Shmuel.
Re: Making sure your module works on other OS-es as well
On Sat, Jul 02, 2011 at 12:17:23PM +0300, Gabor Szabo wrote: I am sorry I did not mean to offend you. Don't worry, you didn't :-) However ... Thank you for you consideration of the other 80% of people who are still using Windows. I would expect that well over 95% of people who even consider using my code are already on a Unixy platform. And I certainly wouldn't expect any of them to be deploying anything non-trivial using perl on Windows. Perl just doesn't fit well into a .net world. -- David Cantrell | http://www.cantrell.org.uk/david There's no problem so complex that it can't be solved by killing everyone even remotely associated with it
Re: Making sure your module works on other OS-es as well
On Sun, Jul 03, 2011 at 12:13:19AM +0900, Shmuel Fomberg wrote: Oh, and by the way, can someone make the server reject report from ancient Perl versions? Why? -- David Cantrell | Bourgeois reactionary pig Perl: the only language that makes Welsh look acceptable
Re: Making sure your module works on other OS-es as well
On 2011/07/03 1:02, David Cantrell wrote: Oh, and by the way, can someone make the server reject report from ancient Perl versions? Why? Because it gives the feeling that we support them. I think that there is someone who is running a smoker on Perl 5.6. do we want authors to get error reports because some feature that they used does not exists or was buggy on that version? I'm not advocating of throwing everything before 5.12, but I think that version 5.8.9 if the earliest we should accept. Shmuel.
Re: Making sure your module works on other OS-es as well
On Sat, Jul 2, 2011 at 7:40 PM, Shmuel Fomberg ow...@semuel.co.il wrote: On 2011/07/03 1:02, David Cantrell wrote: Oh, and by the way, can someone make the server reject report from ancient Perl versions? Why? Because it gives the feeling that we support them. I think that there is someone who is running a smoker on Perl 5.6. do we want authors to get error reports because some feature that they used does not exists or was buggy on that version? I'm not advocating of throwing everything before 5.12, but I think that version 5.8.9 if the earliest we should accept. This meme comes up in some variety or another a few times a year. Let me respond before the bikeshedding gets too advanced. CPAN Testers reports are just data, they aren't being curated in any way. If authors don't want failure reports on ancient Perls, they are advised to be explicit with use 5.006 or use 5.008009 or whatever is the earliest version they choose to support. Likewise, if authors don't wish to be notified about reports, they can customize notification on the preferences site: https://prefs.cpantesters.org/ -- David Golden
Re: Making sure your module works on other OS-es as well
On 2011/07/03 8:50, David Golden wrote: If authors don't want failure reports on ancient Perls, they are advised to be explicit with use 5.006 or use 5.008009 or whatever is the earliest version they choose to support. Let's file it under 'do the right thing by default'. Of course an author can specify which version he supports. but by blocking old version he won't have to. Likewise, if authors don't wish to be notified about reports, they can customize notification on the preferences site: https://prefs.cpantesters.org/ nice. never knew about this option before. Shmuel.
Re: Making sure your module works on other OS-es as well
On Sun, Jul 3, 2011 at 3:30 AM, Shmuel Fomberg ow...@semuel.co.il wrote: On 2011/07/03 8:50, David Golden wrote: If authors don't want failure reports on ancient Perls, they are advised to be explicit with use 5.006 or use 5.008009 or whatever is the earliest version they choose to support. Let's file it under 'do the right thing by default'. Of course an author can specify which version he supports. but by blocking old version he won't have to. That would require a central authority to decide what is the right thing instead of just providing data an letting the module author and the user to decide. I know you know there are companies still using 5.6.x... The distro count in http://pass.cpantesters.org/ might give a better indication on which version of perl is supported by CPAN distribution. Though maybe it would be better to default to only show the production releases of perl and maybe also to include %-ages and/or a graph. It shows that 11,356 have PASS-ing reports on 5.6.1 5.10 has the biggest number that is 21,360. regards Gabor
Re: Making sure your module works on other OS-es as well
On Sat, Jul 2, 2011 at 6:29 PM, Shmuel Fomberg ow...@semuel.co.il wrote: Hi Gabor. 3) running external perl scripts Code like this (in a test) `path/to/other/perl/script param param` is not a good idea on Linux either as this will use the perl in the sh-bang instead of the current perl which is running the tests. These might be different version of Perl. Btw, related to your comment, I think that Padre run itself using wxPerl, without regarding on which Perl it is running. So it I have two Perl versions installed, and both of them have Wx, and tries to run padre as perl5.xx.x padre.pl, it will actually run on whatever Perl that was installed last instead. If I am not mistaken you are running on Mac OSX. I know there is some special casing for that in our code but I don't have a Mac to try it. As I mentioned on other channels Mark Dootson might be the best person to talk to regarding this as he is familiar with Mac and is also a Padre developer. In any case I'd appreciate if we could handle bug reports on the #padre IRC channel or on the padre-dev mailing list. See them here: http://padre.perlide.org/contact.html Regards Gabor
Re: Making sure your module works on other OS-es as well
On Fri, Jul 01, 2011 at 03:11:08PM +0300, Gabor Szabo wrote: So I'd like to ask you all to check the test reports of your modules and if you have consistent failures of one of your modules on Windows then try to fix them. If you need any help, please send a message on either of those mailing list asking people how to fix specific Windows related issues. I went through a period of trying to make sure my code worked on Windows, but I've given up. Not because it's hard to do - it generally isn't - but the complete lack of a reasonable set of tools* on Windows, which just makes me angry whenever I have to touch the blasted thing, made me stop. * starting with a useable shell and editor, documentation, and remote text-based access. No doubt it doesn't help that I have no need for Windows, either personally or professionally, so have no motivation to put the effort into learning it. I am, of course, happy to accept patches, provided that they are adequately documented and have tests, on the understanding that I can't run Windows tests, and may therefore accidentally break them again in the future. -- David Cantrell | semi-evolved ape-thing [OS X] appeals to me as a monk, a user, a compiler-of-apps, a sometime coder, and an easily amused primate with a penchant for those that are pretty, colorful, and make nice noises. -- Dan Birchall, in The Monastery
