I am close to giving up trying to support my Perl modules on Windows. Personally, I have nothing against it, despite all the odd quirky "not-quite-UNIX"es about it. I'm sure the same could be said in reverse, of all the "not-quite-Windows"es about the UNIXes, coming from a Windows developer.
However, I am continually annoyed at the almost complete lack of any smoke-test results ever coming from Cygwin or MSWin32 machines. I can upload a new module to CPAN and within literally hours have a dozen or so smoke-test reports from Linux and FreeBSD machines. Within a few days, a flood more results from these, and also Darwin, OpenBSD, NetBSD, Solaris. But quite often I can sit and wait weeks, if not months before I see the first result from Cygwin or MSWin32.
It's not that I'll ever actually stop looking after code - if someone were to point out a problem or send me a patch, I'm sure I could include it. It's just very hard for me as a developer without a Windows box to know if any of my code actually works on Windows, or if not, to be able to fix it. While I don't have any BSD, Solaris, or OS X boxes, I do at least have the confidence of the smoke-test reports to claim my code works there.
I must therefore conclude one of two things:
- Nobody is using Perl, or at least my Perl modules, on Windows; or
- Nobody using Perl on Windows cares about testing and code quality
I would really dislike having to declare this, because I feel sure there ought to be Windows users around who care. So perhaps someone somewhere can look into actually installing the test reporter module. It isn't hard, really...
I don't have a Windows machine so I might be wrong, but: Wouldn't a dedicated constantly-running smoke-system require a separate Windows license just for that? I'd assume that part of the problem is that a single developer is not likely to use one of his personal licenses for this, assuming he even has a spare one to begin with.
ReplyDeleteI guess the best chance of getting multiple of those test instances might be through companies using Perl on Windows.
@phaylon: It doesn't have to be a dedicated smoker. I personally don't run one. It could simply be that someone installs CPAN::Reporter, so that normal module installs send smoketest reports as part of the install process. That's what I do at home.
ReplyDeleteI'm not asking for /dedicated/ full-time smokers. Just any reports when people install modules would be good.
That could work, but still wouldn't be as immediate. I get that it would still be better than nothing though :) But a dedicated system would have the advantage that you wouldn't be dependent on a subgroup (reporters) of users of a specific module.
DeleteAnd I think it can be quite hard (or at least it was in the past) to get a single user to report things via CPAN-Reporter. Does it still require the Email interface? Does one still need to be subscribed to a mailing list? Plus it contains (and rightfully so) a privacy warning that might put off corporate developers on their office machines.
But, if an occasional CPAN-Reporter user would help, you might want to add that more prominently to the post :) Additionally, you could add a Win32 note to those modules' POD that would mostly benefit from this. Many users are often in the mindset of "trying out modules and finding one that works." If they read in a Win32 section that it might not work since you can't really test it on Win32, and point them to CPAN::Reporter (and the bugtracker), they might be more inclined to help out.
The modern CPAN reporter uses HTTP to post its reports (see metabase). It takes all of ~3 minutes to install the required modules and configure them, as a one-off.
DeleteIt might be nice to show-case that too :)
Deletealso maybe they don't use cpan/cpanp. AFAIK cpanm doesn't have a way to hook into a reporter right?
ReplyDeleteYes; that's the main reason I dislike cpanm. It doesn't feed back to developers any of that information.
DeleteYou know, mea maxima culpa. I'm going to set up a Strawberry smoke tester this week - I can't do a dedicated machine yet, but I can certainly run things at night. I just plain never thought of it.
ReplyDeleteFor what it's worth - yeah, we Windows Perl programmers do exist, and we do use CPAN. I never heard of CPAN::Reporter until right now, and never really thought about setting up testing - even though I love the smoke testers for my own CPAN modules.
So consider me duly chastised.
I work under win7
ReplyDeleteand I can run test for your module as well,
as I see we talk about
https://metacpan.org/author/PEVANS
but only at home, because at work I have a proxy,
also, CPAN::Reporter sometimes work no very good (it seems to me),
good luck, I can setup module on cygwin and on win, I'll try it
I have to say i find myself annoyed because i set up my Win32 smoker literally yesterday after telling you i would do that.
ReplyDeleteCool. More smokers are good. Lets see if it makes any difference then :)
Deleteperhaps ReactOS would be sufficient? its an open source windows clone which boots and runs some things. though perhaps the smoking would find more reactos bugs than perl
ReplyDeleteThat would be great, finding bugs in two Open Source projects at the same time. Provided someone was there to help track down the problem.
DeleteI'm a Windows user, and something of a noob with Perl on Wnidows, though; I just installed CPAN::Reporter because of your blog post. Hope it will help some small bit over time. What else can I do?
ReplyDeleteThe CPAN Testers wiki has the proper instructions on how to set up smoke testing:
Deletehttp://wiki.cpantesters.org/wiki/QuickStart
Unfortunately Smokers rely on modules which either don't pass 'make test' on Windows or don't work once they're installed. I do run a smoker on Windows from time to time, but invariably it hangs up somewhere. Could I suggest that authors also test their own modules on Windows before publishing them?
ReplyDelete> Could I suggest that authors also test their
Delete> own modules on Windows before publishing them?
And how precisely do you propose they test those? Catch 22.
Authors can't often know that modules don't work on Windows unless they are smoke-tested there. Yes there is a certain bootstrapping problem with the modules used for smoke testing initially, but once /a/ setup is working it should be nice and stable.
> And how precisely do you propose they test those?
DeleteYou test them on Windows by testing them on Windows. You can install Strawberry Perl onto Windows and test using that. If you don't have a copy of Windows, then you can download an evaluation copy from Microsoft's web site for free. The eval versions function for about 90 to 180 days depending on the product.
For example, you can get Windows 7 at http://technet.microsoft.com/en-US/evalcenter/cc442495.aspx and Windows Server 2008 R2 at http://msdn.microsoft.com/en-US/evalcenter/ee175713.aspx.
It is due to lack of knowledge. Most perl users do not know how to report test results back. For example, I have never seen an article or blog post about this.
ReplyDeleteSee the link to the CPANTesters wiki; posted above, and also in a comment below.
DeleteInstalling the CPAN::Reporter module is not enough.
ReplyDeleteYou have to enable its usage in CPAN.pm.
See the howto on the CPANTesters wiki.
Has the CPAN testing infrastructure recovered from the problems at the end of last year? cpantesters.org shows only a handful of page requests, pretty sure this used to be a much higher number at the same time last year, and there don't appear to be any results showing in the metabase log either since May:
ReplyDeletehttp://metabase.cpantesters.org/tail/log.txt
and http://www.cpantesters.org/recent.html doesn't have anything since September 2011 either.
There have also been several comments about test results going missing, http://blog.cpantesters.org/diary/148 for example - so I'm wondering if perhaps there *are* smokers running tests, but they're not getting through for some reason?
ActiveState builds all the CPAN modules for its ppm repositories.
ReplyDeleteYou can consult the build log files for the various versions of Perl here:
http://ppm4.activestate.com/MSWin32-x86/
For example, the results for your modules are in (Perl 5.14 build 1400)
http://ppm4.activestate.com/MSWin32-x86/5.14/1400/P/PE/PEVANS/
A module without .ppd file was not compiled.
In the .d directory corresponding you will find the build log as a .txt file.
I don't know if it is as detailed as the report from CPAN::Reporter but it can give you some useful informations.
I hope this helps.
This is the first I ever heard the phrase smoke testing despite using perl for decades. Seems to be quite a disconnect between the end users and the developers.
ReplyDeleteI run (currently) Strawberry Perl 5.16.1 on Windows 7 x64. I'm a casual Perl user and not a very talented developer - most of my programming is geared toward network related modules to get my job done. That said, we corresponded recently over my mistaken bug report for Socket which turned out to be a shortcoming in the C-compiler (MinGW gcc) shipped with the Strawberry distribution. This goes back as far as 5.10.x in Strawberry and up to the latest 5.16.1 release. The header (ws2tcpip.h) and library (libws2_32.a) don't provide all the required routines for IPv6 (in my case, inet_ntop() was tripping up) even though the routines are present in ws2_32.dll.
ReplyDeleteBased on our discussion https://rt.cpan.org/Public/Bug/Display.html?id=78890 last week, I created a post that explains my workaround to get full IPv6 support with Strawberry Perl on Windows http://vinsworldcom.blogspot.com/2012/08/ipv6-in-perl-on-windows_20.html.
That said, none of that really relates to your question about Windows testers. For me, I develop on Windows so I know my modules will work on Windows. I don't actually know many people - unless they're using my scripts - that use Perl on Windows. They tend more towards PowerShell now that that is an option.
Hi, since your post I've got myself a Windows VPS on which I run a smoker. Your Tickit modules 'hang' after the smoker tries to compile them. There is no way for me to test them succesfully other than issuing Ctrl+C in which case the smoker does not submit a bug report and continues with the next module from CPAN.
ReplyDeleteSo it might well be the *main* problem is something funny wrt how your modules are build on Windows. I'm not sure what the root cause is here. There are some other modules that have the same behaviour, but the vast majority simply tests.
The quality of your articles and contents is great.Kanger Subtank
ReplyDeleteThanks for sharing it but people who are using non genuine, cracked or pirated operating system, Mostly facing problems and after the bogus updates their issues may become complex. I also used windows 11 pro trail with many issues on weekly basis but when I activated it there's no more issue found. To fix it, I purchased license key from odosta store which I think is a Microsoft product reseller.
ReplyDelete