Re: testers.cpan.org out of sync with search.cpan.org?
Leon Brocard [EMAIL PROTECTED] wrote: Usually this clears up in about a day, but in some cases it's been 3 or 4 days now and search.cpan.org is telling me that tests have run, but testers.cpan.org doesn't seem to know anything about them. Sorry, I'll prod testers.cpan.org again. Give it a while to sync up. Awesome, thanks! Is the code that drives testers.cpan.org open source? I'd really like to learn more about it. Cheers, Tyler
Re: YAML and Makefile.PL (was various topics)
A. Pagaltzis wrote: * Adam Kennedy [EMAIL PROTECTED] [2006-01-31 07:50]: There isn't really any very good way (that I can see at least) to ensure that an end-user gets an update to EUMM/MB, just the module packager. So maybe that is the fundamental problem that should be addressed? Regards, It comes down to dependencies being an at least rule. As long as the CPAN installer can skip over already-met deps, you get the problem in one way or another. And for sanity reasons, we WANT (nay HAVE) to have it that way. Solutions that can be implement without either betting incredibly aggressive to users, putting MB or CPANPLUS into the core, or going down the bundled route, would be interesting to hear though. Adam K
Re: YAML and Makefile.PL (was various topics)
A. Pagaltzis wrote: * chromatic [EMAIL PROTECTED] [2006-01-31 08:20]: Perhaps CPAN/CPANPLUS should check for updates? Maybe just add EUMM+MB to Bundle::CPAN? (Does CPANPLUS have an equivalent?) Regards, But then how are you going to make Bundle::CPAN trigger when there's a critical failure, without requiring the user to be smart? These things tend to cascade. The obvious solution results in a daisy chain of things you need to change. Adam K
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
brian d foy wrote: [EMAIL PROTECTED] wrote: Hopefully it will be something like: $I::don't::bother::to::write::portable::code=1; ;-) Seriously though, I would expect things in Win32::* to only work on Windows, things in Linux::* only to work on linux, and so on for many other sections (including Mac::* where I have some modules). Portable code isn't always the goal. I want my code to be more like File::Spec, which provides a common interface to a load of platform-specific modules. That has very good coverage of bizarro OSes, and I think we'd all agree that it's an excellent example of a nice portable module. It doesn't work on RISC OS though. -- David Cantrell
Re: What am I doing wrong? (Perl, UTF-8 and cyrillic)
Hello again, If I use this: use open ':encoding(UTF-8)'; in my script, it crashes and makes a big fat core dump. :-( I think it is up to me to figure out the problem now, but if you have any suggestions, I'll be glad to hear them. Unfortunately, because this is not a high priority project I can work on it only for half and hour daily - that's the reason I'm replying so slow. Thanks, - Alex
Re: YAML and Makefile.PL (was various topics)
On Jan 31, 2006, at 2:30 AM, Adam Kennedy wrote: Solutions that can be implement without either betting incredibly aggressive to users, putting MB or CPANPLUS into the core, or going down the bundled route, would be interesting to hear though. If I've read the perl5-porter summaries correctly, M::B just entered core in 5.9.3. There has long been hope that M::B and CPANPLUS will be in core for 5.10. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: YAML and Makefile.PL (was various topics)
On Jan 31, 2006, at 2:32 AM, Adam Kennedy wrote: But then how are you going to make Bundle::CPAN trigger when there's a critical failure, without requiring the user to be smart? CPAN.pm and CPANPLUS.pm already check their own version against CPAN on every run. All we'd need to do is have Andreas or Jos increment the CPAN.pm/CPANPLUS.pm version and just about everyone would be prompted to upgrade the next time they tried to install something. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
TODO test paradox: better TODO test management?
Here's my test-first TODO test management paradox: If I write a failing test and share it through the central repo, the smoke bot fails and keeps sending us e-mail until it is fixed, which can be annoying when these are un-implemented features and not bugs. The effect can be quit paying attention to the smoke bot. If I mark the test TODO, the smokebot succeeds and the test disappears from the radar of tests that should be fixed soon. What's a good way to manage TODO tests so that they continue to be noticed and worked on, but without being annoying? Partly I wish that the reporting tools provided more detail about TODO tests. Rather than just telling me that X TODO tests passed, I'd like to know exactly what they were and where they were located so I can go work on them. I also realize I have another class of TODO tests, it's the: Ill-get-to-it-eventually,-maybe-next-year class of TODO tests. These are things that I've noted I'd like to have an automated test for, but the tests are long term because they are expensive, difficult to setup, or well, I'm imperfect. Maybe being able to add a due date to tests would help. :) The TODO tests would pass before the due date, but if they aren't addressed in flow of work, they start failing to bring attention to themselves. And then there could be a snooze button too... Mark
Re: TODO test paradox: better TODO test management?
On 1/31/06, Mark Stosberg [EMAIL PROTECTED] wrote: Here's my test-first TODO test management paradox: If I write a failing test and share it through the central repo, the smoke bot fails and keeps sending us e-mail until it is fixed, which can be annoying when these are un-implemented features and not bugs. The effect can be quit paying attention to the smoke bot. If I mark the test TODO, the smokebot succeeds and the test disappears from the radar of tests that should be fixed soon. What's a good way to manage TODO tests so that they continue to be noticed and worked on, but without being annoying? Partly I wish that the reporting tools provided more detail about TODO tests. Rather than just telling me that X TODO tests passed, I'd like to know exactly what they were and where they were located so I can go work on them. I also realize I have another class of TODO tests, it's the: Ill-get-to-it-eventually,-maybe-next-year class of TODO tests. These are things that I've noted I'd like to have an automated test for, but the tests are long term because they are expensive, difficult to setup, or well, I'm imperfect. Maybe being able to add a due date to tests would help. :) The TODO tests would pass before the due date, but if they aren't addressed in flow of work, they start failing to bring attention to themselves. And then there could be a snooze button too... While only indirectly related. Lately when ive built blead I see stuff like 10 TODO tests unexpectedly passed! So far ive not found a way to make harness tell me which they are... So i too would like a report of TODO tests, both those passing and those failing. yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: TODO test paradox: better TODO test management?
On Jan 31, 2006, at 10:40 AM, demerphq wrote: While only indirectly related. Lately when ive built blead I see stuff like 10 TODO tests unexpectedly passed! So far ive not found a way to make harness tell me which they are... So i too would like a report of TODO tests, both those passing and those failing. You could try: make test verbose=1 out and then search the output for TODO Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: TODO test paradox: better TODO test management?
On 1/31/06, Chris Dolan [EMAIL PROTECTED] wrote: On Jan 31, 2006, at 10:40 AM, demerphq wrote: While only indirectly related. Lately when ive built blead I see stuff like 10 TODO tests unexpectedly passed! So far ive not found a way to make harness tell me which they are... So i too would like a report of TODO tests, both those passing and those failing. You could try: make test verbose=1 out and then search the output for TODO Harness should provide better info. Todo tests are important. If they unexpectedly succeed IMO they should be treated as if a test failed. Until the author agrees that a todo test should be passing it doing so should be a bug. And the way the author should show her agreement is to change it so it isn't a TODO anymore. cheers, yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: What am I doing wrong? (Perl, UTF-8 and cyrillic)
Moin Alex, On Tuesday 31 January 2006 02:56, [EMAIL PROTECTED] wrote: Hello again, If I use this: use open ':encoding(UTF-8)'; in my script, it crashes and makes a big fat core dump. :-( Please trim this down to a minimal (!) example, and then send a bug report via perlbug. (You did not say what Perl version you were using, if in doubt, maybe you can upgrade it first. Coredumps are fixed often in minor Perl versions) I think it is up to me to figure out the problem now, but if you have any suggestions, I'll be glad to hear them. Unfortunately, because this is not a high priority project I can work on it only for half and hour daily - that's the reason I'm replying so slow. No problem we try to help, we will likely need more data from you. Best wishes, Tels -- Signed on Tue Jan 31 18:23:15 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. Given enough time, all legal battles in the tech industry will invoke the DMCA. This generally means that all constructive arguments have ended. NialScorva's law pgpaebKVwk3EF.pgp Description: PGP signature
Re: YAML and Makefile.PL (was various topics)
Moin, On Tuesday 31 January 2006 06:50, chromatic wrote: On Monday 30 January 2006 20:40, Adam Kennedy wrote: Incremental releasing is a toolchain problem. [snip a good comparisation] I don't say this often, but that really doesn't seem scalable to me. If I have to re-release a distribution because of a bug in the build system that users can't upgrade on their own, the build system sucks for my purposes. And now you understand why I am angry that users updating their YAML to the newest version couldn't install my modules because YAML changed and I had to release new versions of all of them (or tell the users to downgrade their YAML, or wait for a new YAML and then upgrade it). I can mitigate this by not using YAML. So I could use Module:Install instead and find myself in the very same boat - I have to hope that the bundled version of Module::Install will work on whatever system the user has. (I think it will, but so I though YAML will :-D Now, I know Module::Install is an outstanding piece of work, and while it does have the bundling issue, it should also be noted that the other two options aren't much better as my YAML problem (and the Module::Build dependency) show. You basically have to hope that the user's system has the tools to install your module. At the end of the day, it comes down to who has the work, and the ability to fix this. If my users can fix things on their end, it removes the dependency on my (and my free time and energy). If I can fix things for them, it removes the dependency on their time and energy. I see myself as a solution provider, and I want my modules as small, lean, correct and easy to use as possible. If I can save 5 minutes, but create a bigger download/workload/system requirements for all my users, well, I would not do that. So, it comes down to find a compromise. If I spend all day long arguing install methodologies and fiddle with my Makefile.PLs, I am not writing code. So less talk and more code from me :) Best wishes, Tels -- Signed on Tue Jan 31 18:24:56 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. Let's say there are a thousand. But there are 284 million people in this country. You can't have public policy that is aimed at 100,000 people when the other multi-multi-millions are also involved. You can't do it that way. - Jack Valenty in http://tinyurl.com/2y65n pgpLruH7EFNsa.pgp Description: PGP signature
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
Moin, On Tuesday 31 January 2006 00:37, demerphq wrote: On 1/30/06, David Cantrell [EMAIL PROTECTED] wrote: demerphq wrote: On 1/30/06, David Cantrell [EMAIL PROTECTED] [snip] Sorry, i guess my comment was in bad taste. I was just alluding to observations made in the p5p lists and elsewhere that basing file system behaviour on the OS isnt entirely safe, and even expecting the same semantics in the a tree could be unsafe. Like when part of it is an mounted CD-ROM (Hint: ROM :) Best wishes, Tels -- Signed on Tue Jan 31 18:19:52 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. Nuclear powered vacuum cleaners will probably be ready within 10 years. Alex Lewyt, of the Lewyt Corporation, a vacuum maker, predicted in The New York Times on June 10, 1955 -- A warning to all technophiles pgpJGfLUsLur0.pgp Description: PGP signature
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
On Mon, Jan 30, 2006 at 08:59:58AM -0500, David Golden wrote: Well, the more generalized problem is how to you signal to an automated test that you're bailing out as N/A for whatever reason? For Perl itself, it's easy enough for the smoke test to check if the required version of Perl is available -- and the smoke test is smart enough not to try to install an updated version of Perl to satisfy the dependency. It bails out with N/A instead. What's a clean, generic mechanism for a distribution to signal please check this dependency and abort if it's not satisfied? Something in the META.yml (e.g. Alien::*)? Send a specific string to STDERR? Send a specific exit codes? Ugh. Other ideas? For CPANPLUS (and thus YACSmoke) the distribution author can check the OS from a list of known compatible OSs, and if it doesn't find it, bail out with a OS unsupported message. See this slide [1] for a simple example. [1] http://birmingham.pm.org/talks/barbie/cpan-ready/slide603.html This has been in CPANPLUS for a while now. While the obvious distributions of Win32:: and Linux:: may be OS specific, there are others that are not so obvious from the name, which may support a number of OSs, or might not support specific ones. The above exit mechanism provides an NA report to the CPAN testers. Barbie.
bug with Test::Exception? or imacat's autotest box?
Take a look at this output: http://www.nntp.perl.org/group/perl.cpan.testers/285112 It looks like this particular system is not noticing that Test::Exception requires Sub::Uplevel, then gets confused thinking it was *my* module that needed Sub::Uplevel. What's even more concerning is the presence of line noise right after the make test FAILED... Any idea what can be going on here? Thanks, Tyler
Re: TODO test paradox: better TODO test management?
* chromatic [EMAIL PROTECTED] [2006-01-31 19:40]: Write your own. perldoc Test::Harness::Straps or see the examples in chapter 3 of the Perl Testing book: That’s not a long-term answer though, is it? I agree with Yves here, this is stuff that needs to be useful by default. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: bug with Test::Exception? or imacat's autotest box?
Fergal Daly [EMAIL PROTECTED] wrote: I have a fail against a module for exactly the same reason. I initially blamed Module::Build but they convinced me it was Imacat's setup. Apparently the output looks like an old version of something or other. http://rt.cpan.org/NoAuth/Bug.html?id=15034 has details. Imacat didn't respond to my email at the time, That sucks. :-( If imacat's box has gone AWOL, is there anything cpan testers can do to flag it as such? At least until his/her attention is grabbed and the problem is addressed? Thanks, Tyler
Re: TODO test paradox: better TODO test management?
On Tuesday 31 January 2006 11:44, A. Pagaltzis wrote: * chromatic [EMAIL PROTECTED] [2006-01-31 19:40]: Write your own. perldoc Test::Harness::Straps or see the examples in chapter 3 of the Perl Testing book: That’s not a long-term answer though, is it? Why not? You know more about your application and your team and your requirements than Test::Harness does. There's also always verbose mode and grep, if the default summary is too simple. -- c
Re: TODO test paradox: better TODO test management?
* chromatic [EMAIL PROTECTED] [2006-01-31 20:55]: You know more about your application and your team and your requirements than Test::Harness does. I don’t see “unexpectedly successful TODO tests should be treated like other failures” as particularly application-specific. There's also always verbose mode and grep, if the default summary is too simple. I definitely want to be notified automatically of passing TODO tests, and apparently at least three others care enough to post about it on this list. Conversely, I’m pretty sure that of those who don’t *want* it, most simply don’t care, and if this were a default, very few would actually want to turn this behaviour off. All things considered, this seems like a prime candidate for default behaviour. That’s why I don’t think punting to let- everyone-roll-their-own is a long-term solution for this one. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: TODO test paradox: better TODO test management?
On Tuesday 31 January 2006 12:22, A. Pagaltzis wrote: I definitely want to be notified automatically of passing TODO tests, and apparently at least three others care enough to post about it on this list. Conversely, I’m pretty sure that of those who don’t *want* it, most simply don’t care, and if this were a default, very few would actually want to turn this behaviour off. All things considered, this seems like a prime candidate for default behaviour. That’s why I don’t think punting to let- everyone-roll-their-own is a long-term solution for this one. Whose default behavior though? Improving prove to show more diagnostics makes a lot of sense to me. It's a developer tool. I've long wanted better failure reporting. Adding more information to the default Test::Harness summary doesn't make sense to me. It's a user tool. It's important to list failures there, as the code might not work right, but unexpected successes? I don't want to have to explain those or the implications; I'm not sure it's useful information for most users. I still think not enough people write their own harnesses, by the way. -- c
Re: TODO test paradox: better TODO test management?
* chromatic [EMAIL PROTECTED] [2006-01-31 21:40]: Improving prove to show more diagnostics makes a lot of sense to me. It's a developer tool. I've long wanted better failure reporting. Adding more information to the default Test::Harness summary doesn't make sense to me. It's a user tool. Hmm. That’s a good point. Maybe the way to approach this would be to include a default harness for use by developer tools, which would include more chattiness about passing TODO tests. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
OK, speaking of Kwalitee, I saw cpants for the first time today. And saw that it claims to update every sunday, but there hasn't been an update since december 5th. I also saw this interesting .pm file that appeared to have an anonymous hash of every tarball in CPAN in it, all on one line. That nearly crashed my browser. :-) What's up with CPANTS? Is it a defunct project? - Tyler
Re: bug with Test::Exception? or imacat's autotest box?
I have a fail against a module for exactly the same reason. I initially blamed Module::Build but they convinced me it was Imacat's setup. Apparently the output looks like an old version of something or other. http://rt.cpan.org/NoAuth/Bug.html?id=15034 has details. Imacat didn't respond to my email at the time, F On 1/31/06, Tyler MacDonald [EMAIL PROTECTED] wrote: Take a look at this output: http://www.nntp.perl.org/group/perl.cpan.testers/285112 It looks like this particular system is not noticing that Test::Exception requires Sub::Uplevel, then gets confused thinking it was *my* module that needed Sub::Uplevel. What's even more concerning is the presence of line noise right after the make test FAILED... Any idea what can be going on here? Thanks, Tyler
Re: YAML and Makefile.PL (was various topics)
In article [EMAIL PROTECTED], Adam Kennedy [EMAIL PROTECTED] wrote: The big advantage I see here is it's not you doing the work, it's everybody else. I generally don't have too much of a problem doing incrementals... cd trunk/Module-Name ppichangeversion 0.14 0.15 perl ../../tools/build_cpan.pl --install --commit --upload Module-Name Incremental releasing is a toolchain problem. You can automate the thing down to a single command if you care enough. (even if it's a bit at a time) And aren't you writing Module::Release or something to do exactly that? Module::Release does do all of that, but that doesn't mean I let it blindly do its thing or that I want to upload 50 new dists to CPAN when none of them change anything in the real code.
Re: TODO test paradox: better TODO test management?
On Tuesday 31 January 2006 13:31, A. Pagaltzis wrote: Hmm. That’s a good point. Maybe the way to approach this would be to include a default harness for use by developer tools, which would include more chattiness about passing TODO tests. My perfect developer tool would complain noisily about failing tests (and give all of the diagnostic information for me to debug them), highlight bonus tests (and give the diagnostic information for me to promote them), and summarize everything else. If it passes, increment the counter but don't tell me. How would that work for you? -- c
Re: bug with Test::Exception? or imacat's autotest box?
imacat [EMAIL PROTECTED] wrote: That sucks. :-( If imacat's box has gone AWOL, is there anything cpan testers can do to flag it as such? At least until his/her attention is grabbed and the problem is addressed? I'll look into it and return ASAP. It's Chinese New Year here, so give me a break and allow some delay, OK? You could write to me again if I do not return for some certain period. I wouldn't have suggested that unless fergal had indicated that it was a long-standing issue. Now that I know you're aware of the problem and looking into it, I thank you and will patiently await your reply. :) Happy year of the dog! - Tyler
Re: TODO test paradox: better TODO test management?
* chromatic [EMAIL PROTECTED] [2006-01-31 22:50]: How would that work for you? Sounds exactly like things should be. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: bug with Test::Exception? or imacat's autotest box?
Tyler MacDonald wrote: Take a look at this output: http://www.nntp.perl.org/group/perl.cpan.testers/285112 It looks like this particular system is not noticing that Test::Exception requires Sub::Uplevel, then gets confused thinking it was *my* module that needed Sub::Uplevel. What's even more concerning is the presence of line noise right after the make test FAILED... Any idea what can be going on here? CPANPLUS sent the report to your module because its tests failed, because it uses Test::Exception which uses Sub::Uplevel which wasn't available during the test phase. The reason why Sub::Uplevel is missing may come from a problem in IMACAT's box, or maybe not. Details are missing because of the still present interaction problem between CPANPLUS and Module::Build. What you call line noise is most probably File not found in Chinese or Taiwanese. The best thing is to ask IMACAT to send you a more detailed report. Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO
Re: bug with Test::Exception? or imacat's autotest box?
On Tue, 31 Jan 2006, Tyler MacDonald wrote: Take a look at this output: http://www.nntp.perl.org/group/perl.cpan.testers/285112 It looks like this particular system is not noticing that Test::Exception requires Sub::Uplevel, then gets confused thinking it was *my* module that needed Sub::Uplevel. What's even more concerning is the presence of line noise right after the make test FAILED... Any idea what can be going on here? It's a NLS error message. In Big 5, it says. 'This file or directory does not exist.' -- Greg MathesonVent the Pent. --Samuel Beckett
Re: bug with Test::Exception? or imacat's autotest box?
Greg Matheson [EMAIL PROTECTED] wrote: On Tue, 31 Jan 2006, Tyler MacDonald wrote: Take a look at this output: http://www.nntp.perl.org/group/perl.cpan.testers/285112 It looks like this particular system is not noticing that Test::Exception requires Sub::Uplevel, then gets confused thinking it was *my* module that needed Sub::Uplevel. What's even more concerning is the presence of line noise right after the make test FAILED... Any idea what can be going on here? It's a NLS error message. In Big 5, it says. 'This file or directory does not exist.' Ahh, in my firefox it looked like a bunch of copyright symbols and squiggly lines. Guess I've got a few fonts to install. :) The weird thing is, on most chinese language webpages, I get little squares with the 2-byte hex code for the appropriate character written inside... - Tyler
