in reply to win32api::commport install fails

What do you mean that this:

t/test1.t (Wstat: 1280 Tests: 309 Failed: 5)
Failed tests: 53, 57, 61, 210, 219
Non-zero exit status: 5
t/test2.t (Wstat: 768 Tests: 146 Failed: 3)
Failed tests: 5-7
Non-zero exit status: 3
t/test3.t (Wstat: 768 Tests: 264 Failed: 3)
Failed tests: 40, 44, 48
Non-zero exit status: 3
t/test4.t (Wstat: 3072 Tests: 518 Failed: 12)
Failed tests: 5-7, 83-85, 232-234, 294-296
Non-zero exit status: 12
Files=7, Tests=1808, 59 wallclock secs ( 0.22 usr + 0.08 sys = 0.30 CP
+U)
Result: FAIL
Failed 4/7 test programs. 23/1808 subtests failed.
dmake.exe: Error code 255, while making 
'test_dynamic'
-> FAIL Installing Win32API::CommPort failed. See \.cpanm
\build.log for details.

[download]

doesn't tell anything more useful than if it said: It's F***ED!".

They'll have you know, that the Perl Test::*straight jacket suite is state-of-the-art(*).

(*Ie, It copied Java's, so it must be good; Right?!)

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

RIP Neil Armstrong

Replies are listed 'Best First'.
Re^2: win32api::commport install fails (useless)
by tye (Sage) on Nov 01, 2012 at 14:15 UTC

    Yes, prove sucks. A lot. I recall it not sucking this bad. The "summary" output is way too verbose and yet almost everything in the summary is useless (and much of it is just purely incorrect). Meanwhile, it is doing a great job of hiding from the user what would be less output but that would be extremely informative.

    What's worse, the current implementation of prove is like some doctoral thesis on how to over-engineer software using rampant application of inheritance, factories, and "pure" layers of abstraction (that appear to have no use other than adding layers of abstraction). And this makes it extremely time-consuming to find the bit of code that is at fault each time I go to make a tiny improvement to it.

    Trying to follow the flow of prove's code, you repeatedly get the impression that extreme effort was exerted for the sole purpose of making it difficult to follow the code flow.

    You get to a promising-sounding class only to find it has no code that does anything real at all. It just contains a method called 'run' that does nothing other than call a method called 'next' on something else. So you go to find where that something was created so you can know the class name so you can go read the code for that class to see what the 'next' method does. But the code that creates that "something else" is a factory where the class name used is derived via complex means hidden under several layers of abstraction.

    After spending a significant amount of time trying to navigate those several layers of abstraction, you finally come up with another promising-sounding class name. So you go read the code for it and you even find a 'next' method. Unfortunately, all it does is dereference a code reference that was created by some other code. Now you don't even have a method name to aid your next search step.

    Now I've spent an hour or two trying to just find what is surely a very simple couple of lines of Perl code that I'm sure I could fix in a matter of minutes because the specific problem I'm trying to address is a very simple problem, but I don't get three hours of uninterrupted time at work hardly ever so I have to go to a meeting or help somebody with some issue and after that, the dozens of layers of pure abstraction have mostly fallen out of my head and I'm nearly starting over from the beginning if I want to look for the needle of functional, practical code in the haystack of dozens of pure abstraction layers.

    I think I'll next just install an old version of 'prove' and see if the output is tons more useful (like I remember). If not, at least I can tell from the much shorter list of modules that are included (and the fact that these modules have practical-sounding names rather than names that sound like theoretical abstraction layers) that I'll be able to make fixes without needing hours and hours of time to fill my head with dozens of pure layers of abstraction.

    (At least none of the layers are (yet) hiding behind a truly enormous pile of code like if they started using Moose... *shudder*)

    - tye        

[reply]
      and "pure" layers of abstraction (that appear to have no use other than adding layers of abstraction).

      When abstraction becomes distraction, it has failed.

      the current implementation of prove is like some doctoral thesis on how to over-engineer software

      Putting the woe in O'Woe (Order of Worshipful Over Engineers).

      (At least none of the layers are (yet) hiding behind a truly enormous pile of code like if they started using Moose... *shudder*)

      The OO in s-l-o-o-w!

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      RIP Neil Armstrong
[reply]

In Section Seekers of Perl Wisdom