use Perl

The fact that so many other languages get it wrong does not excuse us for getting it worse.

It *does* mean we have an opportunity, *if* we can get it right. And, given CPAN, we *can* get it right. All we need to do is send the right patch to the core maintainers, and convince them it's right. Alternatively, we could produce a module, and convince them to have the normal build process include that in a location that will normally get loaded in as core (maybe as sort of a 'usecorecustomize'ish type thing.)

The ideal solution would not only tell them it's not apparently installed, it would optionally probe using a local system tool like mlocate to see if it's merely installed elsewhere, and it would optionally prompt them to go to CPAN to get it.

Not really. As part of the splinter group "GUIs should be useless, because I dislike needing to use them" crowd, I feel I understand enough of what the "GUIs are useless" crowd thinks to confidently state, this would, at best, tell them y'all are finally concerned with *some* of the right things, but you still have a long way to come.

However, they'd more likely skim, and come away with the overall impression that GUIs are bad and prone to flicker - nothing they didn't already know.

I think you've handled part of the issue very well. For all I know, you've already handled the other part that this post suggests exists. However, some of your post suggests otherwise.

Here, you're focused on what happens to refresh requests while Padre is in the process of changing data that will inappropriately show if that refresh request is immediately honored.

What about what happens to a refresh request to something that has not changed? For example, we get a global refresh request, and the file window contents haven't changed - do we re-render the whole window? Or do we see that nothing's changed, so leave it alone/send a cached image?

I think I've previously worked with editors that did mostly what you've described here which, at the end of an extended update, would occasionally flicker some of the frames a few times, as there were multiple refresh requests during the freeze portion. Can that happen here? If so, is there any simple code that could be used to block it? (It sounds like there could be that code in what you've described, but without diving into the code and studying it for days, I couldn't tell for certain.)

1. Thanks for the pointer on Devel::Eval. For those of us developing under rocks, that will come in very useful (as those extra bits aren't around in 5.6.1.)

2. Thanks for the info on those extra bits, as that'll be useful for my home development. I'm attempting to stay away from string evals, but they're so useful, I don't know how long I can hold out.

3. Thanks for the suggestion on how to sneak in a few more automated regression tests under a manager who doesn't want to "waste" time on them.

I think Alias addressed most of my would-be response, so I'll limit my comments to:

All of the efforts I've personally seen to turn unit tests into benchmarks ended up being more of a benchmark of perl's compiler than anything else.  Unit tests tend to focus on tiny portions of the overall code, and test just them; they tend to not do unnecessary looping.  As such, the naive 'turn them into benchmarks' puts the loop around them, and unfortunately either re-evals them, or re-forks and evals them.

One would be better off turning ones functional tests into benchmarks - on average (at least for me) they test a larger portion of the code per script, but tend to not be as complex, proportionately speaking.  Some of my functional tests have even been distilled down to the point of "Directory A contains a bunch of input files, directory B contains files with the same names which are their corresponding output files.  See if they generate the right output."  When that's running against a persistent process, it can be looped without too much worry.

Of course, the real benchmark is probably more like, "Directory A contains a bunch of input files; each one corresponds to a real session with its data munged to eliminate personal details.  Each session file resets its state at the end.  Directory B contains the expected output for each of these sessions.  Run them all at the same time, repeatedly."

Just in case I'm misinterpreting that output, it looks to me very much like Test::Class has a dependency which has upgraded to a broken version.

This reminds me of two things I'd really like for CPAN to have:

1. Ability to blacklist specific module versions, both in requirements (my module requires File::Next >= 1.0 and not 1.04, for example) and overall (effectively, we pull this version from the repository.)

2. An option to install the test scripts for each module some place, and a script to re-run those test scripts when considering installing a module in the dependency graph for the associated module.  That is, if I have App::Ack installed, along with its tests, and I attempt to install File::Next 1.04, while it passes its own tests, it fails App::Ack's tests, and so it's not blindly installed, and therefore my system isn't broken.

I do realize that the latter feature would require a lot of work and additional features - for example, when processing an install queue, build a single blib directory for all of the modules in the queue, so that the tests can run in the context of all of the upgraded software, instead of just what we have processed thus far.  (That would also be useful for handling circular dependencies - that problem goes away, so long as they aren't build-depends.)  But there's a lot of things that take a lot of work but are really needed.

Sigh.  That's what happens when I try to comment on things while trying to catch up on my reading.  If it had been using Macromedia Flash, then it wouldn't be storing the data server-side.

However, I do think my point still stands of this mentality tends to drops post form data.  It doesn't have to - one could store that in session data also, but it's considerably easier and less problematic to simply use forms, as indicated for the more general case in your original response.

If you are the only one who has a login currently and the site is on your internal network and you only access it from your internal network, the rest of my post is premature.

However, if you connect to it over the internet, having the password encrypted locally does very little good, as there is *more* danger of passwords being captured as they traverse the Internet.

So long as the rest of the site is secure, local storage of passwords is a fairly moot point.  I feel certain that the primary reason that was the major focus of so many of the people responding to the perl monks breach is that it's an absolutely trivial thing to implement - it shouldn't be considered the 'best practice', but rather the 'only practice'.

However, likewise, the submit on a login form should go over https.  This also should be an 'only practice', IMO.  (Yes, I know - last I checked, use.perl.org has the same problem.  However, since you're developing this site right now, it's the time to complain about it now.)

Agreed.  In any event, flash-based solutions are unlikely to win you friends who are truly security conscious when there are static methods that have worked forever that still work.  (And, for that matter, shockwave, java, or javascript solutions will also not motivate friends in the above mentioned crowd.)

Passing the information as form values is especially a good idea because it then makes passing other form values a no brainer.  And when you do that, the login form no longer causes your users to curse at you for requiring that they re-enter their form data.  I've never seen a client-side code solution to return you to the same place handle this right.

Finally, it also has a win for the multi-tab or multi-window user; if they're on your site multiple times, and they manage to get two login pages displayed, both pages will then proceed to the correct place.  Yeah, I know, I'm a freak for doing this, but sometimes my net connection's slow.  Rather than waiting, I change tabs.  Isn't that what they're for?

Not everyone can fly, shoot force-beams from their fingers or eyes, or will things to polymorph or self-destruct.  If one isn't a superhero or adventurer in ones dreams, fighting the aliens may not be so prudent.

Now, from my perspective, those aliens didn't sound so much threatening as misguided and in need of assistance...  But, then, in *my* dreams, I can will the FNG into a Perl master.  Well, on a good night.

I realize you are only suggesting this for the pod tests.  For those tests, this is innocuous enough.  However, as chromatic pointed out, cargo cult programming exists.  I'd prefer to give the cargo cult programmers as few chances to happen across code that skips all tests for people installing via CPAN/CPANPLUS, especially since some of them may not run any tests on their own boxes (even though they have them.)

perl -MPIPs -de '$s = PIPs->new->model("PIPs")->schema; $DB::single = 1;print'

Setting $DB::single makes perl stop before the *next* command.  If there is no next command, it won't stop.

The problem is that the vast majority of programmers use Windows. Sad to say, given that skill doesn't necessarily choose platform, this also means that most of the really good programmers use Windows - and you're shutting them out.

It is not necessarily a problem that is too difficult to overcome, once one determines one wants to fix it. If all else fails, it should be possible to write a svn-git module, to be able to commit to a git repo as easily as to a svn repo (while, of course, losing the git easy forking advantages for the people who use it). Similarly, there could be an hg-git module, as it seems some claim Mercurial also has a fairly low barrier to submit.

Of course, given the platform of the primary maintainer of Padre, an svn-git module may not be as useful as it might otherwise be...

Disclaimer: I know nothing practical about git. It's been on my list of tools to learn since about a week after it was written, but I've not even read all of the theory, despite having read more of the theory than I have of the practical. I suspect this speaks to the tool's complexity, because I find it to be very exciting in theory - very close to my 'dream VCS'.

That is probably accurate, as far as it goes.  :)

That having been said, I don't see the recommends as 100% synonymous with the concept.  Module A can recommend module B because it is complementary to module A, even though there's no code interactions, and no tests which one can do for the other.  I'm not interested in that kind of a relationship, as far as this rebuilding goes.

Specifically, what I'm looking for, for a test-happy build, is the ability to install all test dependencies - both hard and 'recommends' - before running the tests for a new module.  If those test dependencies produce a loop, then I'd like the test report for the modules to not be issued until both modules are installed, and then re-run the tests.  (Note: if both tests then failed, I'd probably consider this another form of na.)

Disclaimer: I'm being idealistic and stuff here.  I've only just installed CPAN::Reporter, and there's a lot about cpantesters I don't yet know.  I haven't looked at the code, and I don't know how complicated this would be to code.  I don't expect all of this stuff to be implemented any time soon - since actually starting to communicate with and learn more about the rest of the Perl community, I'm really impressed with how much of the stuff I'd like to see coded already *is* coded, or already has some vestigial existence.

Actually, I don't have that concern - I want the latest working version. When I upgrade, I bite the bullet and upgrade.

Of course, CPAN.pm won't give me that; it'll give me the latest version, worky or not. But that's an issue with CPAN.pm, not autobundle.

autobundle will also install everything that was installed before, even if some of them were installed only because they were dependencies of one of the modules specifically requested before, even though that module no longer depends upon them. I don't think one can get around that problem without getting the information to make the bundle from the install process, rather than just checking to see what is installed.